Hacker News Reader

Comment by garmaine | Hacker News Reader

> That's driving away the JavaScript/RoR/hipster crowd which is the lifeblood of Rust's adoption.

I'll bite. Why?

Rust is a system-level programming language.

As other people have pointed out, despite being a “systems language” Rust has attracted people from a whole bunch of areas and programming languages and limiting itself to just systems programming would limit its uptake and community for very little benefit.

Not that this means that every demand needs to be acquiesced to, there’s balance to be found.

Web development projects in a new language is a good starting point because you can do something with pretty UI quickly and with minimum configuration. But it has no staying power. A web developer will be gone after a couple of months (fun to learn!), leaving behind nothing, and suddenly Rust will have lost its footing (systemdevelopment).

I’m always happy if people use Rust. But why call out an unrelated field with a use case nearly opposite of Rust’s design requirements as “the lifeblood” of adoption?

I also don't quite understand the appeal of Rust for applications that can tolerate a GC. Other than perhaps borrow checking, I don't see the benefits over statically-typed, GC languages.

I used to code a lot in C++, but I've come to the conclusion that manual memory management is a cost that has to be considered seriously. e.g. one burden is that when you're declaring a field on a struct in Rust, you have to consider whether it needs to be a reference, value, automatic reference counted, boxed, if its a reference, what the lifetime is, etc. The only thing I miss about manual memory management is the RAII pattern.

Rust moves down a level of abstraction that IMO is not useful for most applications.

There’s one specific substantial benefit in comparison with typical Java-like languages: concurrency is much easier in Rust. Having “is this thing thread safe?” answered at compile time is something I missed in Kotlin a lot. Of course, it does not necessary outweigh the need to think about references vs owned values, etc.

I think Rust was relevant in bringing affine types into mainstream, after the ATS and Cyclone attempts.

Thing is, with ongoing efforts on managed languages to integrated similar capabilities into their type systems, we can get most of it, even if we don't get access to the full package.

What languages are you thinking of that are like Rust but GCed? Most GCed languages don't compile to native binaries.

If your requirement is compiling to native binaries, then perhaps dlang with GC enabled? Admittedly it would be a really poor choice in 2020 though given the lack of adoption. Golang is GCd and native, but of course the language is lacking in many ways compared to Rust.

So I guess you're right, nothing I can think of quite fills the niche that Rust does, if compiling to a native binary is a hard requirement. Also I'm not aware of any widely-adopted language with borrow checking, if that's a feature that's valuable for your use case.

Java, Kotlin, Scala, C#, F#, OCaml, Haskell, D, Swift, Ada, Go all can compile to native binaries, yes even Java and .NET.

Reply on news.ycombinator.com