10 comments

[ 2.7 ms ] story [ 34.3 ms ] thread
I'm really excited to see rust in more places. I think that the lack of a "runtime" and interoperability with C were great design choices.
I'm so happy that a safe language is (very) slowly starting to creep its way into where I normally would have had to use C++.

Rust isn't my favorite language, but it's a substantial improvement, at least in my goober opinion, over C and C++.

What sort of features would you like to see in a C/C++ replacement?
I would like a better type system, immutability, and a better guarantee of memory safety.

I'm totally aware that C++ has unique_ptr which can give you something relatively comparable to the Rust memory management, but I personally think that if the compiler doesn't have any kind of official idiom on the subject, it'll probably end up in the codebase. C++ kind of prides itself on being able to "write however you want", which is fine, but then that means that people might start using raw pointers, unchecked arrays, and mutation.

Could a vigilant C++ programmer replicate every feature of Rust? Absolutely, not denying that for a second. Rust doesn't give you anything as much as it enforces a paradigm.

At least that's my two cents.

Oh, yeah, definitely. I guess I was responding more to the "Rust isn't my favorite language" part of your comment- what would you like a language in that niche to do differently than Rust? Or do you just prefer when you can get away without a C replacement? :)
Oh, my bad, I misunderstood.

Lemme first state that I am not a systems developer; I mostly do servers.

That said, some stuff that keeps Rust from being my favorite is a lack of tail-call optimization, the lack of the ability to say that a function is pure and impure (and have that enforced), and not having some concept of a green-threading library built-in.

I realize that the last point can fairly easily be implemented with a library, but the first two points keep me using Haskell.

And evidently, if I'm wrong about any of these points, don't hesitate to correct me! I'd love to have a chance to get better with the language.

EDIT: Just a note, I know that Haskell isn't a systems language and not a direct replacement for Rust. That said, I find that a lot of the features I want in Rust are things I like in Haskell.

Yeah, those are pretty common pain points in Rust.

There is some potential to add tail calls in the future, though, through a reserved keyword "be" (since destructors + tail call optimization don't get along well).

Green threads are probably not going to be as useful in Rust as in other languages. Having something like await/async built into the compiler that transforms into state machine (like in C#) would be more powerful it seems.
Note that Rust does do sibling call optimization, which covers TCO in most of the places where people want to use it.

However, bear in mind that TCO and not having a GC are, if not incompatible per se, severely at odds.

I've recently been using Rust to write a small instrumentation runtime for a project that I would normally have written in C++. The FFI is surprisingly easy and I really love that I can compile down to libfoo.a with no other Rust runtime required. Lack of GC is essential in this space. It really can do anything C can. (I know it didn't always work this way -- there used to be an N:M threading runtime, for example, and a built-in GC for the old @-pointers -- so I'm glad they've gone this way!)