5 ms·
The deep well of academic and industry experience that was brought to bear on Rust's design is one of the reasons it's so good in so many areas. Most programmin
by habitue 4y ago
The deep well of academic and industry experience that was brought to bear on Rust's design is one of the reasons it's so good in so many areas. Most programming languages start with a developer scratching their own itch and kind of stay that way. The language grows features and learns to solve problems as the developers of the language learn the shape of those things. If the designer didn't know the PL landscape in depth, they end up spending time rediscovering lessons others have already learned.
Rust blatantly stole many of the best features of other languages and academic PL research, and its developers have spent their innovation tokens on figuring out how to get all these parts interacting, as well as how to make them ergonomic.
That brings its own challenges, but a feature like ownership and borrowing can't be bolted on afterward. It paid to get it right, and then work hard to make it easier and easier to use.
- mananaysiempre 4y agoWe’ll see if they were the best, but they certainly weren’t the most advanced. (Not necessarily a bad thing!) For example, Mezzo[1] tracks memory allocations in its type system in a manner very similar to Rust, but has absolutely no problem with circular or doubly linked lists. It also has a grand total of two people backing it and seems mostly dead. [1] https://protz.github.io/mezzo/ https://protz.github.io/mezzo/
- Rusky 4y agoI wouldn't say "absolutely no problem." Based on section 2.5 of [1], Mezzo needs some extra bookkeeping to handle reference cycles as well- the program needs to select a single owner for objects involved in cycles, and `give`/`take` them to/from that owner to access them, which can fail at runtime. Section 2.6 describes a static variant of the same idea, named `focus`/`defocus`, which can't fail at runtime but has some limitations on how nodes can be used. These don't exactly match the solutions Rust typically uses, but they are close to a few of them in several ways. This looks more like a question of defaults and API (including the choice to rely on garbage collection by default) than the design of the type/borrow checker. [1] http://gallium.inria.fr/~fpottier/publis/bpp-mezzo-journal.pdf http://gallium.inria.fr/~fpottier/publis/bpp-mezzo-journal.p...
- nixpulvis 4y ago... and then they added `async`.
- carlmr 4y agoLong-term Rust enthusiast here. I agree, async feels tacked on and raw. I think it shouldn't have been added. At least not the way it works right now.
- WalterBright 4y ago> a feature like ownership and borrowing can't be bolted on afterward D has a prototype ownership/borrowing system implemented.
- habitue 4y agoThat is very cool. I kinda tossed out the comment that it can't be bolted on, but maybe I'm wrong? My guess would be it's like a gradual type system in python etc where older D code is the equivalent of unsafe?
- WalterBright 4y agoI, too, thought it couldn't be done. But it can. All that's needed is to annotate a function with @live, which turns on OB for that function. This makes it completely compatible with existing code. The neato thing is it's not necessary to learn a new language, new syntax, throw everything you have away, etc.
- agumonkey 4y agoWhich is quite at odds with the mainstream dev world. Just the other day I commented on someone saying "you don't need to know any of that CS thing.. just write your async api, destruct(uring-bind) your args in your lambdas... and cash in your check" I couldn't help to feel bad from the boastful ignorance.