21–30 of 44 posts
Its important to note the article was published on April 1st.
If by "April 1st" you mean "August 4th", then absolutely. I mean if you say them both fast they kind of sound vaaaaaguely similar...
https://www.think-cell.com/en/career/devblog/should-we-stop-...
Earlier quoted context omitted.
It simply has too many upsides and is way too popular to be replaced with either - a simpler language that does less - a less popular language - a more verbose / restrictive language If you want people to switch to something better, make something better . Its not enough to simply call out the issues (which is valid, but not useful anymore), and it entirely dismisses that replacement languages like D (small, less act…
I like the idea of Rust, the tooling, the package manager (far more better that what you can find in C++). What you are saying is true: I've been writing high performance scientific code and desktop gui apps. I would love to use Rust for my projects, but it just doesn't cut it. The libraries I am using are very mature in C++, but the libraries in Rust to accomplish the same thing are still too immature to consider in…
Also, can you not use these libraries from Rust?
This kind of post is why I do not understand C++ programmers whatsoever. It's basically a demonstration of the absurd amount of time C++ takes away from you by being the moldy pile of shit that it is. You want better compiler checks and less freedom? Great, me too. Can we please shut the fuck up and use a language that actually supports that?
Millions of professional C++ developers work on large scale mission critical C++ code that control everything from airlines to Fortune 500 companies to cars to nuclear reactors to military hardware. And new C++ projects are started every single day.
Most developers have zero clue on what it takes for a programming language to be successful in the real world. And they have zero clue on how much $ and time it would take to rewrite the billions of lines of C++ code out there that runs the world.
Earlier quoted context omitted.
>If you want people to switch to something better, make something better. We already have C, which is better. It existed before C++. It will exist long after C++ is dead. If you don't over-architect and over-abstract your code you can be more productive in C than in C++ precisely because you avoid the kind of nonsense that this article (and the endless other articles about overcoming C++'s shortcomings and cognitive…
No, C is not better. C is much worse. C lacks basic primitives that allow programmers to do useful abstractions and let them concentrate on the business logic rather than on the low level details of every functions. You maybe can write small program easier on C as long as you can fit everything in someone's head. And that's why all complex low level programs are written in C++ and not C. (With the Linux Kernel being…
I explained why it doesn't matter that "C lacks basic primitives...". C has the basic primitives. It lacks generalist containers, for example. But most of those 'generalist containers' are, as I already explained, just not very good. For example, take this post:
https://zeux.io/2023/06/30/efficient-jagged-arrays/
What do we see here? The guy starts off with basically 'normal C++' and what he has at the end if essentially something you could write in C. When you optimise C++, you end up getting C. He has two std::vectors, but they're pre-sized so they're essentially the same as writing 'unsigned offsets = calloc(vertex_count + 1, sizeof offsets);'. This is not any kind of significant boilerplate.
The low-level details are something you NEED to concentrate on. If you don't care about the low-level details, then you shouldn't use C or C++. That's the point of low-level languages: control over low-level details.
All complex low-level programs are written in C. C is used in every production operating system kernel. C is the language in which systemd is written. It's the language in which pretty much every production web server or network server is written in. It's the language used by pretty much everyone interfacing with hardware.
The Linux kernel isn't an exception. It is the typical case.
>And what about the drawbacks mentioned on the article? 99% of programmers don't need to care about them.
The drawbacks mentioned in the article are major issues. They regularly bite C++ programmers, and are always lurking. You can't just say '99% of programmers don't need to care about them'. The whole point of namespaces in C++ was that you didn't need to care about name clashes. The result of argument-dependent lookup is that instead of getting a linker error on a name clash, like you do in a sane language, you instead can get random weird functions being called, silently.
>Uh? To adapt and evolve to a changing environment. Instead of stagnating and becoming irrelevant.
You've missed the point. You say C++ is so wonderful, but it's one of the languages that today is changing the most in idiom and specification. Since C++11, we're constantly being told about the new 'proper' way of doing things in C++. They're adding new features then going 'oh actually that was a bad idea' in every new revision. If it were so great, why would it be changing so much?
None of its changes are to 'evolve to a changing environment'. In C++11? Sure, they added threads, they added atomics. Pretty hard to argue that it wasn't an evolution to adapt to the new multithreading world. But today C++ still doesn't even have a networking API standardised. It still doesn't have a decent filesystem API. It can't even adapt to the world that existed when it was FIRST standardised, back in 1996. How is anything they're doing adapting to the world of today?
---
Really none of what you said addressed anything I actually said.
Earlier quoted context omitted.
I like the idea of Rust, the tooling, the package manager (far more better that what you can find in C++). What you are saying is true: I've been writing high performance scientific code and desktop gui apps. I would love to use Rust for my projects, but it just doesn't cut it. The libraries I am using are very mature in C++, but the libraries in Rust to accomplish the same thing are still too immature to consider in…
Out of curiosity, what are these libraries that are missing equivalent in Rust? Also, can you not use these libraries from Rust?
Anything related to HPC and HFT, CUDA, game engines (Unreal/CryEngine/Ogre3D/Godot vs Bevy), Qt/WinUI/MFC/VCL/FireMonkey/wxWidgets/KDE, COM/XPC/Binder, compiler frameworks (Graal/GCC/LLVM).
Yes, many of those could be used from Rust, some of them already are, provided there are bindings, then again it is the classical question if one wants to maintain bindings, or write the application they care about.
Earlier quoted context omitted.
It simply has too many upsides and is way too popular to be replaced with either - a simpler language that does less - a less popular language - a more verbose / restrictive language If you want people to switch to something better, make something better . Its not enough to simply call out the issues (which is valid, but not useful anymore), and it entirely dismisses that replacement languages like D (small, less act…
>If you want people to switch to something better, make something better. We already have C, which is better. It existed before C++. It will exist long after C++ is dead. If you don't over-architect and over-abstract your code you can be more productive in C than in C++ precisely because you avoid the kind of nonsense that this article (and the endless other articles about overcoming C++'s shortcomings and cognitive…
Earlier quoted context omitted.
It simply has too many upsides and is way too popular to be replaced with either - a simpler language that does less - a less popular language - a more verbose / restrictive language If you want people to switch to something better, make something better . Its not enough to simply call out the issues (which is valid, but not useful anymore), and it entirely dismisses that replacement languages like D (small, less act…
>If you want people to switch to something better, make something better. We already have C, which is better. It existed before C++. It will exist long after C++ is dead. If you don't over-architect and over-abstract your code you can be more productive in C than in C++ precisely because you avoid the kind of nonsense that this article (and the endless other articles about overcoming C++'s shortcomings and cognitive…
You could make that argument about almost any technology (certainly in the IT world). C23 is out this year which will make it the 6th "official" version - obviously a much more slowly evolving language than most, but nonetheless still being fairly regularly "updated and extended".
There's plenty of things I don't care for in C++, but I can (and do) choose not to use those parts. The few times recently I had to work with pure "C" code felt, well, decidedly primitive - but there was no choice but to grin and bear it. Which works great for some contexts, but I'm not sure I can imagine tolerating it for large-scale application development.
Earlier quoted context omitted.
That's a brave argument I'd rarely make of "We could do this thing with major tangible benefits but our Devs might find it a bit hard"
Why aren't we writing everything in assembler? It's so much faster! There's a huge number of business process where execution time is almost a non-issue. As long as the thing runs every day/week/month/quarter no one will give a crap. Development time, supportabilty, and onboarding time for new developers tend to matter way more for those sorts of processes. For things your shipping out to end users? Optimization and…
C++ is generally used by millions of people to whom execution time matters quite a bit. The language is literally designed to force the programmer to decide how to balance CPU cycles with language abstractions and features. It's already hard to debug compared with a lot of other languages (which are generally slower).
The fact that you (and GGP) rarely encounter situations where run time is critical is a limitation on your experience, not a universal law that applies everywhere.
So, context is really important here.
Earlier quoted context omitted.
>If you want people to switch to something better, make something better. We already have C, which is better. It existed before C++. It will exist long after C++ is dead. If you don't over-architect and over-abstract your code you can be more productive in C than in C++ precisely because you avoid the kind of nonsense that this article (and the endless other articles about overcoming C++'s shortcomings and cognitive…
> If C++ is so good why does it need to be constantly updated and extended? You could make that argument about almost any technology (certainly in the IT world). C23 is out this year which will make it the 6th "official" version - obviously a much more slowly evolving language than most, but nonetheless still being fairly regularly "updated and extended". There's plenty of things I don't care for in C++, but I can (a…
The problem is that it's a language that doesn't need to change much. It doesn't really need a committee. People that recognise this don't bother getting involved. That leaves it vulnerable to entryists.
You cannot pick and choose which C++ features to use in practice if you use any kind of library including the standard library.