Sometimes I think that the complexity of concepts in Rust will prevent it's large scale adoption for even it's intended uses. You can't blindly use features, because you get tripped up on the compiler and to understand what the compiler is saying you need to know the details of the things explained in the article :-(. I write networking software for a living in C and would like to use Rust, but the learning curve is pretty steep once you go into the kind of things Rust is cool at.
I dunno, C++ has a similar level of complexity (lots and lots of features and fiddly libraries). Blindly writing C++ causes segfaults and undefined behaviour too.
The difference is that Rust complains at compile time, deterministically. So Rust _feels_ like it's tripping you up, whereas you would have been tripped up (without realizing it, often, because runtime) in C++ too.
The second difference is that people are used to C++ and don't recall how complex it is.
A long time of the whole world of software changing too.
If Rust wants to be useful it needs to have a lot of features devs expect from languages of that kind; plus all the features needed for memory safety; hence the complexity.
All these different mutable/shared/etc. combinations look inherent to the problem, i.e. inherent complexity. You'd have the same problem in another language with the same intended goals. So what is the accidental complexity that Rust is adding to the problem?
Unfortunately it is just the inherent complexity that is troublesome -- there is a steep learning curve to get up to speed with Rust and I am worried that the barrier is too high for most people to climb up -- either that or it will take a while and a whole lot of tutorials/cookbooks until people get familiar piecemeal with all the ways to work with Rust....
I remember Ada was considered complex back in the day and now with all UB and specific compiler extensions, C++ has become much more complex with Ada 2012 and SPARK getting industry adoption in high integrity computing space.
The GC itself is a bit complicated. The internals are mostly invisible, but not entirely.
Without language support for a global-GC switch (which is never going to happen) I don't think a "simple" Java-esque GC would happen.
With language support there's still a decently simple GC possible IMO.
Without language support at all, some things (eg interior mutability) become unweildy if you want to have GCs in them, and we have to create new abstractions for it. It's not too bad though.
(The GC isn't finished and we haven't tried using it much so I really don't know how well it will turn out in practice)
====
regarding general cognitive overhead, it's not too much once you're used to it. And one needs to get used to any language they pick up anyway before using it seriously (just that the curves are different).
The thing I'm most concerned with is that the syntax is fucked. A T& should be an Arc<RefCell<T>>, i.e. the most permissible thing, and you should have to wrap it in other things to remove capabilities, rather than add them. The idea being that the short thing is applicable everywhere and probably what you want, while stronger guarantees require more typing.
Just FYI, `Arc<RefCell<T>>` wouldn't actually be useful, because you could not send it to other threads (`RefCell<T>` is not `Sync`). By your definition the "most permissive" thing would be `Arc<Mutex<T>>` and that hopefully makes it clearer why this would be a terrible default (`RefCell` has similar tradeoffs to those of a `Mutex` that killed your program when it detected deadlock, and `Arc` can leak memory). Rust absolutely gets the tradeoffs right here.
BTW, if you want a language where refcounting is the predominant approach (and where the compiler is built around it), but is otherwise very similar to Rust, you almost certainly want Swift.
The most permissible thing is not the most used thing (&T is far more common than Arc<RefCell<T>>), and Rust's goal is to be explicit about costs. The extra typing directly correlates with extra cost.
Types are types. Let's take a type system with generics but no single inheritance.
Traits are properties that types can have, like Java interfaces though more powerful.
Many traits can be used as types to form a vtable dispatch. For example, Box<Send> uses the trait `Send` here as a type. Objects of type `Send` are "unsized" and must be held behind a pointer (which becomes a fat pointer).
I've been wondering about the same thing recently too. Meanwhile, there is an article that explains how Haskell typeclasses[1] are implemented, or how they conceptually work:
Traits tend to end up as "-able". Maybe you might as well cut out the Hungarian suffix and elide the "able". I don't know if that is the argument, but that's how I view it.
