I love how Eric Raymond describes it as "anti-compact", because, well, it really is. C++ as a whole should be deprecated -- and no new projects should use C++ (unless for some very odd and specific reason).
And what can be used instead of C++? C? If C was better, then C++ wouldn't have been invented. Rust? It's much more painful to use than C++. Zig? It's immature and has very low usage. Nim? Has very low user base. Julia? It isn't solving the same problems.
https://twitter.com/markrussinovich/status/15719951172335042...
Complex template meta-programming only if one is stuck in pre-C++17 compilers.
Learning C++ is like cycling from SF to LA. It starts easy enough and every day you’re making a lot of satisfying progress. But you have so far to go because of all the features and quirks of the language.
It’s probably easier to get started learning C++. But it’s also much faster to finish learning rust and be able to read almost all rust code. (Pin still scares me though)
I’m still not comfortable with Pin, UnsafeCell, raw FFI (lifetime and ownership handling across the boundary is tricky), and complex macros. But I also think that you don’t need to understand these at all to be an effective Rust dev.
I'm also curious what's difficult about pin in rust? It basically just disables moving of the object for the lifetime of the pin.
I understand the concept. It’s the syntax which trips me up. You don’t mark structs as Pin. You mark them as !Unpin. And then, when is it safe to pin_project fields? Every time I read the documentation I understand it for about an hour. 2 weeks later I need to re-read the docs again to convince myself I’m not subtly messing anything up.
I’ve also gotten myself in hot water writing custom Futures, trying to wade through the barrage of compiler errors at the intersection of lifetimes, Pin and async. It’s a lot harder than it needs to be. The compiler holes around GAT, async closures and async trait methods doesn’t help.
The big difference between C++ and Rust is what happens when you get something wrong. C++ has lots of undefined behavior and nasty surprises for the unwary. (I led a C++ project for a decade and saw it all.) In Rust, if you get something wrong, the compiler typically refuses to compile it. Which is also very frustrating, but the frustration is all up front.
This is admittedly quite different from the way people usually learn C++, but it makes sense on its own terms. It's much closer to how higher-level languages like ML and Haskell are taught, and people have successfully learned those languages in introductory programming courses.
Unless you're doing something really highly specific to C++ (like Cuda for instance or deep integration with big C++ codebase), saying that rust is painful compared to C++ is laughable.
Julia was designed from the ground up to have C level performance, and well written Julia code does that easily in throughput focused scenarios.
Julia's intermediate representation which it compiles dynamic code down to is statically typed, and any dynamism just manifests itself as the compiler waiting until the types are resolved at runtime before running again and generating new specialized code.
If your code is written so that the types are all inferrable, there's no pauses.
When cfront turned up, the first versions basically automated that suckage. C++ did get better, but it was still horrible compared to CLOS or Smalltalk. This was largely due to weirdness in how the constructor/destructor ordering worked, the giant bogosity that is multiple inheritance and a few massive other undefined behaviours that every compiler did differently, but I think at this point it's fair to point out the language is bad and things like C# are so much better it's not even funny any more.
C# is much better but still it isn't a systems programming language due to garbage collection. So while you can solve some classes of problems easier and better, it can't replace all of C++ use cases.
Writing compilers, linkers, running bare metal on embedded hardware are all systems programming tasks.
For most use cases Java is a better option. Very fast, without any of the pain.
If you truly must not have a VM (rare), there's still C. Perhaps rust.
Java doesn't force OOP in any meaningful way. I mean it does, in that you need to wrap all code in a class, but that's a non-issue (one line of code at the top and a closing bracket). You can write Java code where all functions are static and do nothing is object-oriented, when that's the best match for your needs.
On verbosity, you can latch on to the ConstructorAccessorMapFieldGetterFactorySingleton nonsense if you want but that's on you. Nothing in the Java language forces that on anyone. Having been writing Java code since 1996 I've never written such code.
My rule is that languages are good if they have value types, which explains why PHP is good.
Those are quite different domains, with only minimal overlap.
Embedded systems more often that not are not seeking maximum performance. What matters is smaller code size and running on mimimal hardware. Java doesn't do so well there since you have the overhead of the VM. Java is rarely a sensible choice for embedded code. Just use simple C, or rust if it works for the use case.
(Yes I know project green was originally about embedded set-top boxes! But times changed.)
Performance critical systems are usually large servers for either high througput (web or other server traffic) or low latency (HFT) applications. The opposite end of the spectrum from embedded. That's where Java shines. You might be able to beat Java with carefully hand-tuned C++ but just as likely the JIT might beat you. So for maximum performance server code combined with a more sane developer productivity, Java cannot be beat.
Write a sufficiently complex memory safe program in C++. I dare you. It's been proven again and again that humans can't do it. And calling Rust more painful than C++ is just absurd.
That is totally easy.
What's not so easy, necessarily, is complex numerically safe program in C++ (that performs well).
You appear to have fallen for the Rust hype machine.
We do know many people at Google can't.
As someone who has used C++ professionally for two decades, I disagree. Rust's pain is superficial and all up front. C++ pain is death by a thousand paper cuts, especially if you have people on your team that aren't intimately familiar with its pitfalls and its more modern constructs. I don't plan to write a new C++ project ever again, unless there's some very compelling reason to do so. Rust is an absolute breath of fresh air.
It's quite a bit easier than Rust and no other popular language has its most important features (cross platform, interfaces with syscalls and other libraries easily, manual memory management possible, likely to be supported for a long time).
These things are useful in many situations.
For example, pre-computing values or parsing at compile-time.
This is useful for example in the following situations:
- You want to embed things at compile-time but keep things apart in a file. This file can be used at run-time when developing but is embedded and literally vanishes (you put your config directly in a struct) when deploying. - You do not want to spend extra time at compile-time. - No need to protect data at run-time with mutexes, etc.
The simplification it can yield is not immediately obvious. It can take a bit more work but the result is worth it. D is more powerful than C++ at this, btw.
I come from functional programming background, so I'm all for taking a little bit longer to make my code compile if that means it'll work. I'd rather deal with compilation errors than waking up at 2am to debug a stupid segfault.
this is not true anymore 90% of the time if you code with a decent knowledge... if you code C, then yes.
FTFY!
Too bold statement. There are still lots of reasons to keep using C++. LOTS.
It is, among worse things, damned rude.
There are lots. It is just that some ppl think real world is just like when they sit down to code a zero-dep, no time-pressure thing.
As such, it is in violation of site terms and conditions, and damned rude.
You are not your job, and prepare yourself for listening to honest criticism of the things you base your identity around or you will find it very difficult to learn and grow.
What was rude and, frankly, hateful, was the call to demote or lay off all C++ programmers.
Funny thing is I'm a C++ programmer myself right now as I mentioned :) Even if we decide to "deprecate" C++ today, Google alone would have large enough C++ codebase left to maintain for the next two generation of programmers.
So no, I don't think it means we should demote or fire all C++ programmers -- but at the same time I'd like to note that as a programmer no one should be married to a single language -- languages come and go.