4 ms·
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, be
by grok2 11y ago
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.
- Manishearth 11y agoI 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.
- grok2 11y agoYep, C++ is complex too, but we've come to that complexity incrementally over a long period of time...
- Manishearth 11y agoA 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.
- Dewie3 11y agoAll 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?
- grok2 11y agoUnfortunately 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....
- pjmlp 11y agoI 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.
- novocaine 11y agoThe learning curve can be climbed, but I am concerned about cognitive overheard of this stuff while trying to write a program affecting productivity. I'd like to know how much the author's proposed gc takes the friction away.
- Manishearth 11y agoThe 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).
- anon4 11y agoThe 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.
- Rusky 11y agoThe 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.
- Jweb_Guru 11y agoJust 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.