[collaborative]

I founf myself in your same situation a few months ago. I chose Rust and regret it

Rust is a better c++. It's not appropriate for anything you wouldn't program in c++. The coding speed is slow

So if you are thinking about learning a new language to program your future apps you currently code in node, choose Go

[Jyaif]

> Rust is a better c++

The Rust language is a far better C++.

In practice, the compile time and binary size of Rust are out of control, which makes Rust far from being a slam dunk over C++. Crossing my fingers this will change!

[hyperman1]

I get the sentiment, but like to nuance it a bit.

The compile time story of rust and C++ is comparable, if you use it the same way. If you use deep include hierarchies and no precompiled headers, if you start using template heavy code like boost, or if you do code generation, the C++ compile times will quickly spiral out of control. Rust does not have the include problem, but the specialization/templating idea is shared with C++, and the code generation problem has an equivalent in the macro mechanism as used by e.g. serde.

In theory, you can get comparable compile times from both. Main difference is rust heavily emphasizes a programming strategy that depends on these 2, and it has a heavy cost in compile time. Meanwhile, a lot of the C++ code is still in the 'C-with-classes-and-every-vendor-creates-a-string-class' camp and while the abstraction level is lower, so is the compile time.

For the binary size, C++ can hide a lot of stuff in libraries, while rust compiles it in and duplicates it for each executable. So you pay a higher fixed cost per application. As long as rust has no stable ABI, rust will stay behind at this point. But it gets better optimization opportunities as it can merge the standard library code with yours, and inter library calls are more costly so runs wins there too. Presumably it's early day for a stable ABI in rust, big wins are still made. Long term, I'd personally like to see some ABI stability in the rust world.

[zozbot234]

Rust has a stable ABI actually, it's called the C ABI. But since most Rust crates do rely on monomorphized generic code in many ways, it's just not possible to share binary artifacts in the first place. (The situation is similar for "header only" libraries in C++.) If you're writing a library that truly does not involve generic code, it makes total sense to expose it via a pure C interface anyway so that languages other than Rust can make use of it.

[hyperman1]

C ABI is very well supported indeed. After commiting some contortions to avoid varargs, I found out Rust does actually cover them.

But it's still something different than a real rust ABI. Basic things like pushing a string or an enum to a client will hurt. Providing a rust library without source is not an option for now.

[Fiahil]

As of Rust 1.62, compilation time is no longer a valid criticism. Things have improved so much in the past 2-3 versions, it's no longer slower than C++. Sorry!

[thesuperbigfrog]

>> As of Rust 1.62, compilation time is no longer a valid criticism. Things have improved so much in the past 2-3 versions, it's no longer slower than C++. Sorry!

Is there a report or study somewhere that shows how much it has improved?

I had heard improving compilation and build time was being worked on, but I don't get to use Rust much in my current work.

I would be interested to see how much improvement has been made and in what areas.

[bbkane]

See https://perf.rust-lang.org/compare.html?start=2021-11-11&end...

[pimeys]

There are a few things to make things slow still. Try macros generating async code. That can go out of control and is a common case in tests.