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.
Weβ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.
I 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.
That 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?
I, 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.
Which 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.
I'm glad to see more mentions of MS's Midori project. The blog posts from Joe Duffy that this article links to make for interesting reading, and I think that there's some interesting ideas there that I'd like to see more experimentation with. The two that really stand out are heavily using contracts in the language and tooling (http://joeduffyblog.com/2016/02/07/the-error-model/#bugs-aba... goes into a fair bit of detail), as well as using capability-based security.
One of my ideas is to see if we can do memory management by the absence of a keyword rather than the presence of a keyword.
So whenever you need to use a pointer, you import it. Whenever a scope is entered that doesn't import the keyword, it is freed. this is slightly different to RAII.
While disappointing, that is kind of just life. A few years back I someone I spoke with was praising a paper my advisor wrote, completely oblivious to the fact that I was the first author.
I'm not actually salty. Rather, sometimes I half-joke that I have 28 years of Rust programming experience, and when people do the double-take I explain that I'm including ML-derived languages with explicit lifetimes/regions, so close enough.
"I was talking to Lou Reed the other day, and he said that the first Velvet Underground record sold only 30,000 copies in its first five years. Yet, that was an enormously important record for so many people. I think everyone who bought one of those 30,000 copies started a band!" -- Brian Eno
Just in case someone want's to try it I've did some work to allow build on linux (Ubuntu 18.04 and probably others too), you can see it here https://github.com/mingodad/cyclone .
I often wonder what could have been if cyclone got more adoption. I don't really think "rewrite it in cyclone" would be any more successful than "rewrite it in rust" but "incrementally port it to cyclone" could have been faster.
I'm not confident Cyclone was ever intended to see widespread adoption. Most languages like it from academia are built to solve a particular problem, but then written about to help other people learn about the developed solutions to that problem. Most people in academia don't want to take stewardship of a language that will grow a serious community, but they do generally want to help in shaping those languages for the better.
Agreed, I don't think there's anything necessarily wrong with academic research languages, especially when people working on more directly applied projects know to use what's been researched, as the other thread about Rust alludes to. I'm reminded of Barbara Liskov's CLU language in the 70's; I don't think it got widely used, but to quote Hillel Wayne [1], "Every language spec for the next decade would namedrop CLU."
> Cyclone development was started as a joint project of AT&T Labs Research and Greg Morrisett's group at Cornell in 2001. Version 1.0 was released on May 8, 2006
I didn't know dan grossman was in that team. He did a nice MOOC on coursera. I wish he did one on cyclone's ideas :)
ps: were there other safe C langs ? I kinda remember another CS based C dialect (a blue themed website) that was close to cyclone but I can't remember which.
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.