Comment by jandrewrogers | Hacker News Reader

Comment by jandrewrogers | Hacker News Reader

Parent Full thread

If you are building high-performance, high-scale systems software (e.g. database engines), modern C++ is by far the preferred choice for new software projects and next generation systems. The notion of C++ being "useful mostly for legacy codebases" is not in evidence. The reality, for better or worse, is that there is no satisfactory replacement currently for C++ for important classes of software even if starting from a completely blank slate. I like some of those other languages, they just can't do the job in a reasonable way.

The reason modern C++ is still the preferred language for some types of software is that it is significantly more expressive in critical ways, which has a substantial impact on software robustness, maintainability, and performance. You could use those other languages, but it would produce a substantially worse product and/or codebase.

To put it another way, there is often no way to translate an existing elegant modern C++ codebase into those other languages without major compromises to either the codebase or performance. And for the kinds of applications where C++ is preferred, those compromises are largely unacceptable. Maybe some of those other languages will approach the practical expressiveness of modern C++ for this kind of software eventually, but not anytime in the near future.

This is not true. Nor is the post you're replying to, for what it's worth.

Rust and C++ are roughly equally expressive for high-performance, high-scale software. The reasons to use one or the other for new code have little to do with whether each language can do the job; clearly, both languages can. Rather, what dominates are factors like whether your build/deployment system is set up to handle one language or another, what your engineers are experienced in, whether you care about memory safety, etc.

Source: I'm one of the maintainers of Rust at a large organization you have heard of that very much cares about high-performance, high-scale systems software.

True. But.

The learning curve of Rust should not be underestimated, IMHO. I do not know except by my own experience and "gossip", and would be interested in hearing from a bigger shop that has to deal with it.

Rust can make an experienced developer feel utterly clueless. The borrow checker is a very harsh mistress. Moving from C++ to Rust for a computer programmer with many years of experience in C++ must be a frustrating and humbling experience. The simplest things become so hard.

I love Rust, but I do not use it professionally (I would love to). I can clearly see that it is a step closer to what we have been waiting for, it may even be the destination. But I can imagine the pain of moving a programmer from 20 years of C++ into Rust. Becoming a novice again

When I started learning Rust after ~25 years of C++, I was quite productive after a couple of months. If C++ teaches you something, it's that you can be productive with a language without being fully familiar with it. After all, 25 years doesn't seem to be enough for learning C++.

The borrow checker is not such a big deal. You should have learned the basics in undergraduate CS in the context of concurrency and/or databases. If you have done shared data parallelism in modern C++ (let's say with OpenMP), you are probably used to similar reasoning.

Borrow checking and lifetimes do make some design patterns difficult to use, which is a reason you should not use such patterns in Rust. But there are almost always ways of achieving the same goals with idiomatic Rust. It's a bit like having to unlearn gotos when transitioning from BASIC to more serious languages and their fancy "structured programming".

> When I started learning Rust after ~25 years of C++, I was quite productive after a couple of months.

Stating that it takes 25 years of experience in order to become productive with Rust doesn't really sound like a positive note.

Keep in mind that your typical user of high-level programming languages already has a very hard time grasping the basic mechanics of C++, and Rust's memory management paradigm alone is renowned for having quite a steep learning curve when compared to C++.

FWIW I was productive in Rust after a couple of months with a background ~5-10 years of experience in primarily JavaScript and PHP (no prior low level experience). Rust does have a steep learning curve, but I'd argue that it's shallower than that of C++ (which puts shoots up in complexity as soon as you wish to include a dependency).

This is especially true if you are actually intending to write production code. There's no way I'd have comfortable releasing my C++ code to production after only 2 months, but my Rust code was completely solid despite my lack of experience in the language.

> The learning curve of Rust should not be underestimated, IMHO.

Not sure how this is relevant in a conversation about C++, for which the notion of a learning curve is even hard to apply given that practically no one manages to write code that can be trusted to be free of basic defects in the language.

> Rust can make an experienced developer feel utterly clueless. The borrow checker is a very harsh mistress.

And rightly so. Rust is only unique in that you get the hangover before deploying the code in production. It's puzzling that some might see this as a drawback of the language.

I am commenting on the difficulties faced moving a computer programmer from C++ to Rust.

Any conversation about C++ has to consider the costs of abandoning the ship

Sky vs Snowboard, basically.

Sky day one is very easy, yet it takes years to master.

Snowboard day one is going to be mostly about falling, unless you want into xgames, it is much easier to master afterwards.

It depends on which experience one wants to have.

> Moving from C++ to Rust for a computer programmer with many years of experience in C++ must be a frustrating and humbling experience

My experience was the exact opposite.

To write correct and safe C++ code you need to be tracking things like lifetimes and ownerships anyway (even in modern C++). Rust allows you offload all of that cognitive overhead to the compiler, which greatly simplifies things.

There was a short period of time needed to get used to the borrow checker, but coming from C++ I understood why it was complaining about these things so the errors didn't come across as opaque or confusing.

Unless one tries to write GUI software, then it is Rc<RefCell<>> everywhere.

Honestly, if moving from C++ to Rust is frustrating for a developer not because of missing but because of borrowing, lifetimes and move semantics, it probably means that they were writing very "old style" C++. I write my modern C++ following Rust semantics as much as I can, and I think it's the right way to currently use C++ without incurring in slews of preventable issues.

Rust IS modern C++ in a stricter package IMHO. C++ still has some extra magic (constexpr, SFINAE) that in Rust is yet not doable or requires procedural macros, but the core language is definitely designed around concepts such as by-value and move semantics which are crucial concepts to use when writing modern C++ applications.

Rust const is the equivalent to constexpr in C++. As for other compile-time "magic", Rust macros are a much more principled approach to that feature set.

Rust const is still way, WAY more limited than constexpr in C++. You can't do basically anything in const Rust yet, while C++'s constexpr even supports memory allocations.

Learning curve is a temporary problem because Rust is pretty new and a lot of people need to begin ramping up at the same time. Hopefully we’ll get to amortize that across many years of projects, like C++.

> clearly, both languages can.

C++ is not memory safe, which is table stakes these days for any truly "high scale" software. Which is why most large-scale software projects have been written in Java, a memory-safe language, since the late 1990s (taking over from the previously common use of C++). And no, even the C++ Core Guidelines and "modern" coding style do not fully address this issue; they're way too clunky, whether or not legacy code is involved. Rust, even more so than Java in the mid-1990s, is uniquely positioned in offering better performance and safety than C++ and a lower complexity in development.

All big GPU and HPC related companies have ISO C++ people on their payroll, so I doubt they will care to add something else.

And NVidia rather uses Ada/SPARK instead of Rust for high integrity computing.

In regards to Java, while I do agree, there is still enough JNI being used there, hence why Project Panama, to improve such workflows where C++ is part of the story.

Increasingly feeling that Rust is like Elm: a language with novel ideas, teaching valuable lessons (a vocabulary for teaching and checking thread safety, documenting exclusive vs. shared mutability in the type system, arguably a vocabulary for teaching and checking memory safety, though that comes at a steep cost), yet so stubborn the community treats its values (avoiding shared mutability) as moral judgments of code, and the language and deliberately obstructs writing code outside of approved patterns (single ownership tree, exclusive mutability). struct{Cell...}& doesn't need to be harder to use than C++ struct{T...}*, but Rust keeps it difficult because the community views it as bad code design and wants to keep it hard. And *mut T lacks RAII unlike C++'s unique_ptr, and requires unsafe blocks in every dereference. As a result, people turn to unsound patterns like https://github.com/kimundi/owning-ref-rs, https://github.com/mcoblenz/Bronze/, and https://github.com/emu-rs/snes-apu/blob/master/src/smp.rs#L5... (and https://gist.github.com/Darksonn/1567538f56af1a8038ecc3c664a... raises questions about what exactly is sound or will be redefined as sound).

It's a good language to learn. I hesitate to consider it a replacement for asm/C/C++. Writing rust is hoping that the code you're porting to rust can adapt well to the restrictions, and if not, searching for esoteric and needlessly unsafe/verbose workarounds.

Not to mention that to embark right now on a fancy-language-of-the-week codebase could be a career ending (and/or even company ending) mistake. I mean, I still work regularly on C++ codebases that are >30 years old (no STL!) and are supported and extended and even switch companies from time to time. God knows how many "languages of the future" we've had in these 30 years.

There are literally millions of C++ developers out there. And that number is growing. There are new C++ projects started every single day. It will take a very long time for any other language to compete with C++. I agree that most biz software that doesn’t require high performance should be written in something else. But there are many application areas where C++ still completely dominates. Look at commercial games for example, browsers, JIT compilers etc. Yes Rust might be able to do a good job in those domains but it is hard to compare with the C++ momentum.

I would be very interested in hearing a few concrete examples!

Reply on news.ycombinator.com