[joz1-k]

> My observation is most people who suggest Rust alternative don't use Rust.

This is a very condescending statement. In fact, for most software, when given the option of a full rewrite from C/C++ to another language, Rust is usually the least reasonable option. Fully automatic memory-managed languages should be considered first.

> People who actually use Rust known it is worth to rewrite C/C++ software in Rust, either the whole or part by part.

A full rewrite is not a feasible option for many large projects, and Rust does not make it easy to rewrite C++ code piece by piece, as the linked article clearly explains.

It's not true that developers don't like full rewrites. Most often, it's the path most developers would choose if they had enough time and funding. But in reality, you don't get either of those two.

And even if you are willing to do a full rewrite, your project probably has non-trivial dependencies on large, mature C++ libraries. You are not going to rewrite those. This is why more new projects are started in C++ every day than in Rust.

[digitalPhonix]

> Rust is usually the least reasonable option

If the software was originally written in C/C++ based on some performance reasons (avoiding GC/being in control of boxing/being in control of when to use vtables etc.) then what would be more reasonable options?

> Fully automatic memory-managed languages should be considered first.

Those languages have existed for 20+ years so if they were ruled out as part of the original decision making then they probably still aren't applicable.

[pjmlp]

Problem was that 20 years ago some of those languages didn't had AOT compilation options, or if they did, they were commercial, priced at ways most developers would rather not bother.

Plenty of software has been written in C or C++, only because they were the only compiled languages known to the authors.

Having said this, Go, D, Swift, OCaml, Haskell, Common Lisp, C#, F#, Java (with GraalVM, OpenJ9).

All of them offer ways to do AOT compilation and use value types, granted Java is too verbose using Panama for that, and one is better of choosing one of the others.

[thw_9a83c]

> Those languages have existed for 20+ years so if they were ruled out as part of the original decision making then they probably still aren't applicable.

There are huge C++ code bases that are 15+ years old and are still actively maintained because the cost of a rewrite is too high for something that still solves the problem well enough.

Most of the large C++ projects I've worked on were written in C++ because it was the most common and mainstream language given the CPU and memory constraints of that time. We have significantly more powerful CPUs now, especially considering multicore computing, and easily 5-10x more RAM than 15 years ago. Java/Kotlin, C#, Go, TypeScript, Swift etc., are perfectly applicable to many more problem domains where C++ once dominated. I can easily agree that many C++ projects would be better off transitioning to a fully garbage-collected language than to Rust.

[lelanthran]

> Those languages have existed for 20+ years so if they were ruled out as part of the original decision making then they probably still aren't applicable.

They were ruled out when the RAM/CPU budget per $SERVER could have been an expensive 4GB/2-core for a complex server processing transactions in real-time.

Today, that same complex server can cheaply run on a 48GB/6-cpu server. Those performance constraints for exactly the same $FUNCTIONALITY are such a low hurdle, dollar-wise, that it makes no sense in most applications of this heuristic.

[ViewTrick1002]

> Fully automatic memory-managed languages should be considered first.

Of which none has solved concurrency. Some like Java prevents UB but garbage data will still be produced if you don’t diligently protect the access of the shared data.

[writebetterc]

Java doesn't produce 'garbage data', racing writes will never show intermediary results.

[thrance]

> Fully automatic memory-managed languages should be considered first.

Why? If it was written in C++, there's a good chance it was so for performance reasons. You wouldn't want to throw that away with a GC.

[joz1-k]

> If it was written in C++, there's a good chance it was so for performance reasons.

I agree. But imagine that games like Doom or Quake would have been unthinkable if they weren't fully written in C/C++. Now, however, we have 3D game engines like Unity that expose a C# API for game logic scripting, and it seems to work just fine. Performance is becoming less of a concern for more and more problem domains.

[tormeh]

You can use C++ libraries from Rust. That's a very normal thing to do. People start new projects in C++ either because they themselves don't want to learn a new thing or because they don't want their employees spending time learning a new thing.

[Narew]

Appart from cxx.rs. I think most binding between C++ and Rust are in fact C and Rust binding. So you need a C API to your C++ library (no template, no std etc...). So for me you can't use C++ library from Rust.

[lelanthran]

> You can use C++ libraries from Rust.

I doubt it. You can use C libraries from Rust, and emit C libraries in C++.

> because they themselves don't want to learn a new thing or because they don't want their employees spending time learning a new thing.

Whining about others not wanting to learn when you could have learned how Rust FFI works is, really, hilarious :-)