Hacker News Reader

Comment by pjmlp | Hacker News Reader

In what concerns userspace, I don't see any good case, if I want a better C, without much features, I rather stick to Go even if I dislike some of the design decisions.

Or D, Nim, Swift, OCaml, Haskell, AOT C#, AOT Java,...

If any kind of automatic memory isn't possible/allowed, I would be reaching out for Rust, not a language that still allows for use-after-free errors.

Maybe it is a good language for those that would like to have Modula-2 with a C like syntax, and metaprogramming capabilities, and are ex-Objective-C developers.

View on HN

> If any kind of automatic memory isn't possible/allowed, I would be reaching out for Rust

I have come to the same conclusion but then I also fear that Rust will continue to expand in scope and become a monster language like C++. Do you or anyone fear that? Is that a possibility?

Rust hasn't grown in scope very much since its release, but in places where it has grown, particularly async and unpin, I find that there features interact very badly with lifetimes and borrowing. I am often forced to ditch borrowing across async method calls and to put everything in Arcs, even when the lifetime is well-defined and it could be easily used if it had been scoped threads instead of futures. I fear that newer features will be incompatible with older ones in a similar way, but fortunately there are no such features on the horizon.

Considering all that, I still see Rust as the most sane choice for writing native programs. I don't really want a "better C", I want to write memory-safe software with confidence, and that means static analysis or a thick safe runtime, whatever is more suitable for the use case.

Technically though, isn’t memory safety not necessary in some cases?

For example, single player video games. You can exploit your own machine if you want, but that’s not an issue.

I like rust, but if I ran into async issues and annoying stuff, I could see a world where I grab a non-memory safe language to make games easily.

Crashing the program during runtime and having to debug it then is still a worse experience than knowing before running it that it cannot crash (due to memory errors).

This certainty comes at a cost, either by negotiating with the Rust compiler or by putting up with a GC. But depending on your calculus, that cost might be worth paying.

It is an issue if it also allows players to work around DLC and other goodies.

Or if having the game on the system can be used by another malicious application as jumping point into root access, starting it as subprocess and injecting the exploit.

Example, Windows attacks via Notepad.

Memory safety isn't just a security thing, it's also a reliability thing. That is, even if my games have zero security sensitivity I'd still like them to not crash or corrupt data.

Will Rust keep growing? Yes, I think so.

Will it turn into a C++-like monster? I don't know. Maybe, but when it comes to C++ it always feels like its "monster" status is largely a result of previous mistakes or early design decisions piling up, and causing trouble (eg. C-style arrays, exceptions, implicit conversions, fiddly sum types rather than first class support, no pattern matching etc.).

Rust will grow large, and probably complicated, but the real issue with C++ are all these past mistakes and a shaky foundation, and Rust is doing much, much better in that regard. Time will tell if we'll eventually look back some of Rust's design decisions as bad or unwieldy (probably).

> Time will tell if we'll eventually look back some of Rust's design decisions as bad or unwieldy (probably).

I think time has already told for things like async and lifetimes.

async, yeah it could be better, given the pains. However note that adding async to .NET and C++ hasn't been a panacea either, to the point that there is a prototype of adding Go/Java green threading to .NET, done by the .NET team. While with the C++ standard library there isn't an executor runtime in the box.

Lifetimes are painful, and a other languages are exploring better ergonomics or combining automatic memory management with affine/linear types, yet it was Rust's adoption that pushed other language designers to actually look into this. So from that point of view, quite a success, even if Rust vanishes tomorrow.

Can't say much about async, since I really lack the experience to say whether async in Rust could feasibly and realistically be much better than it currently is. Some people say that it'd be great if it worked as effortlessly as in Go, but I assume that you don't get to have that without performance tradeoffs.

As for lifetimes, what's the issue? Do you have any reason to believe lifetimes are frustrating because they were badly designed, rather than the fact that they're making complexity explicit which was previously hidden?

Reply on news.ycombinator.com