[lkiux]

I gave Rust several trials in the last year, but I somehow ended up thinking that it's [maybe too much] hyped. Rust managed to get quite a bit of traction.

I've been programming in Haskell and Python in the last years, but I've done more of a decade with C++ only and lately begun some MCU work where I had to use C++ almost exclusively again. I don't have a strict preference anymore, although I edge in Python for new projects as it strikes a good balance.

I'm quite familiar with runtime type checking (hs), and hey, I've actually wrote a couple of programs in ATS (whose syntax is absolutely horrid, and second only to the compiler warnings), because ATS essentially translates to C without an extra compiler, allowing you to use it for any MCU supported by your toolchain.

I came out thinking that doing seemingly simple stuff in Rust, such a mutable linked list, is too complicated for what you get. Let's be honest here, writing a safe linked list in C++ (even more so with C++14) is _trivial_, despite C++ being anything but simple to understand as a whole.

This is aggravating if you think that in systems programming, mutable state is almost central to performance (caches and locality). Most of the efficient structures you end up writing are ad-hoc, mutable and with manual memory layout. Complicated code is a double edged sword: if I need to write complicated code to get compile-time insurance, it means that it's a trade-off to just jumping into unsafe territory where the payoff is small.

I somehow like the syntax of rust, but it's quite verbose. Almost too much in places. And I compare this to C++, which is not too skinny either. But C++ got much better lately. I also really don't like how rust inherited the JS style of wrapping closures directly as arguments of functions (think unwrap). It really reads horribly. I'd have vouched for dedicated syntax for such a common idiom. C-like languages (and C++ included) do not read as nicely as homoiconic languages in these cases.

If writing simpler code leads to less bugs, then Nim is actually a much better language. I wish it had more mindshare, as the core and language itself is far from being polished and regular as rust currently is. The current premise of compile-time safety of rust is good, but not a dealbreaker if you use a modern C++ compiler IMHO. It's pretty easy to wrap unsafe behavior in a class. It's actually easier than wrapping unsafe code in rust.

[tome]

> I came out thinking that doing seemingly simple stuff in Rust, such a mutable linked list, is too complicated ... writing a safe linked list in C++ ... is _trivial_

This is really interesting to me as a curious outside observer of Rust. I conclude that either writing a safe mutable linked list in C++ is really not easy or Rust's type system makes it too complicated to capture simple invariants and properties.

Which is it?

[lkiux]

They're not strictly the same, of course.

The trivial "safe" C++ linked list prevents you from dereferencing uninitialized memory, leaking resources and performing incorrect type conversions, which are the typical issues you'll find in any C linked-list implementation. But there's no compile-time check for the actual lifetime of the objects. This means you can manually destruct the same object twice, for example, and the compiler will not warn.

RAII can get you /very/ close, but since it's not enforced at the compiler level, Rust guarantee is definitely stronger.

My main point is that the strong guarantee comes also at a significant complexity cost, and I'm still not sold it's worth it in many conditions.

[steveklabnik]

If you'd like a very complete answer to this question, http://cglab.ca/~abeinges/blah/too-many-lists/book/

[cmrdporcupine]

Yeah, what I really wanted from Rust was basically OCaml without the GC. Or C++ with a proper module system, no preprocessor crap, some pattern matching and type inference, and a more reasonable syntax. Rust started that way and then the safety stuff took over the type system.

I can roll with it. It's probably worth it. I'd love a job programming in it. But it's not entirely the dream I had.

[RaleyField]

> but I've done more of a decade with C++

So have people at Mozilla (or people anywhere else) and there are still horrible bugs in Firefox or other similarly large projects.

> is too complicated for what you get

If you aren't convinced by arguments that safety is intrinsically valuable for yourself or your customers then another argument is that with safer languages you pay the price upfront (i.e. learning and programming with what seems a more complex language) instead of later spending weeks or months on catching a bug causing crashes.

[lkiux]

I'm absolutely for safety and compile-time assurance. I wrote I've actually use ATS in embedded systems where I could to perform compile-time theorem proving. I used ATS, for example, to actually prove at compile-time the runtime heap memory requirements. This is not easy.

Rust is not on the front of research here, although the borrow checker is more pleasant to use compared to /many/ other implementations.

Memory safety is, of course, important, but security as a whole is so much more than just pointer dereferencing and lifetime checking. We got pretty far with C++, modern toolchains and OS support. Rust programs will be only marginally more secure by default than other classes of programs. Rust will not help with entire classes of other problems like side-channel attacks, any logical bug (like incorrect initialization of IVs, unchecked reflection), and so on.

Rust helps, and I do not criticize that. But as with any system, you have to evaluate it as a whole. Is it a big boost coming from C? Absolutely. C++? Not so much. Heck, you can use LuaJIT in embedded systems, and Rust has zero advantage there.

[soulbadguy]

A bit of a strawman argument here.