These aren't alternatives and are strictly worse as far as language power and expressiveness goes.
There is some value in simpler and dumber languages, but your post essentially boils down to an anti-intellectual "programming is hard, let's go shopping instead".
Some people need complex tools to solve complex problems.
After years of being annoyed by Rust people claiming C++ is dying or too unsafe or whatever, I expected this to be another C# - a sort of C-with-training-wheels for people who care more about productivity than perf. Something I could safely ignore.
This ‘borrow checker’ stuff sounds great for kids, but for disciplined experienced C++ guys it’s at best a non feature and at worst would just get in the way, like GC, right?
In fact, I’m finding the reduced mental overhead (not just from borrow, but from the language as a whole being smaller and more consistent) is a huge win. Even learning the language and stdlib as I go.
I’ll still use C++ proudly where it’s the best choice, but I’d put some effort into trying Rust first. As a cpp-master-race guy, that surprised the crap out of me.
If your point was about explicit ownership being a little more tricky with self-referential structures, that's true, though the existence of std::collections::LinkedList shows that it's entirely possible to manage these structures and at least you still get the benefits of explicit ownership for the structure and the data within it.
I think the problem with this view is that Rust is not being used as a true programming language (like for implementing algorithms), but more as a "glue language".
If all the interesting stuff has to be done in libraries in "unsafe" mode, and all the uninteresting stuff (gluing) is done with borrow checking, then Rust is more a glue language. Which is fine. But don't call it a general purpose programming language.
Also, you seem to be suggesting that it's necessary to use unsafe code to implement these data structures in Rust. For something like the doubly-linked lists that were mentioned in an earlier comment, it usually suffices to use tools like Option and Rc for the links and to encapsulate the logic that manages those links inside functions like push_back and pop_back that you are surely defining to mutate your data structure anyway. Is there something specific you have in mind where this kind of strategy doesn't work and unsafe code is the only solution?
Trees are usually easy because each node has a single parent all the way up to the root and ownership can follow the same hierarchy. More general graphs are a little more tricky, but the same techniques that you can use to implement a specific case like a DLL generalise. For example, in Rust, you can combine Option and Rc to handle, respectively, the intermediate states while the structure is being manipulated and the shared ownership semantics.
You can do both in unsafe rust though. But you probably shouldn't no matter what high level non-GCd language you use.
/Another ex-cpp-master-race guy who has been impressed with Rust
However, if you're developing for embedded you'll probably want to be familiar with unsafe either way if you're going to use Rust.
Regarding self-referencing: Rust encourages you to design differently, which I've found leads to nicer and more thought out designs most of the time. Not all algorithms are possible (or efficient) without it though, and for those you'll have to use unsafe if you _really_ have to implement them yourself.
Specifically, the discussion about intrusive vs non-intrusive data structures and their frequency.
Though honestly, in C++ it is very rare I use something other than vector (potentially wrapped for specific use case, like boost flat_map)
(And yes, it's a niche data structure, vecs are far more common, but it's people's go-to "the borrow checker restricts you too much" example anyway.)
Seems a counter productive go-to argument given the amount of effort we (c++ coders) generally put in to avoiding non-adjacent memory access :)
FWIW I think the Rust community has done itself a disservice by focusing on the safety benefits. Const by default and move by default are much bigger deals in the day to day coding experience, but it’s hard to get across just how awesome they are.
That book looks great, thanks - should take me through a few corners I’ve yet to meet while keeping me entertained.
After 20 years of C++ and about the same number of hours of Rust, Rust makes me feel like Fire Mario because when I come to do a strict correctness and memory efficiency pass after writing something - it’s already correct. I suspect this will have a compound interest-like effect, similar to good code coverage empowering change.
Rust, like you said, isn't there yet. And I'd take issue with the claim that the gap has been shrinking - C++ right now is developing at a faster pace than Rust.
D is excellent overall (and I think sadly under-recognized for this), but it is lacking in ecosystem. Related to the overall topic of sum types, there is an excellent library, `sumtype` which recently hit 1.0 status.
I much prefer either of these to modern C++.
There is a near 1-1 mapping of types. C interop was a major design goal.
Dstep, which uses llvm/clang as a library, can translate headers for you. dpp I believe automagically at compile time translates C++/C headers.
Go with CGo is okay from a usability perspective but performance is poor. I haven't looked much at Rust's implementation so I can't comment. I've also heard Python is not bad.
The most obvious practical limitation is that ctypes can only infer so much about the required parameter and return types of the C functions from how you call them, so you have to specify the types explicitly in your Python code in any other case. That's no harder than writing a C header file, though, and I expect there is probably a tool somewhere that would automatically generate the corresponding Python/ctypes code for the common use cases.
There are a few other warts that aren't quite as intrusive, including some restrictions relating to pointers and some verbose marshalling if you're passing strings around. But overall, it's a very convenient way to call out to C-style APIs from Python code that probably covers 95+% of practical use cases with only minor inconvenience compared to what you'd have written doing everything in either language on its own.
const c = @cImport({
@cInclude("types.h");
@cInclude("stat.h");
@cInclude("user.h");
});Rust is coming along though. It’s the first language I have seen that might unseat C++.
Can you elaborate in what way? I was under the impression the amount of low-level control was equal.
[1]: https://benchmarksgame-team.pages.debian.net/benchmarksgame/... (these benchmarks are not representative of all workloads, but it gives you a general idea)
I think that is a bigger problem than using a language that gives you 10% less performance than C++. And anyway algorithms are typically are more important than the language in terms of performance.
Doubtful, as C++ has language standards and a visible, comprehensible story on how they evolve. C++ has also been evolving faster than Rust.
Right now Rust fills the "C++ with training wheels" niche - when you need a language in this space but don't have the energy or time to disentangle the sordid story of all the crufty legacy systems built around C++ after all this time.
But in principle if somebody made a well thought-out onboarding story for C++ then there's be little point in Rust.
P.S. But you say "my borrow checker" - well, sorry to disappoint you, people don't really care and actually view it as an impediment in learning Rust, not as a feature. If Rust had no borrow checker it'd be an even more popular language.
If you don’t see the value of compile-time memory safety in Rust, you probably haven’t spent hours debugging subtle runtime memory safety errors in a large C application.
I can count on one hand the memory errors I have debugged in five years. The longest took a half-hour. (Code that used a "relaxed" atomic load was moved to a place where it needed "acquire" -- which is the default.) So, I eagerly prefer (rounding up) 2.5 hours of debugging spent in five years over spending 5 extra hours every week -- 1750 hours in 5 years -- waiting on builds from a very slow compiler. (I don't know any reason why the Rust compiler could not be two orders of magnitude faster, and notably faster than a C++ compiler.)
My experience may be unusual in that I do not habitually depend on code badly-written by other people. My complaints about other people's code I do use are more typically about performance, conformability to requirements, or poor usability.
I could be wrong, but I would wager that you are definitely an outlier among C and C++ developers. For the remaining majority, I believe that the compile-time memory safety guarantees that Rust provides are huge.
As to why your experience is different, it could be that you're simply (1) a talented programmer, (2) work with talented programmers, or (3) don't work on a large and complex legacy codebase, or some combination of the above.
The people who choose Rust over C++ aren't (generally speaking, there are of course exceptions) doing because of the borrow checker. They're doing because Rust has Cargo and C++ doesn't.
I can make the case that in some circumstances like low latency requirements, C++ is superior to a GC language like Haskell. But it’s harder to make the case that it’s “strictly” better.
C++ is easy to understand when you understand the mental model its abstractions target.
(In some sense you're right: the mental model of Haskell is mathematical, while the mental model of C++ is some sort of multi-core "Harvard architecture" machine. While it's true that math is a lot easier for the human brain to grasp, this isn't really related to language complexity per se.)
(and from what I understand "Stockholm syndrome" is not classified as a medical condition because it's questioned if it actually exists as thing that can be usefully delineated, not because it wouldn't qualify)
I'm certainly not claiming "C++ is perfect and everything else is useless" or "Rust doesn't stand a chance", but this "there has to be something wrong with you if you use it/ever consider it more suitable" is seriously annoying, and disappointing to see as the top comment here (even if it's not the worst pro-rust denigration of C++-users I've seen). And is damaging the chances Rust et al have in these spaces.
>Suggesting everyone using C++ isn't capable of properly evaluating it (which the comment author can clearly tell from the outside, for every use case) is "not derogatory"?
I see it more as "I wonder if they have given other languages a chance?". There's definitely a lot of C++ devs who aren't giving for example Rust a try, and don't see the negatives of C++ because they haven't experienced anything else lately.
If anything, it was derogatory towards C++, not the devs.
And the answer to the question "I wonder if any C++ developer has ever given other languages a chance" is also a quite obviously "yes" (remember, the claim was about "all"), not "no, they never have".