Java is probably the worst language ever. It ha done tremendous amount of damage to the developer community. And it has gotten worse because hardware has evolved in a non java friendly way.
Yeah! I remember that also. And how Java written code would run faster for every versions and surpass C++. I'm still waiting... The sad thing with most of the new languages is that you need to switch language every 5th year to stay on top of what is popular for the moment.
I feel like that assumption has come about because of the allure of OOP, thinking that C++ rules because it's C + OOP. But now C++ is not used because OOP is so awesome. It's because C++ is fast and flexible. Java isn't that fast or flexible, it's selling point was "write once, run everywhere" but this undoubtedly became "write once, debug everywhere". It's still is used a lot though.
@@BboyKeny You can write OOP in C++, you just aren't forced to. JAVA blew several things IMO: Iterators are fundamentally wrongly implemented. Generics are fundamentally wrongly implemented.
Java was absolutely awful, but Sun was a brilliant marketer. They didn't try to sell it to developers, but to the suits who knew just enough to be lethal. The media blasted the general public with stories about how Java was going to be the language of the upcoming internet. The suits signed up for it, fearing they were going to lose out to the future, despite protests from developers who knew Java was all hype.
I don't think "issues inherited from C" is fair when a lot of the things that are problems in C++ are fine in the more barebones environments where C is a preferred alternative. Deciding to religiously stick to being a superset of C when there was no real need to was stupid though. Different tools for different jobs
@@MechanicaMenace I get what you're trying to say, but there are definitely things in C that are still bad when using plain C today. They might be less painful than in C++, but they are still there.
@@Spartan322 38 years ago, both languages have grown since. And for at least 10 years most C++ was hampered by it too. I still see modern C++ that is basically just C with terrible use of classes. Also plenty of languages support C interop without including all of C as part of the language.
@@MechanicaMenace No language I can think of that has any wide support compares to C++ in terms of C interop even now, and that was the big thing necessary for C++ to take over the market, in fact its a common problem, if you want to supersede a language for a specific use, the only quick way to do it is to keep compatibility while improving on the old system, C++ dominated thus because it could trivially run any C code. Without this C++ simply would've never even taken off. As for "modern C++" that's not modern C++ if its not using a large amount of even the C++11 features, let alone C++17. C with classes is a pre-C++98 concept, anyone who still does that is still stuck in the 80s, that's not modern, that's stupid. And C++ may have been hampered in some ways by interop with C, the fact is that without it, there would be no C++, nobody would've used it, simple as that. Every member of the standards committee and many of the standards contributors agree with this as well, but even that aside we could simply compare languages that didn't have that vs. those that did, those that said they'll kill C++ but didn't have trivial C interop, not a single one of them actually killed C++.
C++ to other memory managed languages is like a knife to a blender. Yes you have to type more to get the same thing, but sometimes, actually many times you want the power to control of what you are cutting exactly the way you want. C++ will be here as long as performance and energy are constraints to computation. The day we don't have performance and energy constraints on computation (maybe quantum computing?, idk), that day c++ dies.
I will pour one out for ol' C++ But first let's celebrate episode 400. At work, for an autonomous driving (research) software framework, C++ is very much still alive. For better or worse this will be the case for the foreseeable future.
My personal opinion is that the new language and library features are good enough to draw in a lot more users, but consuming libraries and plugins needs serious attention--which should be addressed by C++ modules. It appears they are working on making them as good as C# modules, per this open source project: ifc-spec
I've been hearing "C++ is on its way out" for literally my entire 20+ years of programming life and it has yet to happen. On the other hand, the vast majority of proposed replacements have come, had their 15 minutes in the sun, and then slid into irrelevancy. I do not fear for my C++ career unless AI somehow figures it out, which I'm yet to see.
It is on way out. This way will take several decades, probably more than half of century. But no current C++ developer in any thread yet. It will take generations to replace systems C++ with Rust or something else.And yes we already had that talk with Cobol 30 years ago, ppl were arguing how Cobol is not dying as it top 1 language used in the world.
I love c++ but moved onto Rust. I wouldn't have gone near any of the previously touted c++ killers, but Rust is the real deal. Cargo is the real killer, after having cargo it's difficult to justify going back to c++.
@@theLowestPointInMyLife Cargo is nice when you're working on some "done and done" project like a web service that could be easily replaced or rewritten in the future. When you work on something that supposed to work and evolve over many years, like, let's say, a game engine, Cargo with its NPM-like project management will become the problem you need to solve more sooner than later. A small-sized project in Rust can easily hit 500 in dependencies count with half of them in 0.x version range, do you have any guarantee that all of them will work in 5 years on newer versions of Rust? Besides, c++ has a lot of package managers. From xmake and build2 to vcpkg.
@mapron1 I really doubt it. I will just give a recent example about a project we started working on, its an ML HPC library, I am also a programmer having only 8 years of experience (but I started when I was 12) so, I would say I am in "young developers" category with only actually 3-4 years of cpp experience realistically because I move so much between different languages for different projects. I really wanted to use rust for this project because of its "compile time optimisation" approach I wanted to take and rust macro system is the best for it, though its doable in c++ using constexpr and templates. After testing out rust and cpp for a month we couldn't find a way to the fastest while using rust, the fastest BLAS implementations are in c++, the fastest gpu compute is only possible in c++, not to mention it would be hassle to link those said gpu libraries statically as we want to. The toolchain for c++ although little shabby from its legacy is probably the fastest binary generating toolchain out there (not to mention the most configurable), there is absolutely no doubt about it and nothing beats it. I absolutely love rust, its my favourite language to work in but there is no denying its not replacing C/C++ anytime soon.
Unreal Engine is in C++ of all the languages. It's not gonna be dead. Unity just committed seppuku with their latest decision, people are migrating to UE, and therefore C++. That's, like, a million programmers coming to C++ over the next few years.
Unity is built with C++ and Godot as well, you’re gonna have a hard time finding a game engine not written in C++. It’s the gold standard in gamedev after all. Only exceptions I know of are Minecraft(Java, although bedrock is C++) and Remedy’s games since they use Dlang.
most of UE is based in blueprints, you can use C++ but its ment to assist the blueprint's not be dedicated to it. so id say even in UE C++ is on the sideline.
@@F0r3v3rT0m0rr0w _"most of UE is based in blueprints"_ haha. No. UE is written in C++. It has 16 millions of lines of C++ code in it. When you create a game, it's a C++ project first with the base and the most of the code in C++. _"you can use C++ but its ment to assist the blueprint's not be dedicated to it"_ No, that's not how it works. Whenever you do anything in blueprints, all of it still runs C++ code. Programming in blueprints is a recipe for a disaster: you kill your performance and your games runs like shit. Proper UE development looks like this: you program everything in C++ and in the editor you do non-programming things with blueprints: meshes, skeletons, textures, level design, UI design(only how it looks, no coding UI logic in blueprints), etc. Tell me you're not a programmer without actually telling me. You just did. Artist?
It's also being used widely in autonomous vehicles! :D We are using it here at Volvo Trucks! I'm quite sure it's not going to die at least in the short or midterm, but it's definitely going to be more challenging for it to keep growing specifically because of much more competition in the market, which is a good thing. also, so many discussions around it and a pretty active and alive community/committee is another witness of it being alive and in good shape for now.
There are more car Maintenance Mechanics than there are Mechanical Engineers building cars. That doesn't mean that Mechanical Engineering is dying. I think the same principle applies here. There are still C language developers maintaining drivers and kernel for compute devices. I think C++ has found its niche. It is not the tool for all scenarios.
Sean Baxter's Circle seems like a solid path towards evolution. The dude has implemented nearly every feature of Rust and all sorts of safety/defaults fixes.
Yet another C++ compiler would not help with the problem because of existing codebase, with c++ you can only use Rust to get the Rust experience, no compiler can save your external code.
Thanks for the 400 episodes of C++, I really like the language. The company I am working for uses all sorts of languages, C++, C#, Java, Kotlin, Python, and type-script for different purposes, they are just like wrenches and screwdrivers. It is a matter of how fast people can loosen or tighten the screws. But I still do not like Java, and happy to see Kotlin is replacing it on Android which is one of the most significant application scenarios for Java. I am pretty sure Google already realized its fault and corrected it in Fuchsia by not using Java at all :). Ast to C++, I really wish someone could use AI to filter the error messages yielded by the compiler, especially those template-related errors.
I've spent over 30 years writing C++, where much of my work has been converting Perl, PHP, Basic, C, C#, Java, Python, and assembly language code to C++ in order to improve performance and reduce memory consumption. In that process I typically improve reliability as well. I suspect there will always be a need for "a portable assembly language with some cool features", and C++ works for me. 🙂
The only people saying "C++ is dying" are people trying to get you to use _their_ language. Meanwhile pretty much every language that _isnt_ C++ is implemented in C++.
C and C++ is the most portable. As someone who brings up new systems from scratch building new Linux systems all start with the c/c++ tool chains. Asking if C++ is dying is like asking if bricks are dying because someone is building wooden houses. 🤷♂️ it's a pointless question.
Thanks for making this video Jason. C++ is my first programming language that I learnt in my high school. Still my favorite programming language. During my high school, for some reason, we were taught very old Turbo C++ (in 2011). It was challenging to learn it, but in the end I managed to make my first ever project. I had no idea about modern C++ until late 2014. But learning modern C++ gave me relief as otherwise I would have to force myself to learn and use Java. My first job was in C++03. But gradually I got a chance to use C++17. Hopefully in future I will get a chance to use C++2x and use more modern features.
I have no idea what your background is, obviously, but I've heard this story of being taught Turbo C++ in recent years from many people in Indian schools. I'm hoping that trend is changing! Turbo C++ didn't even implement namespace std yet.
I worked on a team that prohibited the use of C++. That could be incredibly restrictive when working in domains for which many of the ready-made solutions were already available as shared C++ code. They wanted some image processing program put together, instead of using a C++ open library, they wanted us to use some other open library that could run in a browser. That other open source library used Web Assembly compiled from C++. I wonder if the managers would have chosen differently had they realized.
A director of engineering I know, located in Silicon Valley , told me that he can’t find c++ developers for embedded systems . The company has an exciting product and pays very well. But can’t find candidates to interview. (Not defense related)
The main problem of C++ is the usage of error prone C features. The C language features should be switched off by default. Many of the vulnerability is coming from C code. Also the lack of standardize ABI of C++ is a big problem. For shared libraries the primitve C API is used.
I learnt ANSI C back in 1988 from K&R as a kid. Later I haven’t used it for 25 years, but last year I learnt C++ at university (MSc Data Analytics UCD Dublin), and since then, I keep learning (and using) it as a Python and R extension. Maybe a standard package manager (Conan 2?) would be useful; and also a restrictive subset with modern syntax and safety features (Carbon? cppfront?) which could empower application developers to write safe applications with it could also help.
Also, constexpr and consteval pre-computation of large portions of a program that would otherwise run at runtime, in the field on multiple machines? constexpr and consteval are green technology.
Haha this warmed my heart. I agree with all arguments. C++ has insane pedigree at this point and the language and stdlib are evolving. I love knowing that I can use the language in absolutely any context from embedded controllers to distributed HPC. There's longevity in that capability alone.
7:41, paused here to point out it's perfectly possible to program in ANY language (including asm or even machine code, not that I'm insane enough to try), basic integers and floats for starters are pretty much always gonna be memory safe when used with the basic operators. For buffers you just need a guarded page to copy it to, edit, then copy back. By guarded I mean a set of at least 3 contiguous pages, the 1st and last are to be read only, this enures segfaults if things go south. The middle page/s are for the copied buffer that's being edited/read from, once done the bytes expected in the actual buffer will be copied from the page into the buffer without ever touching the externals of the buffer. So here's a VERY rough example in pseudo code: vm = newguarded( bufsize ); memcpy( vm, buf, bufsize ); modify( vm, ud ); memcpy( buf, vm, bufsize ); delguarded( vm ); Naturally there's quicker ways to implement this but it gets the rough idea across
The hype I had in your last argument it comes from a c++ fangirl. But it will take a while until imports become normal. But they promises so much in time saving I just love it, and I think it will make a revolution to C++. Also, I also think that we may see some mixture in the future like half project in C++ the other JavaScript? Maybe. Something to speed up the writing process. Don't know but C++ feels live and C++23 sounds more promising than chatGPT.
I find curious that you don’t mention Odin and Zig. I think those 2 have a higher potential to at least complement C++ than Carbon or Cppfront. I don’t think we need a C++ successor to kill C++ and I don’t think C++ will die any time soon. However, I believe we should be more vocals with the committee about the many fixes C++ needs to make our life better. I think it’s useless to add new syntax every time we have a new standard when we still did not fix fundamental flaws of the language.
Seeing the title, my immediate reaction was "no, it is not a death; it is necrosis". Once something gets into C++, it always co-exists with the old approach. To make things worse, the new approach will not work for every use case, and there is always some circumstances where you must get back to the old approach. Let's be honest with ourselves: C++ has been and will continue to be a total mess of half-baked features. For example, references and pointers. References cannot be null, cannot be rebound, must be initialised immediately at declaration, and cannot do pointer arithmetic. Arrays decay to pointers. Even `this` is a pointer (despite it can never be null, need not be rebound, is initialised automagically, and you rarely need pointer arithmetic on `this`; i.e., it could have been a reference). For example, char arrays, char pointers, null-terminated strings, std::string, std::wstring, std::u16string, std::u32string, std::u8string, std::string_view. For example, plain arrays, pointers, pointers/references to arrays, std::vector, std::array, and of course the notorious std::vector. For example, exceptions, errno, return codes, std::optional, std::expected. For example, global statics, anonymous namespaces, private module members. For example, implicit casts, C-style casts, static_cast, dynamic_cast, const_cast, reinterpret_cast, std::bit_cast. For example, default initialisation, aggregate initialisation (designated or not), zero initialisation, copy initialisation, move initialisation; with curly-braces, with parentheses, with equal signs. And many more. C++ needs not more new features, but a thorough clean-up to regain simplicity and consistence. But apparently it will not happen, and every one is still working hard to add more half-baked features and compromises into it. In conclusion, for new projects, forget about C++ and choose a sane language to work with.
sigh of relief - I can continue to report to work and continue working on my C++ green field project (started in year 2023) thanks for clearing this up - that I don't need to start deleting C++ compilers and toolchains off of my computers
yep, I think all of your thoughts are good.... While c++ may not be the most "glamorous" it is still at the core of many aspects of "computers" around the world. Also, you didn't even touch on embedded/hardware stuff!
I think you missed the point. It seems to me that the C++ successor languages are being developed because the C++ language itself has gotten so complicated it's completely unmaintainable, the language itself has built up 40 years of technical debt. People starting new projects *could* use the features of modern C++ (including C++ 23 features), but then they get saddled with all of the wide variety of edge cases that C++ has. Alternatively, they can use a more modern programming language that, as of the current moment, has fewer edge cases and more safety. C++ is certainly going to be around for a long time in the future just based on the number of projects using it, but I don't think many projects will adopt a modern flavor of C++ as their primary language. I say this as someone who got into programming by checking out a C++ book in highschool around 2010 and still uses the language frequently.
there are things I really don't understand in language evolution, especially caused by programmer coming from other worlds. Like why should we write upfront functions? Why auto main()->int and not the 40 years functioning int main() ? Where is the advantage, other than confusing people seeing the most common version since forever?
Bjarne's cfront, emitted C code. That is you wrote in C++, fed that into cfront, and cfront would emit C code that a C compiler would compile and link. cfront reached version 3.0 which I believe tried to support templates.
It is very important in embedded - but there's a surprising number of people who still think that C++ cannot be used in embedded because it's "too slow"
The thing that strikes me about all of these new languages is they either look like Rust or they look like C#. Both languages and any that are similar suck so much and it boggles my mind how often they're copied.
Mojo is, to me, the most interesting potential replacement that I don't see discussed as a successor. Chris's track record is as solid as it gets, and the language's focus on multi-core, multi hardware could lead to large applications being authored in Mojo. I don't know yet how low level it will go, whether you'd be sane to write a driver in Mojo, but there's a tonne of overlap in complex applications where able wasting less cognitive capacity on language structure/quirks/history will be a big win.
I think both Java and C++ will not "die", just like COBOL and Fortran are not dead. However they probably will become legacy languages, so that most of new projects made will be in other languages like Rust, Carbon or Cppfront(which sort of is c++ or "cpp2.0" and classic C++ will be a language used to mantain legacy software.
Rust really isn't designed to supercede C++ unlike what most people think, cppfront and Carbon would be more likely, but given they rely on C++ to exist, C++ really doesn't seem to be going anywhere.
@@Spartan322 That's true. C++ has indeed reached the "threshold of immortality". The question is will C++ still be the go-to language for high performance application software and system software. That remains to be seen of course. But it's getting some stiff competition for sure!
@@torarinvik4920 I think for now at least, none of the alternatives are all that compelling, many of the modern ones tend to either be overly safe to the point of a struggle to deal with or they intentionally remove features that are commonly used for solutions in C++ that simply don't have an analog in the other languages. From the folks I know and seen in high level infrastructure development, say like aerospace and security contracting, they still start new projects in C++, there's simply no alternative, there are folks even I know who still have to use C for new projects occasionally like for video codec development.
I think the answer to this question depends on how you define "dying" for a programming language. If you define it as "won't be used anymore", Cobol is still in use. The death of EVERY language which at some point was popular NEEDS to be measured in multiple human lifetimes. That makes it very hard to track if one is dying or not and currently, I would say no. If you define it as "less and less NEW projects pick it, even for an area where it was originally very popular", then it's considerably harder. And I don't know of any data which can support either side. But considering the way regulations work and are reformed at this point (especially thanks to government agencies which want to limit the use of language where memory bugs are easy), I could see this happening to C++ in the coming years. But as I said, this goes for NEW projects, not existing ones.
I personally don't see C++ dying around me in the professional world, although maybe it is not always the predominant choice for fresh new projects anymore. True, many people have predicted the death of C++ in the past. What feels different to me this time is how many well-known figures of the C++ community seems to believe it is so. As you said, there's ADSP, with Bryce, ex-chair of LEWG, saying C++ is dead, there's people like Nicolai Josuttis and Kevlin Henney that said it on a panel at ACCU 2023, you have people like Herb Sutter, Kate Gregory, Chandler Carruth, Dave Abrahams and even Sean Parent at some level that move their attention to successor languages... Non-rhetorical question: did this happen before?
I wouldn't consider Herb's cppfront to be him paying more attention to a successor language, the others maybe, thought they're too reliant on C++ and the development of C++ to say that anyone can get off of it. And there's still a lot of new projects that start on C++ when they needing something lower then C#.
C++ will only “die” when it has a clear descendant take over for it, like it did for C. A “C*” so to speak. And even then C isn’t dead; it’s just the programming language counterpart of Latin, a language still used but no longer being significantly modified/updated. Rust is too different and currently limited in its own ways to be a full replacement. My guess is that we see C++ de facto forked into several possible successors like Circle vs. Cppfront, and depending on how that played out it might replicate the early era of C successors where C++ competed with things like objective-c before ultimately winning out.
> c++ modules hello world I wish it was that simple. But modules is a major pain point across different platforms and compilers. And sadly it still lack features many want the most - to make them usable like python/rust with objects and templates not just namespaced functions.
Herb's CppFront looks the most promissing, basically what I have suggested for a while, that cpp is not obligated to mollycoddle 30 year old code bases. If they want to sit on their thumbs and make zero effort to refactor or upgrade than they can just set --std=C++98 on their compiler and forego the modern features. Even then it would only be for that one old compilation unit, the linker just sees assembly/binary/intermediateLang and doesn't know chunks started as C99 from g++23 from Fortran.
Hello. Thank you for video. As I know some IT giants like Microsoft recommend starting new projects in a Rust. And on the last graph in your video, we can see that rust is really growing now. So it could be possible that Rust will replace C++ in the future(but not nearest), because of a lot of existing C++ code as you mentioned in the video, and you can not replace all this code at once. What do you think about this?
It's a crying shame that they're so adamant about not fixing core problems that would allow them to make the improvements needed to modernise the language. No pattern matching, no discriminated unions, no standardised package manager, no compiler backing you up on safety concerns ala Rust. I can see why newcomers might ignore it over languages with superior tooling.
OMG - carbon-lang reminds every Apple developer of the past... 😆 Carbon was the compatibility layer introduced in classic macOS to facilitate the move to the UNIX based macOS / OS X It's ooooooold...
At least re: language design, it's not grow or die. Ideally, the core language gives enough that people can define whatever else they need from there. Language designers must aim to put themselves out of business. If you were told C++11 could either have lambdas or foreach but not both, which should you choose? IMO lambdas because you can approximate foreach by std::for_each + lambda, but not the reverse. Once we have lambda, the core language is freed from needing to support every looping construct. So if the core language is not growing, are we failing to keep up? Or did we put ourselves out of a job? For C++, i think it's both. The past decade of improvements does mean we can express a lot more inside of C++, like how variant and tuple are in the standard library, not the core language. But there is no satisfactory way we can build reflection using standard C++, and, lacking reflection, there's a lot we cannot do, (hence every game studio making their own code generator to work around this).
not sure about the death of c++.. in fact, i think the problem of c++ is two fold: (1) should it rather be called ++c (its faster)? and (2) to resolve the most vexing parsing of what c++98 really means; 1998 or 2098?
"virtually every database engine is written in C++"... Look at Postgres, Redis, SQLite... Other DB engines that are written in C++ usually use a subset of C++ that is very close to C (and described as C-style).
The main problem with C++ is that it is such a slow-moving behemoth with far too many cooks steering the ship. Changes take years to go from an idea to a proposal to a standard and then years longer to actually be implemented in all major compilers.
It tries to be everything to everyone and is pumped full of cryptic features. It was too complex for its use in the 90s and it certainly is too complex today. Instead of adding features, it should have been replaced with a "light" version that kept the essentials and making it easy to understand and work with. The hardware landscape has changed quite a bit too, so threading, resource locking and data access/databases should have build-in constructs for them.
@@TheEVEInspiration _"It was too complex for its use in the 90s and it certainly is too complex today"_ Or you can just do classes, templates(very sparingly when needed), and do shared_ptr and basically write C# by passing by reference with shared_ptr.
@@KulaGGin I deliberately limited myself to the features I really needed. That worked fine for me, but still I found that upwards of 90% of the colleagues programming in the same language were unable to cope well with even that. So I was spending a lot of time unraveling and fixing other peoples code. And I can say with certainty, the language was too complex.
@@KulaGGinOh and don't get me wrong, I loved the language. Especially the predictable constructor/destructor calling for local objects, which could be utilized to do write very safe self-cleaning code, regardless of branch complexity. In a new language it is something I would expect to be there and even expanded upon (one of the reasons C# sucks, it's broken). Not allocating on the stack, but still following destruction upon call-stack unwinding for example, without smart pointers and such additional constructs. It is one of those needless complexities C++ is burdened with.
I feel like the argument of "there's already millions of lines written in cpp, we have to keep it alive!" is like saying "we have to keep burning gas because there's already millions of gas burning cars! We can't make electric cars!". Imagine how many latent vulnerabilities and bugs there could be in all of those millions on lines. Look at the work at Google and Microsoft where they are rewriting critical portions of their stack in memory safe languages, and trying to get rid of their c/cpp.
I know most of those charts are really directed at people looking for jobs so I can see why they lump everything together. However it is not a good way to compare languages because it is expected that there will be more volume of programming in front-end interpreted languages than in backend infrastructure languages. The whole point of the interpreted stuff is quick turnaround and temporary solutions. Companies want a fresh website look every month but they want a mainframe processing transactions to be stable for decades. But that website bling is non-critical either in reliability or hardware efficiency (each line of code is low value) so they will tend to throw a bunch of cheap labor at it. While the development work for the mainframe is likely to be done with a lot of testing and optimizing along the way (each line is high value).
c++: There's already a well known way to do X also c++: let's confuse our devs instead of helping them by mandating Y instead just because we don't like c despite inheriting everything from it
C++ isn't dying, but there are big questions about where it's going and how it's going to get there. C++ language evolution has some very very difficult questions to answer, and not everybody is happy with the Standard Committee's current answer. I don't think C++ will die, but the community may fragment which would be a great loss.
How many compilers work with `import std;` and how many of them let me write custom non-`std` modules? And for that matter how many have full format support; I think last time I wanted something fancy it wasn’t supported anywhere
@@cppweekly well allright. Now that I think about it, I've been using cout less once I started doing graphical stuff like SFML and the Godot Engine, so maybe I won't even miss it.
I don’t think C++ is dying. Everything else essentially uses C++ as the backend language, so until that changes C++ will live on. I will say, the committee should try and push for C++26 being the next C++11, which I think would revitalize the language. C++20 modules, ranges, and coroutines were huge additions but incomplete and C++23 and 26 are picking up the slack. Adding Contracts, Pattern Matching, Static Reflection, and removing the need of the PreProcessor I think would be the necessary requirements to grow C++.
VSC still doesn't support C++23 yet. As an aside, I see more videos showing interest in new languages than I do C++ videos. Yes, C++20 has a lot of new features, but it's very easy to get wrong and still hard to write memory safe and bug free code. It's also difficult to keep up with all of the new features and changing syntax.
I lile c++ but it interstingly when using the cutting edge language features, specifically auto return types, deducing this and utf8 strings i find that c++ looks a lot like rust. This is why i consider rust a successor to c++ that cleans up the legacy mess and makes meaningful defaults.
This is an almost completely unqualified opinion, but here we go: You already mentioned that C++ is used in pretty much every system that needs to be reliable, and this fact alone is why it will probably take decades for it to fully "die", whatever that may mean. It reminds me of how there are still people needed to maintain COBOL systems because they are so crucial, and it seems likely that C++ will have the same thing happen, just much more pronounced due to how widespread it was for decades. We might see a downwards trend in new projects being built on C++, but even that may take years to fully develop. In the meantime colleges will still be teaching C++ in a lot of courses so the supply of fresh C++ users is also not stopping anytime soon.
How many meetings to decide what to change/add to get another look of "hello, world!" ?... Let's refactor everything ! Nice seeing a 400th episode ! I'm not the sharpest C++ coder, but I like spending time here from time to time, always learning something. Even if I hate templates ...
I encourage you to spend some time with templates and get over the hate. That or just use `auto` function parameters and let the compiler write the template for you. In many cases it truly is the best option for performance and correctness, while avoiding implicit conversions and runtime type checking.
@@cppweekly I was referring to the server side. I believe PHP, Ruby and Python are used for small sites. And companies internally and larger sites externally would use Java and C#. I think Facebook and Google and other mega sites use C++ for high traffic applications. There is also mobile with Swift/Objective C being the Apple preferred languages and Java/Kotlin being the Google preferred languages. Unfortunate that the market can only handle two OSes because Blackberry was going with QT and C++ and I think Nokia (Symbian/Linux) was as well. But Windows Phone was C#.
To me it seems c++ is popular because its so ubiquitous. We have a lot of old c++ written, most importantly pre c++23! While i dont think its dying, its also not going to grow significantly anymore, which may change in the future if c++ can drop its legacy cruft.
![BOWKYLION - วิงวอน (ex-change) [Official MV]](http://i.ytimg.com/vi/cLdnZWDaO-w/mqdefault.jpg)
I was a C++ programmer in the 90s and back then Java was going to make C++ obsolete overnight. 25 years later and I'm still being paid to write C++.
Java is probably the worst language ever. It ha done tremendous amount of damage to the developer community. And it has gotten worse because hardware has evolved in a non java friendly way.
Yeah! I remember that also. And how Java written code would run faster for every versions and surpass C++. I'm still waiting...
The sad thing with most of the new languages is that you need to switch language every 5th year to stay on top of what is popular for the moment.
I feel like that assumption has come about because of the allure of OOP, thinking that C++ rules because it's C + OOP. But now C++ is not used because OOP is so awesome. It's because C++ is fast and flexible. Java isn't that fast or flexible, it's selling point was "write once, run everywhere" but this undoubtedly became "write once, debug everywhere". It's still is used a lot though.
@@BboyKeny You can write OOP in C++, you just aren't forced to.
JAVA blew several things IMO:
Iterators are fundamentally wrongly implemented.
Generics are fundamentally wrongly implemented.
Java was absolutely awful, but Sun was a brilliant marketer. They didn't try to sell it to developers, but to the suits who knew just enough to be lethal. The media blasted the general public with stories about how Java was going to be the language of the upcoming internet. The suits signed up for it, fearing they were going to lose out to the future, despite protests from developers who knew Java was all hype.
C++ is definitely still evolving in meaningful ways. But the language is severely held back by past decisions and issues it inherited from C.
I don't think "issues inherited from C" is fair when a lot of the things that are problems in C++ are fine in the more barebones environments where C is a preferred alternative. Deciding to religiously stick to being a superset of C when there was no real need to was stupid though. Different tools for different jobs
@@MechanicaMenace I get what you're trying to say, but there are definitely things in C that are still bad when using plain C today. They might be less painful than in C++, but they are still there.
@@MechanicaMenace Half the reason C++ took over everything was specifically because it has a pure C interop.
@@Spartan322 38 years ago, both languages have grown since. And for at least 10 years most C++ was hampered by it too. I still see modern C++ that is basically just C with terrible use of classes.
Also plenty of languages support C interop without including all of C as part of the language.
@@MechanicaMenace No language I can think of that has any wide support compares to C++ in terms of C interop even now, and that was the big thing necessary for C++ to take over the market, in fact its a common problem, if you want to supersede a language for a specific use, the only quick way to do it is to keep compatibility while improving on the old system, C++ dominated thus because it could trivially run any C code. Without this C++ simply would've never even taken off.
As for "modern C++" that's not modern C++ if its not using a large amount of even the C++11 features, let alone C++17. C with classes is a pre-C++98 concept, anyone who still does that is still stuck in the 80s, that's not modern, that's stupid.
And C++ may have been hampered in some ways by interop with C, the fact is that without it, there would be no C++, nobody would've used it, simple as that. Every member of the standards committee and many of the standards contributors agree with this as well, but even that aside we could simply compare languages that didn't have that vs. those that did, those that said they'll kill C++ but didn't have trivial C interop, not a single one of them actually killed C++.
Happy 400th! Thanks for all the hard work supporting and promoting c++!
C++ to other memory managed languages is like a knife to a blender. Yes you have to type more to get the same thing, but sometimes, actually many times you want the power to control of what you are cutting exactly the way you want. C++ will be here as long as performance and energy are constraints to computation. The day we don't have performance and energy constraints on computation (maybe quantum computing?, idk), that day c++ dies.
I will pour one out for ol' C++
But first let's celebrate episode 400. At work, for an autonomous driving (research) software framework, C++ is very much still alive. For better or worse this will be the case for the foreseeable future.
My personal opinion is that the new language and library features are good enough to draw in a lot more users, but consuming libraries and plugins needs serious attention--which should be addressed by C++ modules. It appears they are working on making them as good as C# modules, per this open source project: ifc-spec
You can add Windows to the list of massively important projects written in C++
yeah, the most popular malware project
As well as Linux
@@PixelThorn Linux is written in C. Pretty sure.
@@PixelThornLinus torvalds famously hates C++
@@not_everI feel like that if you really like C then you will hate C++ and vice versa.
I've been hearing "C++ is on its way out" for literally my entire 20+ years of programming life and it has yet to happen. On the other hand, the vast majority of proposed replacements have come, had their 15 minutes in the sun, and then slid into irrelevancy. I do not fear for my C++ career unless AI somehow figures it out, which I'm yet to see.
It is on way out. This way will take several decades, probably more than half of century. But no current C++ developer in any thread yet. It will take generations to replace systems C++ with Rust or something else.And yes we already had that talk with Cobol 30 years ago, ppl were arguing how Cobol is not dying as it top 1 language used in the world.
I love c++ but moved onto Rust. I wouldn't have gone near any of the previously touted c++ killers, but Rust is the real deal. Cargo is the real killer, after having cargo it's difficult to justify going back to c++.
@@theLowestPointInMyLife Cargo is nice when you're working on some "done and done" project like a web service that could be easily replaced or rewritten in the future. When you work on something that supposed to work and evolve over many years, like, let's say, a game engine, Cargo with its NPM-like project management will become the problem you need to solve more sooner than later. A small-sized project in Rust can easily hit 500 in dependencies count with half of them in 0.x version range, do you have any guarantee that all of them will work in 5 years on newer versions of Rust?
Besides, c++ has a lot of package managers. From xmake and build2 to vcpkg.
@mapron1 I really doubt it. I will just give a recent example about a project we started working on, its an ML HPC library, I am also a programmer having only 8 years of experience (but I started when I was 12) so, I would say I am in "young developers" category with only actually 3-4 years of cpp experience realistically because I move so much between different languages for different projects.
I really wanted to use rust for this project because of its "compile time optimisation" approach I wanted to take and rust macro system is the best for it, though its doable in c++ using constexpr and templates. After testing out rust and cpp for a month we couldn't find a way to the fastest while using rust, the fastest BLAS implementations are in c++, the fastest gpu compute is only possible in c++, not to mention it would be hassle to link those said gpu libraries statically as we want to.
The toolchain for c++ although little shabby from its legacy is probably the fastest binary generating toolchain out there (not to mention the most configurable), there is absolutely no doubt about it and nothing beats it. I absolutely love rust, its my favourite language to work in but there is no denying its not replacing C/C++ anytime soon.
Unreal Engine is in C++ of all the languages. It's not gonna be dead. Unity just committed seppuku with their latest decision, people are migrating to UE, and therefore C++. That's, like, a million programmers coming to C++ over the next few years.
Unity is built with C++ and Godot as well, you’re gonna have a hard time finding a game engine not written in C++. It’s the gold standard in gamedev after all. Only exceptions I know of are Minecraft(Java, although bedrock is C++) and Remedy’s games since they use Dlang.
most of UE is based in blueprints, you can use C++ but its ment to assist the blueprint's not be dedicated to it. so id say even in UE C++ is on the sideline.
@@F0r3v3rT0m0rr0w _"most of UE is based in blueprints"_
haha. No. UE is written in C++. It has 16 millions of lines of C++ code in it.
When you create a game, it's a C++ project first with the base and the most of the code in C++.
_"you can use C++ but its ment to assist the blueprint's not be dedicated to it"_
No, that's not how it works. Whenever you do anything in blueprints, all of it still runs C++ code.
Programming in blueprints is a recipe for a disaster: you kill your performance and your games runs like shit.
Proper UE development looks like this: you program everything in C++ and in the editor you do non-programming things with blueprints: meshes, skeletons, textures, level design, UI design(only how it looks, no coding UI logic in blueprints), etc.
Tell me you're not a programmer without actually telling me. You just did. Artist?
It's also being used widely in autonomous vehicles! :D We are using it here at Volvo Trucks!
I'm quite sure it's not going to die at least in the short or midterm, but it's definitely going to be more challenging for it to keep growing specifically because of much more competition in the market, which is a good thing. also, so many discussions around it and a pretty active and alive community/committee is another witness of it being alive and in good shape for now.
Congratulations on reaching 400!!
I feel like if you wanna work on all the most interesting and important software projects, you gotta know your C++.
I feel the same .
There are more car Maintenance Mechanics than there are Mechanical Engineers building cars. That doesn't mean that Mechanical Engineering is dying. I think the same principle applies here. There are still C language developers maintaining drivers and kernel for compute devices. I think C++ has found its niche. It is not the tool for all scenarios.
Yep. Finding a solution effectively is a matter of matching tools and skillset to each problem, like basically everything else in life.
C++ is dying, yet C++ conferences are getting more popular and more expensive to attend.
According to Bjarne people have been saying each year that C++ is dead up to 40 years now and it's still going strong
C++98: releases
Random 98' people: C++ is a dying language
Thank you for sharing Jason!
When a language is not updated, then it can be said that it is dying!
C++ has no any sign of death!
C++ will never die, because we all love it so much!
Sean Baxter's Circle seems like a solid path towards evolution. The dude has implemented nearly every feature of Rust and all sorts of safety/defaults fixes.
Yet another C++ compiler would not help with the problem because of existing codebase, with c++ you can only use Rust to get the Rust experience, no compiler can save your external code.
@@foxwhite25 When you complain about rusts immature ecosystem, you get told to just bind to a c++ library. How is that any different?
Thanks for the 400 episodes of C++, I really like the language. The company I am working for uses all sorts of languages, C++, C#, Java, Kotlin, Python, and type-script for different purposes, they are just like wrenches and screwdrivers. It is a matter of how fast people can loosen or tighten the screws. But I still do not like Java, and happy to see Kotlin is replacing it on Android which is one of the most significant application scenarios for Java. I am pretty sure Google already realized its fault and corrected it in Fuchsia by not using Java at all :). Ast to C++, I really wish someone could use AI to filter the error messages yielded by the compiler, especially those template-related errors.
I'm pretty sure you can just paste an error into chatgpt and ask it to simplify it, and you will get pretty far.
I've spent over 30 years writing C++, where much of my work has been converting Perl, PHP, Basic, C, C#, Java, Python, and assembly language code to C++ in order to improve performance and reduce memory consumption. In that process I typically improve reliability as well. I suspect there will always be a need for "a portable assembly language with some cool features", and C++ works for me. 🙂
Happy 400th! Thanks for making this beautiful language even more exciting, interesting and more beautiful! ❤
🎉
The only people saying "C++ is dying" are people trying to get you to use _their_ language.
Meanwhile pretty much every language that _isnt_ C++ is implemented in C++.
In the visual effects world, almost everything is C++ or Python talking to C++. The amount of code is staggering.
C and C++ is the most portable. As someone who brings up new systems from scratch building new Linux systems all start with the c/c++ tool chains. Asking if C++ is dying is like asking if bricks are dying because someone is building wooden houses. 🤷♂️ it's a pointless question.
Thanks for making this video Jason. C++ is my first programming language that I learnt in my high school. Still my favorite programming language. During my high school, for some reason, we were taught very old Turbo C++ (in 2011). It was challenging to learn it, but in the end I managed to make my first ever project. I had no idea about modern C++ until late 2014. But learning modern C++ gave me relief as otherwise I would have to force myself to learn and use Java. My first job was in C++03. But gradually I got a chance to use C++17. Hopefully in future I will get a chance to use C++2x and use more modern features.
I have no idea what your background is, obviously, but I've heard this story of being taught Turbo C++ in recent years from many people in Indian schools. I'm hoping that trend is changing! Turbo C++ didn't even implement namespace std yet.
@@cppweekly Yes that's correct. Hopefully it has changed now and they are teaching modern C++.
@@kinershah464they didn't change it, but removed c++. My batch was the last batch that had to use borland/turbo c++ compiler.
Now they teach python.
C++ is still strong. And Herb's project is amazing!
I worked on a team that prohibited the use of C++. That could be incredibly restrictive when working in domains for which many of the ready-made solutions were already available as shared C++ code. They wanted some image processing program put together, instead of using a C++ open library, they wanted us to use some other open library that could run in a browser. That other open source library used Web Assembly compiled from C++. I wonder if the managers would have chosen differently had they realized.
Most mobile network code GSM->5G and ORan is written C++
Excellent video! C++ is still the standard for most game developer jobs, especially for Unreal Engine's blueprint being C++ based
Unreal Engine is an amazing game engine, blueprints with C++ make it so powerful. Got to experiment with it recently, amazing engine.
A director of engineering I know, located in Silicon Valley , told me that he can’t find c++ developers for embedded systems . The company has an exciting product and pays very well. But can’t find candidates to interview. (Not defense related)
Congratulations on 400 episode!!,
As long we have video games,c++ is not going anywhere 😊
The main problem of C++ is the usage of error prone C features. The C language features should be switched off by default. Many of the vulnerability is coming from C code. Also the lack of standardize ABI of C++ is a big problem. For shared libraries the primitve C API is used.
I learnt ANSI C back in 1988 from K&R as a kid. Later I haven’t used it for 25 years, but last year I learnt C++ at university (MSc Data Analytics UCD Dublin), and since then, I keep learning (and using) it as a Python and R extension. Maybe a standard package manager (Conan 2?) would be useful; and also a restrictive subset with modern syntax and safety features (Carbon? cppfront?) which could empower application developers to write safe applications with it could also help.
Also, constexpr and consteval pre-computation of large portions of a program that would otherwise run at runtime, in the field on multiple machines? constexpr and consteval are green technology.
Haha this warmed my heart. I agree with all arguments. C++ has insane pedigree at this point and the language and stdlib are evolving. I love knowing that I can use the language in absolutely any context from embedded controllers to distributed HPC. There's longevity in that capability alone.
Congratulations on Episode 400, Jason!!!!
400 weeks straight!!
People like to hate on what they don't understand, someone's gona always have to know the language in which everything is made.
7:41, paused here to point out it's perfectly possible to program in ANY language (including asm or even machine code, not that I'm insane enough to try), basic integers and floats for starters are pretty much always gonna be memory safe when used with the basic operators. For buffers you just need a guarded page to copy it to, edit, then copy back. By guarded I mean a set of at least 3 contiguous pages, the 1st and last are to be read only, this enures segfaults if things go south. The middle page/s are for the copied buffer that's being edited/read from, once done the bytes expected in the actual buffer will be copied from the page into the buffer without ever touching the externals of the buffer. So here's a VERY rough example in pseudo code:
vm = newguarded( bufsize );
memcpy( vm, buf, bufsize );
modify( vm, ud );
memcpy( buf, vm, bufsize );
delguarded( vm );
Naturally there's quicker ways to implement this but it gets the rough idea across
The hype I had in your last argument it comes from a c++ fangirl. But it will take a while until imports become normal. But they promises so much in time saving I just love it, and I think it will make a revolution to C++. Also, I also think that we may see some mixture in the future like half project in C++ the other JavaScript? Maybe. Something to speed up the writing process.
Don't know but C++ feels live and C++23 sounds more promising than chatGPT.
“Girl” or girl ?
I find curious that you don’t mention Odin and Zig. I think those 2 have a higher potential to at least complement C++ than Carbon or Cppfront. I don’t think we need a C++ successor to kill C++ and I don’t think C++ will die any time soon. However, I believe we should be more vocals with the committee about the many fixes C++ needs to make our life better. I think it’s useless to add new syntax every time we have a new standard when we still did not fix fundamental flaws of the language.
Seeing the title, my immediate reaction was "no, it is not a death; it is necrosis". Once something gets into C++, it always co-exists with the old approach. To make things worse, the new approach will not work for every use case, and there is always some circumstances where you must get back to the old approach. Let's be honest with ourselves: C++ has been and will continue to be a total mess of half-baked features.
For example, references and pointers. References cannot be null, cannot be rebound, must be initialised immediately at declaration, and cannot do pointer arithmetic. Arrays decay to pointers. Even `this` is a pointer (despite it can never be null, need not be rebound, is initialised automagically, and you rarely need pointer arithmetic on `this`; i.e., it could have been a reference).
For example, char arrays, char pointers, null-terminated strings, std::string, std::wstring, std::u16string, std::u32string, std::u8string, std::string_view.
For example, plain arrays, pointers, pointers/references to arrays, std::vector, std::array, and of course the notorious std::vector.
For example, exceptions, errno, return codes, std::optional, std::expected.
For example, global statics, anonymous namespaces, private module members.
For example, implicit casts, C-style casts, static_cast, dynamic_cast, const_cast, reinterpret_cast, std::bit_cast.
For example, default initialisation, aggregate initialisation (designated or not), zero initialisation, copy initialisation, move initialisation; with curly-braces, with parentheses, with equal signs.
And many more.
C++ needs not more new features, but a thorough clean-up to regain simplicity and consistence. But apparently it will not happen, and every one is still working hard to add more half-baked features and compromises into it. In conclusion, for new projects, forget about C++ and choose a sane language to work with.
As long as people are writing API libraries for modern and emerging services in a language, it's not dying.
sigh of relief - I can continue to report to work and continue working on my C++ green field project (started in year 2023)
thanks for clearing this up - that I don't need to start deleting C++ compilers and toolchains off of my computers
:D
yep, I think all of your thoughts are good.... While c++ may not be the most "glamorous" it is still at the core of many aspects of "computers" around the world. Also, you didn't even touch on embedded/hardware stuff!
When you mentioned the c++0x flag, it brought back memories :-P
I think you missed the point. It seems to me that the C++ successor languages are being developed because the C++ language itself has gotten so complicated it's completely unmaintainable, the language itself has built up 40 years of technical debt. People starting new projects *could* use the features of modern C++ (including C++ 23 features), but then they get saddled with all of the wide variety of edge cases that C++ has. Alternatively, they can use a more modern programming language that, as of the current moment, has fewer edge cases and more safety.
C++ is certainly going to be around for a long time in the future just based on the number of projects using it, but I don't think many projects will adopt a modern flavor of C++ as their primary language. I say this as someone who got into programming by checking out a C++ book in highschool around 2010 and still uses the language frequently.
Excellent point.
there are things I really don't understand in language evolution, especially caused by programmer coming from other worlds.
Like why should we write upfront functions?
Why
auto main()->int
and not the 40 years functioning
int main()
?
Where is the advantage, other than confusing people seeing the most common version since forever?
Its certainly not dead in games programming!
Bjarne's cfront, emitted C code. That is you wrote in C++, fed that into cfront, and cfront would emit C code that a C compiler would compile and link. cfront reached version 3.0 which I believe tried to support templates.
Your video was great, but I think you should have mentioned the importance of C++ in embedded systems too, that will make it hard to die.
It is very important in embedded - but there's a surprising number of people who still think that C++ cannot be used in embedded because it's "too slow"
I am biased, as I use C++ exclusively, and have used it for about 22 years.
I am not a professional, though, but basically a hobbyist.
The thing that strikes me about all of these new languages is they either look like Rust or they look like C#. Both languages and any that are similar suck so much and it boggles my mind how often they're copied.
Mojo is, to me, the most interesting potential replacement that I don't see discussed as a successor. Chris's track record is as solid as it gets, and the language's focus on multi-core, multi hardware could lead to large applications being authored in Mojo. I don't know yet how low level it will go, whether you'd be sane to write a driver in Mojo, but there's a tonne of overlap in complex applications where able wasting less cognitive capacity on language structure/quirks/history will be a big win.
I've never heard of Mojo, but I'll check it out. Thanks!
Oh yea! Live long and prosper C++!
I think both Java and C++ will not "die", just like COBOL and Fortran are not dead. However they probably will become legacy languages, so that most of new projects made will be in other languages like Rust, Carbon or Cppfront(which sort of is c++ or "cpp2.0" and classic C++ will be a language used to mantain legacy software.
Rust really isn't designed to supercede C++ unlike what most people think, cppfront and Carbon would be more likely, but given they rely on C++ to exist, C++ really doesn't seem to be going anywhere.
@@Spartan322 That's true. C++ has indeed reached the "threshold of immortality". The question is will C++ still be the go-to language for high performance application software and system software. That remains to be seen of course. But it's getting some stiff competition for sure!
@@torarinvik4920 I think for now at least, none of the alternatives are all that compelling, many of the modern ones tend to either be overly safe to the point of a struggle to deal with or they intentionally remove features that are commonly used for solutions in C++ that simply don't have an analog in the other languages. From the folks I know and seen in high level infrastructure development, say like aerospace and security contracting, they still start new projects in C++, there's simply no alternative, there are folks even I know who still have to use C for new projects occasionally like for video codec development.
I think the answer to this question depends on how you define "dying" for a programming language.
If you define it as "won't be used anymore", Cobol is still in use. The death of EVERY language which at some point was popular NEEDS to be measured in multiple human lifetimes. That makes it very hard to track if one is dying or not and currently, I would say no.
If you define it as "less and less NEW projects pick it, even for an area where it was originally very popular", then it's considerably harder. And I don't know of any data which can support either side. But considering the way regulations work and are reformed at this point (especially thanks to government agencies which want to limit the use of language where memory bugs are easy), I could see this happening to C++ in the coming years. But as I said, this goes for NEW projects, not existing ones.
Thank for video. C++ can't die because of this channel.
I personally don't see C++ dying around me in the professional world, although maybe it is not always the predominant choice for fresh new projects anymore. True, many people have predicted the death of C++ in the past. What feels different to me this time is how many well-known figures of the C++ community seems to believe it is so. As you said, there's ADSP, with Bryce, ex-chair of LEWG, saying C++ is dead, there's people like Nicolai Josuttis and Kevlin Henney that said it on a panel at ACCU 2023, you have people like Herb Sutter, Kate Gregory, Chandler Carruth, Dave Abrahams and even Sean Parent at some level that move their attention to successor languages... Non-rhetorical question: did this happen before?
I wouldn't consider Herb's cppfront to be him paying more attention to a successor language, the others maybe, thought they're too reliant on C++ and the development of C++ to say that anyone can get off of it. And there's still a lot of new projects that start on C++ when they needing something lower then C#.
C++ will only “die” when it has a clear descendant take over for it, like it did for C. A “C*” so to speak. And even then C isn’t dead; it’s just the programming language counterpart of Latin, a language still used but no longer being significantly modified/updated.
Rust is too different and currently limited in its own ways to be a full replacement. My guess is that we see C++ de facto forked into several possible successors like Circle vs. Cppfront, and depending on how that played out it might replicate the early era of C successors where C++ competed with things like objective-c before ultimately winning out.
Hey i am new to programing and want to learn c++, can i ask, with what video should i start in this channel?
th-cam.com/play/PLs3KjaCtOwSY34fFKyhOFovFlB7LikDwe.html
Hopefully!
> c++ modules hello world
I wish it was that simple. But modules is a major pain point across different platforms and compilers. And sadly it still lack features many want the most - to make them usable like python/rust with objects and templates not just namespaced functions.
Herb's CppFront looks the most promissing, basically what I have suggested for a while, that cpp is not obligated to mollycoddle 30 year old code bases. If they want to sit on their thumbs and make zero effort to refactor or upgrade than they can just set --std=C++98 on their compiler and forego the modern features. Even then it would only be for that one old compilation unit, the linker just sees assembly/binary/intermediateLang and doesn't know chunks started as C99 from g++23 from Fortran.
Hello. Thank you for video. As I know some IT giants like Microsoft recommend starting new projects in a Rust. And on the last graph in your video, we can see that rust is really growing now. So it could be possible that Rust will replace C++ in the future(but not nearest), because of a lot of existing C++ code as you mentioned in the video, and you can not replace all this code at once.
What do you think about this?
Obviously, I'm still using C++ 😂 My main programming tool since the 90's. I see no reason to switch to anything else.
It's a crying shame that they're so adamant about not fixing core problems that would allow them to make the improvements needed to modernise the language.
No pattern matching, no discriminated unions, no standardised package manager, no compiler backing you up on safety concerns ala Rust. I can see why newcomers might ignore it over languages with superior tooling.
OMG - carbon-lang reminds every Apple developer of the past... 😆
Carbon was the compatibility layer introduced in classic macOS to facilitate the move to the UNIX based macOS / OS X
It's ooooooold...
At least re: language design, it's not grow or die. Ideally, the core language gives enough that people can define whatever else they need from there. Language designers must aim to put themselves out of business. If you were told C++11 could either have lambdas or foreach but not both, which should you choose? IMO lambdas because you can approximate foreach by std::for_each + lambda, but not the reverse. Once we have lambda, the core language is freed from needing to support every looping construct.
So if the core language is not growing, are we failing to keep up? Or did we put ourselves out of a job? For C++, i think it's both. The past decade of improvements does mean we can express a lot more inside of C++, like how variant and tuple are in the standard library, not the core language. But there is no satisfactory way we can build reflection using standard C++, and, lacking reflection, there's a lot we cannot do, (hence every game studio making their own code generator to work around this).
5:48 Hylo dropped the goal of C++ interop some time ago (before even the name change I think). Circle was worth a mention though.
I started learning C++ at the beginning of 2023 ... so it cannot and must not die 😉
It will not. It is all BS that it will die. Every 3 years, there is a new ISO C++ standard. The mulithreading support is impressive.
C++ is not dying, it is me dying learning modern C++ at my 40th...
not sure about the death of c++.. in fact, i think the problem of c++ is two fold: (1) should it rather be called ++c (its faster)? and (2) to resolve the most vexing parsing of what c++98 really means; 1998 or 2098?
C++ is language which have own market niche and thats it. Game devs using it from time to time.
Congrats for the 400episodes!
"virtually every database engine is written in C++"... Look at Postgres, Redis, SQLite... Other DB engines that are written in C++ usually use a subset of C++ that is very close to C (and described as C-style).
SQLite is written in C.
The main problem with C++ is that it is such a slow-moving behemoth with far too many cooks steering the ship. Changes take years to go from an idea to a proposal to a standard and then years longer to actually be implemented in all major compilers.
It tries to be everything to everyone and is pumped full of cryptic features.
It was too complex for its use in the 90s and it certainly is too complex today.
Instead of adding features, it should have been replaced with a "light" version that kept the essentials and making it easy to understand and work with.
The hardware landscape has changed quite a bit too, so threading, resource locking and data access/databases should have build-in constructs for them.
@@TheEVEInspiration _"It was too complex for its use in the 90s and it certainly is too complex today"_
Or you can just do classes, templates(very sparingly when needed), and do shared_ptr and basically write C# by passing by reference with shared_ptr.
@@KulaGGin I deliberately limited myself to the features I really needed. That worked fine for me, but still I found that upwards of 90% of the colleagues programming in the same language were unable to cope well with even that. So I was spending a lot of time unraveling and fixing other peoples code. And I can say with certainty, the language was too complex.
@@KulaGGinOh and don't get me wrong, I loved the language. Especially the predictable constructor/destructor calling for local objects, which could be utilized to do write very safe self-cleaning code, regardless of branch complexity.
In a new language it is something I would expect to be there and even expanded upon (one of the reasons C# sucks, it's broken).
Not allocating on the stack, but still following destruction upon call-stack unwinding for example, without smart pointers and such additional constructs. It is one of those needless complexities C++ is burdened with.
@@TheEVEInspirationyour 2 last sentences dont make sense at all
I feel like the argument of "there's already millions of lines written in cpp, we have to keep it alive!" is like saying "we have to keep burning gas because there's already millions of gas burning cars! We can't make electric cars!". Imagine how many latent vulnerabilities and bugs there could be in all of those millions on lines. Look at the work at Google and Microsoft where they are rewriting critical portions of their stack in memory safe languages, and trying to get rid of their c/cpp.
It was one of the greatest video that i've ever seen.
How low is your bar, damn
I know most of those charts are really directed at people looking for jobs so I can see why they lump everything together. However it is not a good way to compare languages because it is expected that there will be more volume of programming in front-end interpreted languages than in backend infrastructure languages. The whole point of the interpreted stuff is quick turnaround and temporary solutions. Companies want a fresh website look every month but they want a mainframe processing transactions to be stable for decades.
But that website bling is non-critical either in reliability or hardware efficiency (each line of code is low value) so they will tend to throw a bunch of cheap labor at it. While the development work for the mainframe is likely to be done with a lot of testing and optimizing along the way (each line is high value).
C++ is everywhere..
c++: There's already a well known way to do X
also c++: let's confuse our devs instead of helping them by mandating Y instead just because we don't like c despite inheriting everything from it
C++ isn't dying, but there are big questions about where it's going and how it's going to get there. C++ language evolution has some very very difficult questions to answer, and not everybody is happy with the Standard Committee's current answer. I don't think C++ will die, but the community may fragment which would be a great loss.
C++ isn’t dying, it users are. They are old
@@Fareoneo My C++ team is 2/3 under 30. There are new C++ developers.
@@FareoneoHey! I resemble that remark! 😁
@@szaszm_ I've found this to be the case as well, but of course this is just my anecdote. Regardless, the data seems to reinforce this stance as well
Crazy? I was crazy once. They locked me in a room. A C++ room. A C++ room with UB. And UB makes me crazy. Crazy?...
How many compilers work with `import std;` and how many of them let me write custom non-`std` modules? And for that matter how many have full format support; I think last time I wanted something fancy it wasn’t supported anywhere
Yes, it's a work in progress, but that's not the point. it will get there soon.
Are we losing cout? I ended up taking a long break from programming & C++ 'til recently, and only now got used to namespaces!
Not losing it, but there's just no reason to use it anymore. std::print is faster and easier to use.
@@cppweekly well allright. Now that I think about it, I've been using cout less once I started doing graphical stuff like SFML and the Godot Engine, so maybe I won't even miss it.
I don’t think C++ is dying. Everything else essentially uses C++ as the backend language, so until that changes C++ will live on.
I will say, the committee should try and push for C++26 being the next C++11, which I think would revitalize the language. C++20 modules, ranges, and coroutines were huge additions but incomplete and C++23 and 26 are picking up the slack.
Adding Contracts, Pattern Matching, Static Reflection, and removing the need of the PreProcessor I think would be the necessary requirements to grow C++.
Thats already too much stuff i don’t want to have implemented that way.
First, we need to see a wider adoption of modules, both in terms of compiler implementations and libraries. The #include travesty must stop!
VSC still doesn't support C++23 yet. As an aside, I see more videos showing interest in new languages than I do C++ videos. Yes, C++20 has a lot of new features, but it's very easy to get wrong and still hard to write memory safe and bug free code. It's also difficult to keep up with all of the new features and changing syntax.
C++ is "threatened" by some countries, for some industries, but it is far from dying. So much code would have to be converted, it would take decades.
I lile c++ but it interstingly when using the cutting edge language features, specifically auto return types, deducing this and utf8 strings i find that c++ looks a lot like rust. This is why i consider rust a successor to c++ that cleans up the legacy mess and makes meaningful defaults.
Autodesk 3ds Max
Maya
Blender
Houdini
AutoCAD
SolidWorks
Fusion 360
Nuke
Substance Painter
V-Ray
…
Your asss is dying!
This is an almost completely unqualified opinion, but here we go: You already mentioned that C++ is used in pretty much every system that needs to be reliable, and this fact alone is why it will probably take decades for it to fully "die", whatever that may mean. It reminds me of how there are still people needed to maintain COBOL systems because they are so crucial, and it seems likely that C++ will have the same thing happen, just much more pronounced due to how widespread it was for decades. We might see a downwards trend in new projects being built on C++, but even that may take years to fully develop. In the meantime colleges will still be teaching C++ in a lot of courses so the supply of fresh C++ users is also not stopping anytime soon.
The irony that the final example is basically just Java. Massive improvement there, boys. Good job.
or c, C had printf function
C++ is the base for everything, so if you want to replace it, needs to RE-Build a new technology.
How many meetings to decide what to change/add to get another look of "hello, world!" ?... Let's refactor everything !
Nice seeing a 400th episode ! I'm not the sharpest C++ coder, but I like spending time here from time to time, always learning something. Even if I hate templates ...
I encourage you to spend some time with templates and get over the hate.
That or just use `auto` function parameters and let the compiler write the template for you.
In many cases it truly is the best option for performance and correctness, while avoiding implicit conversions and runtime type checking.
I've been programming professionally for about 30 years now. And guess what? C++ has been "dying" for most of that period, or so they say.
"What have I proven here?" You've proven that inertia is a thing.
Major desktop apps are written in C++. But most of the programming now is on the web. Where does C++ stand in web apps?
C++ is used in a LOT of web apps as well. If you really care about performance there's a good chance you're using emscriptem
@@cppweekly I was referring to the server side. I believe PHP, Ruby and Python are used for small sites. And companies internally and larger sites externally would use Java and C#. I think Facebook and Google and other mega sites use C++ for high traffic applications.
There is also mobile with Swift/Objective C being the Apple preferred languages and Java/Kotlin being the Google preferred languages. Unfortunate that the market can only handle two OSes because Blackberry was going with QT and C++ and I think Nokia (Symbian/Linux) was as well. But Windows Phone was C#.
@@lockbert99i think they'll eventually switch to HTML instead.
17:33 I'd like to see the same chart, but with % over all programmers rather than just raw programmers count
stayin' alive, stayin' alive
To me it seems c++ is popular because its so ubiquitous. We have a lot of old c++ written, most importantly pre c++23! While i dont think its dying, its also not going to grow significantly anymore, which may change in the future if c++ can drop its legacy cruft.
Good luck finding someone willing to pay for decades of rewrite & debugging of that "legacy cruft".