Comment by anacrolix
1 year ago
This is actually accurate. While Rust is a great replacement for C, so is C++. But Rust has tons of extra features that C doesn't have, just like C++. Moving from C++ to Rust is a sideways move. Moving from C to Rust is definitely an increase in complexity and abstraction.
Rust is a great replacement for C++ as it fits into the same place in the stack of tools.
Go is not a C or Python replacement.
Zig is a good replacement for C.
> Go is not a C or Python replacement.
Google stopped writing new Python, because they found that the same engineers would produce software with similar defect rates, at a similar price and in similar time, with Go, but it would have markedly better performance, so, no more Python.
Go manages to have a nice sharp start, which means there are going to be a bunch of cases where you didn't need all the perf from C, but you did need a prompt start, so, Java was not an option but Go is fine.
In my own practice, Rust entirely replaces C, which has previously been my preferred language for many use cases.
> But Rust has tons of extra features that C doesn't have, just like C++.
C++ has tons of extra features over C because it's a kitchen sink language. Rust has some extra features over C because in order to support static analysis for memory safety in a practically usable manner, you need those features. In practice, there are lots of C++ features that Rust doesn't bother with, especially around templates. (Rust just has a more general macro feature instead. The C++ folks are now on track to adding a clunky "metaclass" feature which is a lot like Rust macros.)
Every language becomes a kitchen sink with enough time on the market, even C, people really should learn about the standard and the myriad of compiler extensions, K&R C was almost 60 years ago.
C++ already has almost Rust macros, with a mix of compile time execution, concepts and traits, without requiring another mini-language, or an external crate (syn).
> Every language becomes a kitchen sink with enough time on the market,
Sometimes they remove stuff, and then everything written before a specific date stop working.
I've used Rust quite a bit now and there are too many features. It can't claim to be tidy anymore. Sure it's a better situation than C++, but it is getting worse and unlikely to get better.
> Moving from C++ to Rust is a sideways move.
In what sense? Features or complexity? From a productivity/correctness perspective, Rust is a huge step up over C++.
While I agree, that isn't much the case for those using static analysis, and hardened runtimes, which provide much of the same safety improvements, granted without lifetimes tracking.
Use more xcode, Clion, Visual Studio, C++ Builder, and less vi and Emacs for C and C++.
Not everyone has the RIIR luxury for what we do.
Those things certainly help, but as someone who actively maintains a lot of C++, I'll stand by my claim that even with those added tools, Rust is a very large upgrade in both productivity and correctness. I'm not claiming all C++ should be RIIR. But you won't find me starting any new projects in C++, unless compelled to do so.
1 reply →
> Zig is a good replacement for C.
I have never used zig, although I have looked into it. I have used C and C++ for a long time, and would like a replacement for C.
To my mind zig is nowhere near a good replacement for C. It adds way too much extra stuff (e.g. metaprogramming). A good replacement for C would have a similar simplicity and scope to C (i.e. a portable assembler) but address known issues. For example it should fix the operator precedence rules to be sane. It should close-off on undefined behavior and specify things more formally than C, and still allow low-level memory manipulation. To be even better than C it should allow stuff that would be obviously correct in assembler, but is UB or ID in C.
Go has plenty of bad design decisions, but not being a safer C isn't one of them.
TinyGo and TamaGo folks enjoy writing their bare metal applications on embedded and firmware.