This makes a lot of sense to me. I don’t really care at all about memory safety, but being able to use pattern matching, option types, etc. in a language I might actually get to use for work gets my attention.
I used Rust at work to prototype a conversion to conjunctive-normal form. Rust’s type system allowed me to apply the “make illegal states unrepresentable” mantra: I had one type for expressions as typed in by the user, and another type for CNF expressions. By separating the two, I was sure that the conversion procedure created an expression that was actually in conjunctive-normal form. Of course, I had to test quite a lot to have some confidence that the conversion retained the proper semantics, but the main attraction of Rust was being able to have the type checker look over my shoulder as I ventured into a territory I was unfamiliar with.
Why does Rust have a better chance of adoption than OCaml? It seems to have better marketing, is that really all it comes down to?
I think it’s easy to dismiss as “marketing”, but having a large, well-funded, non-academic org behind it counts for a lot. But yeah, I would say it’s more about public perception than any technical reason. I would certainly be happier using OCaml, but that’s not a battle I’m ready to fight.
OCaml’s multi-core needs to happen. Even then there’s not an exact overlap with Rust due to GC (and multi-core means OCaml’s GC won’t be as fast anymore). Add in the “weird syntax” and OCaml is handicapped out of the gate.
I have high hope for Reason which makes OCaml’s syntax less weird.
Substructural types and borrow checking are language features, not “better marketing”. “Safety”, as defined in pretty much every other general-purpose language (if there are exceptions, please let me know), means only “memory safety”. Please tell me how OCaml guarantees that a file will be closed exactly once, and not used afterwards.
On the other hand, “safety” in Rust means safe concurrency and safe manipulation of arbitrary resources (files, network connections, GUI objects, etc.). The only thing that remotely approaches this is monadic regions, but they’re simultaneously more unwieldy (you have a monad transformer stack with one layer for each nested region) and less expressive (you can’t express “braided” allocation patterns: “allocate A, allocate B, deallocate A, allocate C, deallocate B, allocate D, deallocate C…”) than what Rust has.
On the other hand, “safety” in Rust means safe concurrency and safe manipulation of arbitrary resources
I just wanted to clarify some things for others, mostly because I just want to be careful that we don’t accidentally overstate what Rust gives you. (I totally get your point about “safety” meaning more than just memory safety though, of course!)
Rust certainly takes steps to ensure that resource destruction happens in a predictable way, but it is actually orthogonal to “safety” if “safety” is taken to be the dual of unsafe (which is a completely reasonable interpretation IMO). Namely, using unsafe in Rust exposes you to potentially undefined behavior, and memory/resource leaks don’t actually fall under that umbrella. In particular, it is possible to explicitly leak resources in safe code. With that said, of course Rust intentionally makes it quite hard to leak things on accident!
And, Rust certainly cares about other types of safety as well. For example, unwind safety (otherwise known as “exception safety”).
I agree that these are great features, but do you really think they are deciding factors in whether Rust will be picked over OCaml in an industrial context? If so you have a lot more trust in organizations making decisions based on technical facts than I believe is warranted.
Edit: If Rust takes off over OCaml I think it will have far more to do with the familiarity of an algol-descended syntax than any actually useful features, because people make choices like that based on gut feelings, not by lining up a list of features.
The two big things for me are:
I do think emphasizing those two aspects more heavily would make for a better pitch.
For future reference, in a later post Steve responds to two critiques/thoughts on the first post. One ‘Rust is mostly safety’ by Graydon Hoare and ‘Safety is Rust’s Fireflower’ by Dave Herman.
(All of these are on lobsters right now, but I’ve wanted to make it easier to find them later.)
sadly he don’t explain to stranger what he has more than safely
Why doesn’t he doesn’t mention Golang in comparison? He mentioned C# but stops there. Go is a similar vintage to Rust and has similar goals, but it takes a different approach to safety. Meanwhile, Graydon’s post (linked in another Lobster’s thread), acknowledges that there are parallel attempts to do this:
A few valiant attempts at bringing GC into systems programming – Modula-3, Eiffel, Sather, D, Go – have typically cut themselves off from too many tasks due to tracing GC overhead and runtime-system incompatibility, and still failed to provide a safe concurrency model.
I think you can read into this statement a lot, especially with all of the improvements to Go’s GC that are in version 1.8. It’s great to have two unique approaches to safe concurrency in systems languages (Rust and Go). It’s too early to tell which one will achieve their goals the best.
To be clear, Rust claims to eliminate data races in safe code at compile time. Go does not. The specific guarantees provided by both memory safe languages differ when it comes to the standard implementations. You can read more details about Go specifically from rsc.
With that said, in practice, Go provides some nice runtime protections against data races. Its race detector for example is awesome, and since Go 1.6, I believe data races on hash maps will always panic.
Understood that there are different tradeoffs (zero overhead, etc). I’m talking about “what problems is this language good at solving”, and I think they’re very close given the goal of safety in concurrency.