Hacker News Reader

Comment by mastry | Hacker News Reader

I think Rust is probably too complex for the average enterprise developer who seldom thinks about code outside of work. Not that these developers aren't smart - they just have different life priorities than a lot of HN readers and Rust experts.

View on HN

I am so to speak an industrial entreprise developer working with Vxworks on a medical device. This is exactly the kind of context where you don't mind if the compiler takes a bit longer or if you have to fight the borrow checker in exchange of not having a data race or a memory leak with catastrophic consequences at the wrong time.

Today we are using static or dynamic code checker (which are not cheap) but it would be so much better if we could simply not create some kind of issues in the first place.

I know that Rust is not a silver bullet either but having some Rust support in Vxworks makes so much sense. This is basically my secret wish of the last few years coming true. If anyone at Windriver is reading this, thank you!

It does not mean we are going to rewrite everything tomorrow, but at least we can seriously consider that for new features we could introduce some Rust services in a few years likely.

Rust's complexity isn't accidental unless it's being used for a job where it's overkill. Achieving memory safety in non-GC languages (let alone the degree of other static safety Rust enables) is easier in Rust than C++.

The way I think about it is that Rust exposes all the hard stuff that's hidden in C++.

C++ makes things look simpler than they are and eventually you end up in one nightmare scenario after another, because of all the hidden complexity.

Rust just shoves all that complexity to the forefront, right in your face, so that you are forced to deal with it and don't end up in nightmare land later.

Honest question, what part of Rust is more complex than C++, smart pointers and all? Because it's not evident.

I'm not a full time Rust developer, so your milage will vary:

Rust is a more modern language, so there are a number of modern approaches that Rust uses that C++ can't due to backwards compatibility. And Rust isn't fundamentally an OOP language. I'd say Rust is a bit closer to C than C++, but that's a gross simplification.

But I think what Rust does is forces the developer to address application complexity at compile time, instead of finding out about these problems during run time. Things like segfaults, race conditions, etc. are ferreted by the compiler.

So, Rust might feel more complex, but in reality it's just forcing you to deal with those issues sooner rather than later.

I think Rust is closer to C++ in an important way. Rust and C++ provide abstractions in situations where C spells out the implementation explicitly: e.g. Trait objects (virtual inheritance in C++), lambdas (same in C++), enums (no equivalent in C++). To accomplish similar things in C you'd specify how it will be represented at the machine level, e.g. a struct of function pointers; a function pointer + struct pointer; a union + some way of identifying members. Generally this adds a lot of convenience to the higher-level languages compared to C, but it sacrifices flexibility in the special situations where you need that level of control (e.g. implementing an efficient VM you might want the tag of your object type to be more of a bitfield).

Those are great concrete comparisons.

Another gross simplification I like is: Rust is a memory safe C with type classes. (traits)

Turing complete templates and inheritance make C++ far more complex I'd say then, even at compile time.

Lifetimes. In C++ you don't have to think about ownership to make the compiler happy; you only have to worry about that stuff if you want your program not to crash.

That's exactly why I use Rust, I can not be sure when I get enough confident with C++ to not make my program crash in unexpected ways.

Can you give an example? Smart pointers make you consider ownership. Or does Rust account for more than that?

Rust's ownership model tracks the safety of borrows at compile time in ways C++ can't. You can derive a reference from another reference, and the compiler won't let you do anything to the original object that would leave the derived reference dangling. In C++ there are two different conventions for that: use plain old pointers to represent the borrows, and be careful they don't outlive the owning `unique_ptr`; or use `shared_ptr` to do the bookkeeping at runtime (also available in Rust, as Rc/Arc).

Got it, thanks for the explanation.

So C++ programmers are able to subvert the upfront complexity by ignoring C++ 11 features then, going straight to raw pointers.

This is spot-on. Worked with enterprisy java devs .. seen their code. They couldn’t give a shit about code quality

Java exists to make shitty code less shitty. But in reality it will often hide the shittiness through countless layers of abstraction.

Java is a great glue language. But if the problem you are solving can't be fixed by glue, say performance, computationally heavy algorithms or something of that kind, then look elsewhere.

Reply on news.ycombinator.com