2016 Rust Commercial User Survey Results

That's not a survey, that's a focus group.

I'm impressed with Rust. The borrow checker is the biggest advance in memory safety since garbage collection.

But there's a lot about Rust that's unnecessarily weird.

- The type system is unusual, and complex. It's hard to do anything without templates.

- The template libraries are heavily biased towards closure-oriented functional programming. This is cool, but hard to read. Parts of expressions are nameless and have no visible type. This is terse but hard to maintain.

- The hacks needed to avoid the need for exceptions are uglier than exceptions.

This creates major obstacles to adoption. Unlike the borrow checker, none of these things are clearly improvements. They're just different.

I would have gone for Python-type exceptions rather than error enums and macros, single-inheritance OOP rather than traits, and Python-type with clauses rather than RAII.

Do you mean the generic types and functions that stop you having to reimplement a whole pile of common patterns and data types yourself? You're welcome to write your own VecInt and VecString and VecMyStruct and VecYourStruct and OptionInt and HashMapIntString, but I'll go out on a limb and say that would be more annoying than 's in a few places. For one, not having generics would make it far more annoying to create reusable zero-cost abstractions around `unsafe` code, resulting in your other favourite criticism: more unsafe code for "unnecessary" (i.e. performance) reasons.

> - The template libraries are heavily biased towards closure-oriented functional programming. This is cool, but hard to read. Parts of expressions are nameless and have no visible type. This is terse but hard to maintain.

This isn't true: most generic types go via other schemes, and only use closures for simple combinators (making one line manipulations simpler and easier to read, but like with anything, can be abused), or when they're required to achieve the desired semantics (iterator pipelines).

---

In any case, (some of) your proposed replacements don't make sense as the only built-in for their given functionality, for a systems language. If the task in question can take the loss of control, then Python (or similar) seems like a better choice for you.

> would have gone for Python-type exceptions rather than error enums and macros,

True Python-style exceptions require allocations to handle errors.

> single-inheritance OOP rather than traits

This forces dynamic dispatch everywhere and loses type safety (when passing types through functions and storing them in data structures), rather than being able to specialise functions and data types, and track exact types through code.

Also, only offering single-inheritance has significant semantic problems, e.g. what happens when your type is both equatable and cloneable?

> Python-type with clauses rather than RAII

What exactly does this address? It seems just like a syntactic rephrasing of `let x = foo()`, given it would have to be compulsory for certain types, or else guarantees are lost.

---

Rust is, as you say, different to other languages, but very little of it (and none of the features you call out) was chosen just to be gratuitously different. The new features of course might just take a little time to get used to if one is coming from mainstream imperative/OOP languages.

For example try writing even a basic function accepting two scalars of type T and U and performing arithmetic on them. The way the Rust compiler works it isn't possible without specifying various bounds on the traits (which I appreciate, actually, for explicitness). And even then there are limitations around casting that require non-trivial workarounds (it is ridiculous, frankly, that the num crate isn't in the standard library, but that crate has its own problems).

And there is no specialization, which is a severe limitation.

Can't disagree with your comments re: python.

You need generics to have the borrow checker that you praise above. Otherwise references would be basically crippled.

> The template libraries are heavily biased towards closure-oriented functional programming.

No, they aren't. I use for loops all the time in Rust, and it's totally natural to do so. My general guideline in my own code (which is followed in projects like WebRender and Servo layout) is that if it's one line, I use the functional idiom; if it's more than one line, I use a for loop.

> Parts of expressions are nameless and have no visible type. This is terse but hard to maintain.

Are you thinking of unboxed closures here? If so, they're necessary to avoid unnecessary heap allocations in normal code. If we didn't have that, then we couldn't compete with C++11 closures.

> - The hacks needed to avoid the need for exceptions are uglier than exceptions.

Unwinding is the single most divisive issue in Rust. We would alienate most of our community (I'm not kidding) if libraries required it. For a time, there was a language fork over the issue until it was resolved.

> Unlike the borrow checker, none of these things are clearly improvements. They're just different.

No, they're needed for the borrow checker and most of the other features to work.

> I would have gone for Python-type exceptions rather than error enums and macros

Then, as above, you instantly alienate all embedded developers.

> single-inheritance OOP rather than traits

This doesn't work in practice unless you introduce interfaces: it's way too inexpressive. This is why Java and C# have interfaces. Traits are just interfaces.

> Python-type with clauses rather than RAII.

You want to force an extra layer of indentation for every Box or Vec you create, and leak memory if you forget to write "with"? No thank you!