Wrapper Types in Rust: Choosing Your Guarantees | Hacker News Reader

Wrapper Types in Rust: Choosing Your Guarantees

manishearth.github.io

100 pointsManishearth21 comments

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.

Yep, C++ is complex too, but we've come to that complexity incrementally over a long period of time...

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 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.

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.

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.

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.

Great writeup! Deserve a spot on the official docs.

"Copy" feels weird as name of a type. I translate it into "Copyable (trivially)" internally, is that correct?

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.

Yes, but `Copy` is a trait, not a type. Traits can be used as types but they're ... different.

I'm longing for formal definitions of type and trait, to see the exact difference.

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:

https://www.fpcomplete.com/user/jfischoff/instances-and-dict...

[1] I guess close enough analog to Rust traits.

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).

> Traits are properties that types can have, like Java interfaces though more powerful.

The GP asked about formal definitions. So I think they want something more precise than that.

I know, I was just clarifying my original statement :)

Reply on news.ycombinator.com