6 ms·
> 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
by joz1-k 1y ago
> 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.
- tormeh 1y agoYou 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 1y agoAppart 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.
- tormeh 1y agoYou can just use CXX? Idk what to tell you. A coworker of mine is doing it. It's not some kind of weird thing.
- Narew 1y agocxx only support a part of c++ STL container. It doesn't support template and custom container implementation. So no generic, no variadic number of argument, no automatic type déduction etc...
- lelanthran 1y ago> 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 :-)
- tormeh 1y agoA coworker of mine is using CXX in a combined Rust and C++ code base. This is not exotic.
- digitalPhonix 1y ago> 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 1y agoProblem 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.
- TJSomething 1y agoI've been using F# and there are actually several roadblocks for AOT F# [0]. However, a self-contained .NET JIT executable is still surprisingly small (18 MB for an ASP.NET minimal API written in F#), easy to build, and easy to deploy. [0] https://github.com/dotnet/fsharp/issues/13398 https://github.com/dotnet/fsharp/issues/13398
- pjmlp 1y agoYeah, I listed it, because it is kind of possible, even if there are issues currently.
- Dylan16807 1y agoAnd even if the speed and memory penalties are exactly the same as they were 20 years ago, you no longer need to support a pentium 3 with 64MB of RAM. If you write code that would have performed well 20 years ago, then bloat it 300%, it'll run just fine. I'd rather have that than just about any electron app.
- ViewTrick1002 1y ago> 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 1y agoJava doesn't produce 'garbage data', racing writes will never show intermediary results.
- tialaramex 1y agoLoss of Sequential Consistency means realistically humans cannot understand the behaviour of the software and so "garbage" seems like a reasonable characterisation of the results. It might take a team of experts some considerable time to explain why your software did whatever it did, or you can say "that's garbage" and try to fix the problem without that understanding of the results. The hope when Java developed this memory model was that loss of SC is something humans can cope with, it was not, the behaviour is too strange.
- Dylan16807 1y agoEven with sequential consistency, interweaving multiple threads produces results that go firmly into the garbage category. Even something as simple as adding to a variable can fail. To solve interweaving, add mutexes. And once you have mutexes you'll be protected from weak memory models.
- ViewTrick1002 1y agoWhat is the end result of two threads adding +1 to the same counter 1 million times each in parallel? Well, the result is safe but unknowable. I would call that garbage data.
- thrance 1y ago> 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 1y ago> 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.
- thrance 1y agoTrue, but I would guess that projects more susceptible to rewrites would be low-level core libraries where state-of-the-art performance is always desirable.
- joz1-k 1y agoCorrect. And if those projects exposed a C++ API, then rewriting them in Rust would be highly problematic, because Rust did not prioritize C++/Rust interoperability (for well-understood reasons). So, you can either have a C API and move to Rust or have a C++ API and create a Rust version of the library for Rust developers, but your original users of the C++ library will stick with the C++ version.
- pjmlp 1y agoWith lots of Assembly, inline Assembly isn't C or C++, regardless of how many devs might pretend otherwise. It is like saying C libraries are Python, only because they happen to be used from Python bindings.
- tialaramex 1y agoIf you want assembler Rust seems like a smarter choice because in Rust that's just part of the language whereas in C or C++ it's a vendor extension.
- deleted 1y ago[deleted]