from Hacker News

The Rust I wanted had no future

by dochtman on 6/5/23, 7:03 AM with 508 comments

by sph on 6/5/23, 8:03 AM
Very interesting insight from Graydon, in hindsight I too would have loved something more towards ML than C++. I never liked the kitchen sink approach that I see first C++, now Rust moving towards, but I respect what Rust has managed to solidify into. It's a good language.
That said, I still hate async with a passion, it makes the language more complex and not very elegant (i.e. function coloring). And now that I know how it works behind the scene (thanks to Jon Gjengset [1]), it feels so complicated and hacky, a mediocre very high level concept that someone managed to implement as a zero-cost abstraction. Impressive, but still a bad idea.
I'm sure the pro of having a BDFL instead of a committee is being able to follow a singular vision, instead of trying to appease members by adding the fad du jour which might stray a little too far from the original vision. Too many chefs in the kitchen and all.
1: https://www.youtube.com/watch?v=ThjvMReOXYM
by titzer on 6/5/23, 1:00 PM
> Library-defined containers, iteration and smart pointers. Containers, iteration and indirect-access operations (along with arithmetic) comprise the inner loops of most programs and so optimizing their performance is fairly paramount; if you make them all do slow dispatch through user code the language will never go fast. If user code is involved at all, then, it has to be inlined aggressively. The other option, which I wanted, was for these to be compiler builtins open-coded at the sites of use, rather than library-provided. No "user code" at all (not even stdlib). This is how they were originally in Rust: vec and str operations were all emitted by special-case code in the compiler. There's a huge argument here over costs to language complexity and expressivity and it's too much to relitigate here, but .. I lost this one and I still mostly disagree with the outcome.
Trust me, you do not want to put this stuff into the compiler. It's not just that it's cheating for perf, but it's confusing to users (no source code to read how these work) and frustrating that they can't write their own. Ultimately what this really means is that these things are indeed written in some language--the compiler's IR. JavaScript actually has a ton of this kind of things and every JS engine has gone through multiple generations of "what language do we write Array.sort in!?". In V8, these intrinsics are written in a DSL because doing them in asm, a special dialect of C++, or one of two compiler IRs ended up being more trouble than its worth.
You want a clear separation between what is language and what is library.
by moonchrome on 6/5/23, 8:12 AM
As someone casually following Rust and haven't touched it or C++ in probably 5+ years (but keeping tabs in hope of coming back to that world), I feel like a lot of decisions he mentions are what made me optimistic about Rust adoption/positioning itself as a modern C++ replacement. So I kind of agree with his conclusion - his version of Rust would be much less interesting to me, and I think a lot of it's current users. eg. I only started playing with Rust once they removed green threads. Zero cost abstractions are a major selling point.
by hardwaregeek on 6/5/23, 2:21 PM
A lot of Graydon's ideas feel like interesting extensions to ML-style languages. I bet if he had continued down that path, it would have been a lot more of an experimental language with a hodgepodge of different ideas. Which is totally valid (you need these languages to test new paradigms and features), but definitely would not have become mainstream.
Basically, I view Grayson as a leader who set the tone for Rust being a language that was willing to take ambitious swings on cutting edge features. But I don't think he would have been the person to eventually make the cuts and compromises necessary to hew the language into a cohesive, mainstream language. Rust ending up as a replacement C++ helped it not only determine which features to keep and which rules to follow, but also helped it create the right pitch for developers to use it.
This does lead to a larger question about BDFLs. Perhaps, like CEOs, the BDFL you want when you're starting a language is not the BDFL you want when you're maturing a language, or maintaining a language. Especially around feature selection, in the beginning it may pay off to add a lot of features based on user feedback, but later on it may be better to push back more. And from a psychological standpoint, I have wondered about the pressure of being a BDFL. Grayson has been open about stepping down partially due to reaching his limits, and I suspect other BDFLs have thought about it too. The job sounds exhausting and thankless. At a certain point, wouldn't you want to leave and start a new project? And wouldn't we want the person who had success once to give it another shot?
by anonyfox on 6/5/23, 12:18 PM
I love Rust and built some production code with it in the past. But nowadays I want something more simple so that not-so-senior developers can pick it up quickly, and I want flawless tooling, and willing to sacrifice a bit of performance. So basically I often end up with Go. Go is exceptionally great in tooling, ecosystem, any objective metrics like build times or crosscompilation... but I still don't like the language itself personally.
If there would be something just like Go, but with a bit more powerful typesystem like Rust has (Option<T> instead of `err != nil`, and so on), and a simplified ML-like language instead of an imperative one... that would be my dream.
by javajosh on 6/5/23, 12:39 PM
Too bad graydon didn't get his way with build times. I've come to believe that the most important feature of any development environment is to minimize the built-test-debug cycle. Of course, a real system has many different ones, ranging from "language level" to "I have to redeploy and perform a complex series of actions in an app or 3". But at the language level I've found that build performance is of paramount importance. And when a project ignores build perf, everyone suffers every time they build. Since the lower-limit is the language compiler, it should therefore be kept very fast. (And the people working on the applications must constantly resist adding features that slow the BTD loop down any further.)
A good example of this trade-off in Java is Lombok. A very handy library that legitimately avoids a ton of boilerplate, but it also absolutely tanks your build time. In a real system, a large one, your team is better off just getting good enough with their editor that they can generate the hateful boilerplate, and leave Lombok out. Because you'll be paying for Lombok all the time, and only need it a small fraction of the time. There are hundreds, thousands of these conveniences that are deeply tempting but should be avoided, in every build. The problem is that the programmers become attached to these little nicities and actively resist giving them up, even though they are so costly.
by jstx1 on 6/5/23, 7:25 AM
A bunch of things you don't like about Rust? Turns out that the person who originally created the language doesn't like them either.
I know that the main point is about governance and how having a BDFL would have led to a completely different language but I really would have preferred the Graydon-BDFL-Rust to what we have today.
Very interesting article, worth a read.
by bfrog on 6/5/23, 2:02 PM
After reading this I'm really quite happy Graydon created Rust, but then conceded the path it has taken.
It really is an incredibly language and ecosystem, in large part, because of its performance potential.
To be clear, the only real options in this space were arguably C, C++, and maybe in some circles D in my mind. C++ and C by far had the mind share.
Had Rust gone the way Graydon wanted I don't think Rust would be so interesting in the OS and Embedded space. This is a space that it turns out is really ripe for change.
Embedded application are growing more connected, and more complex all the time. Security is a serious concern perhaps followed by or proceeded by performance depending on who you ask. Rust checks so many boxes off in this space its really hard to argue that it isn't a better solution.
Would you rather write a little embedded http server on an IoT device in C, C++, or Rust? What about an embedded networking stack? What about a mesh network stack? I know the answer I'd have every time for this myself.
by xiphias2 on 6/5/23, 12:04 PM
,,I would have traded performance and expressivity away for simplicity''
,,A lot of people in the Rust community think "zero cost abstraction" is a core promise of the language. I would never have pitched this and still, personally, don't think it's good''
If the language makes compromises in performance, it's not a real C++ competitor anymore.
Some things are not about what people ,,like'', but that we need a language that is safe and can compete with C/C++ in performance for systems level programming, as most security problems in the world come from C/C++ memory management.
If it's significantly slower than C++, Mozilla couldn't have picked it up to replace C++ code base, as there was a huge competition in performance between browsers.
by krupan on 6/5/23, 12:48 PM
The key challenge of rust for me:
"Complex grammar. I've become somewhat infamous about wanting to keep the language LL(1) but the fact is that today one can't parse Rust very easily, much less pretty-print (thus auto-format) it, and this is an actual (and fairly frequent) source of problems. It's easier to work with than C++, but that's fairly faint praise. I lost almost every argument about this, from the angle brackets for type parameters to the pattern-binding ambiguity to the semicolon and brace rules to ... ugh I don't even want to get into it. The grammar is not what I wanted. Sorry."
by ZephyrBlu on 6/5/23, 9:31 AM
This is an interesting read, because I read it as "I would have done all these things which would have kept the language more pure to my vision but less accessible".
I also found this bit interesting: "It's easier to work with than C++, but that's fairly faint praise".
I see this kind of thing in my own personal projects all the time. I'm thinking "oh it would be really cool if I built X" when in reality most of the time users just want really simple stuff.
Being easier to work in than C++ might be faint praise, but it's probably the biggest draw of Rust for me. I don't want to touch C++ with a 10ft pole, but I love using Rust.
by mjburgess on 6/5/23, 10:59 AM
Over the evolution of Rust, I've been increasingly despairing about many of the things Graydon here dislikes. I assumed the present "syntactical insanity" was, somehow, intended; it seems, really, it wasn't.
I find Rust basically unusable -- at the level of abstraction I want to write code, basic definitions break line limits.
Rust seems to be a repetition of C++'s mistake: a language which conspires you to pretend it's another. There are now nearly as many Rusts as C++s.
If I return to any domains where Rust would be relevant, I'd probably now opt for Zig or equivalent.
by bazoom42 on 6/5/23, 12:51 PM
To be successful, it is not enough for a language to be good. It might not even be necessary. What matters is if there is s significant niche where the language is a better fit than any alternative.
PHP show that a language only needs to get that one thing right.
Rust have found its niche. Graydons vision seem to be a more elegant language which would compromize on the points which actully make Rust succesful.
by Aissen on 6/5/23, 8:19 AM
On integer wrapping, I think explicit wrap is annoying at first, but eliminates a whole class of bug. I can only agree with:
> (Swift at least traps in release by default -- I wish Rust had chosen to).
I enable it in release on serious projects:
```
    [profile.release]
    overflow-checks = true
```
by PhilipRoman on 6/5/23, 9:05 AM
Haven't followed Rust too much, but I'm always surprised when I hear that Rust is too difficult or not ergonomic. As I understand it is meant to be a systems level language; something you'd use to write kernels, TCP stacks, browsers and ssh daemons.
Anyone writing these things today in C or C++ already understands object lifetimes and Rust just adds a static checker for them.
In such projects churning out lines of code is not the bottleneck, ease of development should not be prioritized over long term maintainability.
Why on earth would you try to rewrite python CRUD apps in Rust?
by weinzierl on 6/5/23, 11:30 AM
One thing I wished was on this list, but wasn't, is syntax. I love many syntax decisions Rust made, but I wish Rust hasn't borrowed so much syntax from C/C++. The syntax of these languages was designed under (for todays standards) weird keyboard and encoding constraints and many choices are just odd.
To give you a few examples:
- = instead of == for equality would have been the natural choice
- := for assignment is similar enough to what is used in math for definition, so that languages like Pascal use it
- <> for inequality is something SQL got right
Smaller things that bug me are the ubiquity of the double colon (::) and the weird mixture of snake case and camel case conventions.
And not to leave the wrong impression, I think Rust got many things very right. My personal highlights are:
- -> for the return value
- concise keywords like `fn`
- `where` for constraints
In general more Algol/Pascal and Haskell - less BCPL and C/C++.
by Aardwolf on 6/5/23, 10:09 AM
> Tail calls. I actually wanted them! I think they're great. And I got argued into not having them because the project in general got argued into the position of "compete to win with C++ on performance" and so I wound up writing a sad post rejecting them
I don't understand the subtleties here: Is tail calls an optimization the compiler can do irrespective of the language? Or is there something that prevents this and requires the compiler to use stack here? Is there any visible effect to the programmer from supporting tail call or not, other than performance and stack depth?
How does not supporting them compete with C++ performance?
by erik_seaberg on 6/5/23, 8:38 AM
I’m very glad expressivity won out. I would like our profession to stop accepting tools that waste effort.
I’ve always seen safety and lifetimes and borrowing as the main value prop, so I was surprised to see he was sort of aiming at an ML without GC, rather than a C++ that doesn’t blow up.
by dathinab on 6/5/23, 9:56 AM
One thing I want to add wrt. "Cross-crate inlining and monomorphization. I wanted crates to allow inlining inside but present stable entrypoints to the outside." [..] is that it was in general well desired AFIK by most developers but so far out of scope that you probably would need to had the resources rust has today _before_ the 1.0 release to get it done right. At lest with the state CS research had been at during that time. By now due to various reasons (e.g. swift) there is much more research in that direction already done hence a new language has it much easier.
by mhd on 6/5/23, 8:39 AM
Ah, Sather gets mentioned. That's a name I haven't heard in a long time. I remember looking at it during the latter half of the 90s when I was searching for the perfect OO language...
https://www1.icsi.berkeley.edu/~sather/
by LeanderK on 6/5/23, 9:01 AM
Can someone comment on "Library-defined containers, iteration and smart pointers"? I have no rust experience so far. Magic compiler support for such primitives is something I usually very much, really strongly dislike, it was always my experience that it is the wrong point of abstraction because it just reduces the design state so much. But then you need good support for inlining the relevant parts of the language, which I think is very often very poorly done. In fact, I have so far never seen a solution I like.
What is the rust experience wrt to inlining? Can every expression be inlined or only selected ones? How can you know what got inlined in some expression? Do you have to manually annotate every single function call you have to inline or is there a more general command?
by truculent on 6/5/23, 9:36 AM
It sounds like the Rust He Wanted has a lot of thematic similarities to Elm. Interestingly, Elm has a BDFL, and a development process that reflects that. And he’s right - there are a lot of people who really don’t like that!
Overall, a really interesting article. Though I like today’s Rust, I do think I would prefer the trade-offs made by the alt-Rust outlined here.
Perhaps it’s just my own personal preference, but I think there is a strong bias in users towards what they are already familiar with, and it’s hard to break away from those without a BDFl or similar position of authority who can impose their vision.
by FrustratedMonky on 6/5/23, 11:28 AM
Great read from a creator of a language. There are so many new languages these days, it is always enlightening to hear the author discuss design tradeoff's. That being said, man, its easy to forget how difficult and complicated creating a good language can be.
Makes me wonder if things like Linux, or C++, were historical anomalies, the stars aligned. How many good projects fail because of 'loosing arguments' that should have been won, or the community didn't form, etc... a million things..
by junon on 6/5/23, 4:28 PM
> I was weirdly focused on [the Actor] model that in practice has many issues
I maintain the actor model is probably the most theoretically perfect concurrency and distributed computing model. The holy grail. We just don't have the right hardware for it and it's extremely limited by addressability issues with current technology.
So I don't really find this surprising, nor disagreeable. It's just not a model that Works Well at present.
by w10-1 on 6/5/23, 5:34 PM
Graydon may lament the features that got away, but being a good loser may be the best way to encourage contributions and to respond to community needs. The historical forces on a language are both its constraints and its drivers. Languages that are nice conceptually are not responsive to history.
Both Swift and Rust both veered away from their original champions. The champions helped by focusing the problem and providing a technical skeleton, but the need (the pain of C/C++/Objective-C) was both intense and complex, so the community was stronger than the BDFL model.
Interestingly, Swift has seen Rust forge ahead on a number of fronts, but is quietly adopting the best of Rust, and soon interoperating with C/C++ will be frictionless. The ties to Apple are being loosened, with a more portable stdlib and a Foundation library that subsets the legacy Apple Foundation instead of dragging Apple API's into other platforms. If/since Apple is to rewrite its systems in Swift, Swift will likely evolve into the best language for migrating off C/C++.
Compare Graydon, von Rossum, or Chris Lattner to Java's Mark Reinhold. Mark has been quietly at the helm of Java since 1997, navigating: the Oracle and open-source transitions, partners ranging from IBM to broad developer communities, continuous VM updates that kept Java relevant, and the quick pace of recent language/library upgrades: lambdas (method and field handles), vector processing and FFI, native...
by mcguire on 6/5/23, 7:13 PM
"Exterior iteration. Iteration used to be by stack / non-escaping coroutines, which we also called "interior" iteration, as opposed to "exterior" iteration by pointer-like things that live in variables you advance. Such coroutines are now finally supported by LLVM (they weren't at the time) and are actually a fairly old and reliable mechanism for a linking-friendly, not-having-to-inline-tons-of-library-code abstraction for iteration. They're in, like, BLISS and Modula-2 and such. Really normal thing to have, early Rust had them, and they got ripped out for a bunch of reasons that, again, mostly just form "an argument I lost" rather than anything I disagree with today. I wish Rust still had them. Maybe someday it will!"
I remember that one. The change was shortly after I started fooling with Rust and was major. Major as in it broke all the code that I'd written to that point.
"Async/await. I wanted a standard green-thread runtime with growable stacks -- essentially just "coroutines that escape, when you need them too"."
I remember that one, too; it was one of the things that drew me to the language---I was imagining something more like Pony (https://www.ponylang.io/).
"The Rust I Wanted probably had no future, or at least not one anywhere near as good as The Rust We Got."
Almost certainly true. But The Rust We Got is A Better C++, which was never appealing to me because I never liked C++ anyway.
by ch33zer on 6/5/23, 10:45 AM
What a wonderfully self aware and honest piece of writing.
by Keyframe on 6/5/23, 8:25 AM
The Rust he wanted sounds a lot like Ada.
by zozbot234 on 6/5/23, 8:52 AM
Technically, Rust had no future prior to the 2018 edition. The fact that Rust can add new features as the use cases for it evolve is a strength of the language, one that it had from the start even with Graydon as a BDFL.
by tormeh on 6/5/23, 10:53 AM
I think Rust is somewhat cumbersome as a language, but I also think the right tradeoffs were made. There are far fewer and far worse competitors in the high-performance space than in the general purpose space.
by cmrdporcupine on 6/5/23, 9:21 PM
When I first read Graydon talking about his plans for Rust, I pictured it as StandardML (or OCaml) without a garbage collector, and I was sold. This list doesn't look fully like that, but is closer than current Rust is.
My interest back then was in a higher level language with type inference and a modern ML-like type system but that could be used for systems programming, especially in database, virtual machine, and even operating system dev.
These days I work pretty much full-time in Rust, and I think Rust as it is today delivers on some of that promise, but not all. I feel like the language's borrowing and ownership checking are pretty brilliant but really begin to become a pain when dealing with nested and interrelated trees of objects and iterators (like if building a compiler or query evaluator, etc.), and resorting to Arc/Rc/RefCell, etc. feels awkward.
I'm not sure if the language Graydon talks about here would have been better for that or not.
But I'm also happy we have Rust, because it's an improvement over what else is out there, and I hope the community gets through its growing pains.
by sheepscreek on 6/5/23, 1:20 PM
I’ll get straight to the point I want to make: Rust is suffering from an identity crisis. Much like Javascript.
Realizing this, I thoroughly feel the need for a “Rust, the good parts” doctrine.
A good portion of use-cases could be successfully implemented with a small subset of language. The small subset doesn’t need to be any more complicated than Go. And in doing so, we’d be reducing the entry barrier for masses and encouraging wider adoption.
Edited: For clarity
by superkuh on 6/5/23, 7:30 PM
Funny how every time I click a link to a dreamwidth.org hosted blog the,
>"Hello, you've been (semi-randomly) selected to take a CAPTCHA to validate your requests. Please complete it below and hit the button!"
...pops up and the button doesn't actually work. Truly one of the worst blog hosts out there if you actually want everyone to be able to read what you write.
by vintagedave on 6/5/23, 9:24 PM
> The other option, which I wanted, was for these to be compiler builtins open-coded at the sites of use, rather than library-provided. No "user code" at all (not even stdlib). This is how they were originally in Rust: vec and str operations were all emitted by special-case code in the compiler.
One of the things I like about Delphi is that it has some powerful types as compiler intrinsics. Sets, strings (the compiler-generated code does call into RTL methods for things like finding substrings, but the string type itself), and so forth are all compiler-generated.
I would like to see more, in fact: I think a map type would be a great inbuilt addition. (What I'd really like is compiler stubs so you could link in your own implementation. Whatever is linked in, it's then heavily optimised by the linker to be inlined etc as appropriate.)
by 0xDEF on 6/5/23, 2:19 PM
Rust moved in a direction where it is now a suitable alternative to C/C++ all the way down to operating system code and bare-metal embedded firmware.
Graydon wanted something else even before Rust 1.0 was released. He wanted an OCaml-like language with modern Go/Erlang-inspired higher level concurrency abstractions.
by smasher164 on 6/5/23, 10:00 PM
I admire Graydon's humility on the subject--and sure enough, I disagree with some of his ideas in this post, and agree with other ones.
- Explicit lifetimes are what make rust what it is. It would have surely failed had they not been introduced.
- I disagree about having a first-class module system instead of traits. Coherence and implicit instance resolution are a core value of Rust. `Send / Sync` are key examples of that.
- Green threads probably wouldn't been viable for rust, given the kind of programs it's targeting.
- Pretty much everything else however, I agree with.
by neonsunset on 6/5/23, 10:13 AM
I can't imagine Rust being even remotely viable without having generics or using LLVM to target a wide variety of platforms with sufficiently good codegen quality.
by pjmlp on 6/5/23, 2:37 PM
While it has a been a great piece of wrong to introduce affine type systems into mainstream, it hardly justifies outside domains where any kind of automatic memory allocation isn't either a blocker, or religious issue that won't be sorted out even by proving the contrary.
I see the ongoing attempts to add linear types for low level coding, alongside automatic resource management more future proof.
by rurban on 6/5/23, 12:57 PM
Interesting. So it looks like once he let the C++ folks in, they started to damage it. As they did with their own design decisions before.
by pmontra on 6/5/23, 10:19 AM
> The priorities I had while working on the language are broadly not the revealed priorities of the community that's developed around the language in the years since
Isn't that a matter of self selection? A language which developed around those priorities would have a community sharing those priorities now.
The point is if that community would be as large as the current one, larger, smaller.
by MontagFTB on 6/5/23, 1:23 PM
> Not 100% clear about actors -- I was weirdly focused on that model that in practice has many issues…
Any ideas what he meant here?
by TowerTall on 6/5/23, 8:41 AM
The article starts with "In a recent podcast about Rust leadership, the BDFL question came up again"
What it BDFL?
by svieira on 6/5/23, 3:12 PM
> Not 100% clear about actors -- I was weirdly focused on that model that in practice has many issues
Does anyone have any insights on the particular issues with actor-based concurrency vs. "direct parallelism like threads or locks" that he might be thinking about here?
by Lk7Of3vfJS2n on 6/5/23, 5:31 PM
Has Rust gone beyond the point of no return? Have less elegant features possibly been embedded in the language that have put Rust on the track to never become the hypothetically perfect or unblemished language?
by p0nce on 6/5/23, 10:28 AM
> First-class &
Interestingly like Graydon suggests this and 'tis something D has, you can only have `ref` for function parameters. This is something the users sometimes complain about, but I guess it has positives.
by aidenn0 on 6/5/23, 6:23 PM
I wanted nearly the same language Gradyon wanted, but I also suspect that my tastes are insufficiently mainstream for a language to my tastes to be as popular as Rust has become (much less as C++ is).
by Decabytes on 6/5/23, 10:57 AM
I know we haven’t gotten to that point yet, but I’m curious to see if in my lifetime we get a successor to Rust that fixes a lot of issues people have with the language now.
by codedokode on 6/5/23, 5:51 PM
I don't understand why in Rust integers wrap around. It doesn't make sense and there are vulnerabilities caused by wrapping integers in C.
by jimwhite42 on 6/5/23, 11:16 AM
On the "Async/await" wrt IO and FFI, I wonder what Graydon and others think about the Erlang BEAM or the GHC runtime implementation.
by qaq on 6/5/23, 10:04 AM
Will be interesting to see how things play out in Mojo as it looks like they will account for lessons learned by Rust community.
by parasense on 6/5/23, 4:51 PM
He's already created several programming languages, and there is still time to create his ideal.
by worik on 6/5/23, 8:21 PM
> basically every language discovers the long way that financial math is special and, at great length, eventually adds a decimal type.
And every case it is wrong
Financial math is not hard when you know how
Use integer types not horrific cludges like "decimal"
Just because IBM did it does not make it right. It is wrong
by garbagecoder on 6/5/23, 6:10 PM
>a viable c++ alternative
Wow, so one of the principal creators understands that that's what it is, not a replacement for everything under the sun.
And it's a GREAT c++ alternative, but ffs please stop telling me to use it for everything from webdev to embedded.
by camgunz on 6/5/23, 9:56 AM
I would love to play with the language Graydon describes here.
by olalonde on 6/5/23, 4:23 PM
> Explicit lifetimes
I never understood that one either. There is always only one "solution" that will make your program compile, so why not just let the compiler figure it out?
by cryptonector on 6/5/23, 6:50 PM
> Environment capture. I often say (provocatively) that "I hate lambda", but lambda is actually (at least) two separate language features: one is a notation for anonymous function literals; another is equipping those anonymous function literals with environment capture. I don't really care either way about having such a literal syntax, but I really do dislike equipping it with environment capture and think it's a mistake, especially in a systems language with observable mutation. Early Rust had something called "bind expressions" which I copied from Sather and which I think are better (clunkier but better). Rust gained lambda-with-environment-capture in a single package which I didn't object to strongly enough, as part of trying to make interior iteration work on LLVM-with-no-coroutines, and this motivation was later removed when we moved to exterior iteration. But "if I were BDFL" I would probably roll back the environment capture part (it's easier to tolerate for non-escaping closures which many are, eg. in non-escaping coroutines / stack iterator bodies, but .. eh .. complex topic).
TFA loses me here. I rather like the Fn/FnMut/FnOnce business, though yeah, closures of dynamic extent are very limited unless you Box them to make them of indefinite extent... and so the whole language lacks that character that functional languages with GCs have, but it's still functional, just functional with a straight-jacket.
Earlier in TFA there's a mention of exterior iteration as in generators, and I want to point out that while generators are very nice, they are not a substitute for closures. Icon, for example, had iterators and first-class co-routines ("co-expressions"), but no closures, and so where one needed closures one had to use co-routines (costly!). It's true that with generators one needs closures less than without generators, but still, closures are very important.
> Traits. I generally don't like traits / typeclasses. To my eyes they're too type-directed, too global, too much like programming and debugging a distributed set of invisible inference rules, and produce too much coupling between libraries in terms of what is or isn't allowed to maintain coherence. I wanted (and got part way into building) a first class module system in the ML tradition. Many team members objected because these systems are more verbose, often painfully so, and I lost the argument. But I still don't like the result, and I would probably have backed the experiment out "if I'd been BDFL".
This loses me too.
It's great then that Rust didn't have a BDFL! :)
> Underpowered existentials. The dyn Trait mechanism in Rust allows runtime and heterogeneous polymorphism, a.k.a. Existentials. These types are useful for many reasons: both solving heterogeneous representation cases and also selectively backing-off from monomorphization or inlining (when you have those) in order to favour code size / compile time or allow dynamic linking or runtime extension. Early Rust tried to use these extensively (see also "first-class modules") and actually had an intermediate-rigidity type called an obj that was always a sort of Cecil-like runtime-extensible existential glued to a self-type record that allowed method-by-method overriding at runtime (almost like a prototype-OO system). Today's Rust strongly discourages the use of any such dynamic dispatch, a feedback loop arising from both technical limitations placed on them and a library ecosystem that's taken that as a sign never to use them.
This, on the other hand, is a brilliant observation and I agree with it as with much else in TFA.
> Tail calls. I actually wanted them! I think they're great. And I got argued into not having them because the project in general got argued into the position of "compete to win with C++ on performance" and so I wound up writing a sad post rejecting them which is one of the saddest things ever written on the subject. It remains true with Rust's priorities today, I doubt it'll ever be possible across crates (maybe maybe within), but as with stack iterators IMO they're a great primitive to have in a language, in this case for writing simple and composable state machines, and "if I were BDFL" I probably would have pointed the language in a direction that kept them. Early Rust had them, LLVM mostly made us drop them, and C++ performance obsession kept them consigned to WONTFIX bug status.
Oh dear. TCO is essential, IMO. I understand that it may not be possible in cross-crate cases, but still, TCO is very important.
by demarq on 6/5/23, 12:54 PM
beautiful ending!
by avgcorrection on 6/5/23, 1:19 PM
I haven’t cared about what Hoare thinks of Rust since 2015.
1. He hasn’t been involved in the language for a long time
2. His vision for the language was completely different compared to how the remaining developers ended up designing it. So if I ended up liking Rust under his “BDFL”ing then it would be for completely different reasons compared to why I like (and dislike) Rust today