[HN Gopher] My "grand vision" for Rust
___________________________________________________________________
My "grand vision" for Rust
Author : todsacerdoti
Score : 90 points
Date : 2026-03-05 01:37 UTC (3 days ago)
(HTM) web link (blog.yoshuawuyts.com)
(TXT) w3m dump (blog.yoshuawuyts.com)
| satvikpendem wrote:
| Finally seeing more movement on effects or what started as
| keyword generics, there was a big blog post a few years ago but
| not much public facing news although of course they've been
| working on it as Yoshua says in the post.
|
| I truly do wish we get closer to Ada and even Lean in terms of
| safety, would be great to see all these theoretical type system
| features become reality. I use the `anodized` crate right now for
| refinement type features, and who knows, maybe we get full
| fledged dependent types too as there aren't many production
| languages with them and certainly not popular languages.
| pjmlp wrote:
| Reposting my comment from Reddit,
|
| I had some Scala 3 feelings when reading the vision, I hope Rust
| doesn't gets too pushy with type systems ideas.
|
| That is how we end with other ecosystems doubling down in
| automatic memory management with a good enough ownership model
| for low level coding, e.g. Swift 6, OxCaml, Chapel, D, Linear
| Haskel, OCaml effects,...
|
| Where the goal is that those features are to be used by experts,
| and everyone else stays on the confort zone.
| satvikpendem wrote:
| I doubt those languages would have the same level of traction
| as Rust, especially now that Rust has already gotten said
| traction over the past decade with even the Linux kernel using
| them. It's more likely that Rust will be written as today and
| then these extra features are added for more type safety in
| certain functions as like I said in another comment I doubt
| people are going to write type contracts for every single
| function (maybe LLMs will, but that's an orthogonal
| discussion).
| pjmlp wrote:
| Apparently you missed Swift.
|
| Linux kernel adoption of Rust hasn't been a smooth ride,
| exactly because of its type system among C folks.
|
| It is only happening because the likes of Google and
| Microsoft want to see it through.
| satvikpendem wrote:
| Swift is not really for systems level programming like Rust
| and interestingly some projects like Ladybird have moved
| away from Swift towards Rust.
| Ygg2 wrote:
| Doubt Rust will ever get to implicit hell of Scala 2.
|
| If for anything, Rust isn't married to C as Scala is to Java.
| Conscat wrote:
| My understanding is that Scala 3 came with many large breaking
| changes that made adoption difficult. I at least hadn't heard
| users complain that new features weren't desired.
| palata wrote:
| > I had some Scala 3 feelings when reading the vision, I hope
| Rust doesn't gets too pushy with type systems ideas.
|
| I don't know if it is true or not, but my feeling is that Scala
| brought a lot of new ideas. But as I read somewhere, "Scala was
| written by compiler people, to write compilers", and I can
| understand that feeling.
|
| Kotlin came after Scala (I think?) and seems to have gotten a
| lot of inspiration from Scala. But somehow Kotlin managed to
| stay "not too complex", unlike Scala.
|
| All that to say, Rust has been innovating in the zero-cost
| abstraction memory safe field. If it went the way of Scala, I
| wonder if another language could be "the Kotlin of Rust"? Or is
| that Zig already? (I have no idea about Zig)
| ozgrakkurt wrote:
| This sounds insane at this point. The language already has too
| many features. Would be cool if all these people with amazing
| visions could move it elsewhere.
|
| Rust is fast tracking being as bad as c++ in terms of just
| garbage in it.
|
| IMO the worst thing about c++ isn't that it is unsafe but it is
| extemely difficult to learn to a satisfying degree.
|
| This is already kind of feels true for Rust and it will be surely
| true if people just keep shoving their amazing ideas into it.
|
| IMO even async/tokio/error-handling aren't that well though out
| in rust. So much for keeping things out of the language.
|
| Maybe Rust just wasn't what I wanted and I am salty about it but
| it feels a bit annoying when I see posts like this and
| considering where Rust is now after many years of shoving stuff
| into it
| fabiensanglard wrote:
| I agree that the complexity is getting scary. They keep on
| adding more and more stuff and it is hard to follow.
| tcfhgj wrote:
| Could you expand a bit more?
| xiphias2 wrote:
| The main problem I see is adding things slowly instead of
| automatic rewrites.
|
| I remember adding lifetimes in some structs and then wanted to
| use generics and self pointing with lifetimes because that made
| sense, and then it didn't work because the composition of some
| features was not yet part of Rust.
|
| Another thing: there are annotations for lifetimes in function
| signatures, but not inside the functions where there is a lot
| of magic happening that makes understanding them and working
| with them really hard: after finally the borrow checking gave
| me errors, that's when I just started to getting lots of
| lifetime errors, which were not shown before.
|
| Rust should add these features but take out the old ones with
| guaranteed automatic update path.
| satvikpendem wrote:
| The edition mechanism covers your last paragraph.
| zozbot234 wrote:
| > The language already has too many features.
|
| That's actually the point. Many of these additions can be
| phrased as _unifying_ existing features and allowing them to be
| used in previously unusable ways and contexts. There 's
| basically no real increase in user-perceived complexity. The
| Rust editions system is a key enabler of this, and C++ has
| nothing comparable.
| pjmlp wrote:
| It has clang tidy, -std=lang-version, and preprocessor that
| is version aware.
|
| Rust editions don't cover all use cases that one can think of
| regarding language evolution, and requires full access to
| source code.
| SkiFire13 wrote:
| > requires full access to source code
|
| What do you mean? Editions don't require full access to
| source code. Rust in general relies heavily on having
| access to source code, but that has nothing to do with how
| editions work
| zozbot234 wrote:
| You can write a binary library that exposes a C ABI using
| Rust (which is indistinguishable from an ordinary C/C++
| library) and then provide source for a Rust wrapper crate
| that provides a "safe" interface to it, much like a C
| header file.
| pjmlp wrote:
| Yes they do, when mixing crates from various editions and
| how changes interact together.
| aw1621107 wrote:
| > when mixing crates from various editions and how
| changes interact together.
|
| Could you elaborate more on this? It's not obvious to me
| right now why (for example) Crate A using the 2024
| edition and Crate B using the 2015 edition would require
| both full access to both crates' source beyond the
| standard lack of a stable ABI.
| pjmlp wrote:
| Because in order to have standard library breaking
| changes across editions, if those types are exposed in
| the crate public types, or change their semantics across
| editions, the compiler has to be able to translate
| between them when generating code.
|
| See the Rust documentation on what editions are allowed
| to change, and the advanced migration guide on examples
| regarding manual code migration.
|
| Not so much what has happened thus far, rather the
| limitations imposed in what is possible to actually break
| across editions.
| Rusky wrote:
| Or put another way, a hypothetical feature that you made
| up in your head is the thing that requires source access.
| Editions do not let you change the semantics of types.
|
| To be fair, Rust tooling does tend toward build-from-
| source. But this is for completely different reasons than
| the edition system: if you had a way to build a crate and
| then feed the binary into builds by future compilers, it
| would require zero additional work to link it into a
| crate using a different edition.
| pjmlp wrote:
| Exactly, hence why people should stop talking about
| editions as if they sort out all Rust evolution problems,
| in your own words it doesn't allow changing type
| semantics
| aw1621107 wrote:
| What you're describing sounds more like a _potential_
| issue with editions if /when they allow breaking stdlib
| changes more than a problem with editions as they exist
| today, which is more what I took the original comment to
| be talking about.
| pjmlp wrote:
| Exactly because they don't allow it, they don't cover all
| scenarios regarding language evolution
| jstanley wrote:
| https://xkcd.com/927/
| wtetzner wrote:
| Can you explain how this is relevant here?
| patrick451 wrote:
| This comparison is useless until rust commits to a stable
| ABI.
| satvikpendem wrote:
| It doesn't have too many features, it arguably does not have
| enough. The issue is that the current features don't play
| nicely with each other, so much of the work has been in making
| sure they do, such as with async traits as an example: there is
| no reason why you can make a function async but not inside a
| trait, and this was the case until very recently.
|
| Beyond that, what the article shows is exactly what I want, I
| want as much type safety as possible especially for critical
| systems code which is increasingly what Rust is being used for.
| LiamPowell wrote:
| This inevitably happens when the approach to language design
| is "try it and see". I know people here hate design-by-
| committee, but historically it's led to some very cohesive
| languages.
| satvikpendem wrote:
| Yes, however how many of them are used in production to
| some level of scale (not even to the scale of Rust)?
| Stroustrup's quote and all that.
|
| Rust's development process is also design by committee,
| interestingly enough.
| LiamPowell wrote:
| > Rust's development process is also design by committee,
| interestingly enough.
|
| Sure, but it's still quite informal and they just add
| things as they go instead of writing a complete standard
| and figuring out how everything interacts before anything
| is added to the language. Design-by-committee was
| probably not the best term to use.
| metaltyphoon wrote:
| > I know people here hate design-by-committee, but
| historically it's led to some very cohesive languages.
|
| C++ is not cohesive at all
| LiamPowell wrote:
| I didn't say this applies to every committee, but I do
| think the opposite applies to almost every "try it and
| see" language.
|
| Examples of cohesive languages designed by committees
| would be Ada and Haskell.
| pjmlp wrote:
| Haskell is anything but cohesive, depending on which
| feature flags are enabled on GHC, or any other compiler.
| scrubs wrote:
| Well ok ... experiment but maybe unlike c++ we could have
| added N keywords removed M keywords for arguably net-
| simpler language.
|
| Geez I'd hate to be in rust dev shoes if I can't remove
| something later when I have a better better min/max. I
| guess this could be done off main, stable.
| Starlevel004 wrote:
| Rust is also design-by-committee.
| wolvesechoes wrote:
| > design-by-committee
|
| I don't think it is about having committee, but rather
| having a spec. And I mean spec, not necessarily ISO
| standard. There should be a description of how specific
| features work, what is expected behavior, what is
| unexpected and should be treated as bug, and what is
| rationale behind specific decision.
|
| Coincidentally people here hate specs as well, and that
| explains some things.
|
| I know there is some work on Rust spec, but it doesn't seem
| to progress much.
| bitwalker wrote:
| AIUI, that is what the MIR formalization work is about,
| and it seems to be moving along fine. My impression is
| that covers essentially all the interesting parts of Rust
| worth specifying formally.
| SkiFire13 wrote:
| Re: async in traits, the feature was delayed because it
| relied on the "Generic Associated Types" and "Impl Trait in
| Traits" features. If Rust delayed the whole `async` feature
| for working on those pretty type-theoretic features what
| would you have thought?
| satvikpendem wrote:
| Well in practice the async_trait crate worked just fine. If
| Rust delayed the whole async feature I'd have thought
| they'd have better been able to handle the function
| coloring problem via something like OCaml's algebraic
| effects rather than following the trend of JS and C# back
| then, as OCaml's came along much later after more research
| into the model.
| jcranmer wrote:
| You're not wrong here. Not that I'm entirely up-to-speed on all
| of the deep Rust discussions, but the sense I have of the
| language evolution is that while there is definitely a _loud_
| contingent of people pushing for a lot of the complexity of
| full effect systems or linear types, these sorts of proposals
| aren 't actually all that likely to actually move forward in
| the language.
|
| (I should note that of all of the features mentioned in this
| blog post, the only one I actually expect to see in Rust
| someday is pattern types, and that's largely because it
| partially exists already in unstable form to use for things
| like NonZeroU32.)
| satvikpendem wrote:
| Yoshua works directly on developing the language, and
| mentions he is working on these features specifically (he is
| part of the effects initiative), I'm not sure you won't see
| these features in Rust.
| Rusky wrote:
| Yoshua is part of the "loud contingent" being described.
| He's not on the lang team, and he's been "working on"
| things like keyword generics for years without any
| indication that they are going to make it into the
| language.
| tcfhgj wrote:
| What complexity?
| j-krieger wrote:
| After working with Rust for half a decade I'm afraid I have to
| agree. A lot of the newer features have weird edge cases with
| promises for fixes stuck in bikeshedding hell for years
| (looking at you const generics). Alternatively feature authors
| wait on dependecies that will never ship.
| russdill wrote:
| I think part of the idea is you and to make it impossible to
| misuse an underlying API. This can make development much less
| complex.
| arrty88 wrote:
| I would love to have a use case to learn and write rust today.
| But i am deep in node and go services for my employer. Previously
| wrote java and c#. What are people writing in rust today?
| satvikpendem wrote:
| Whatever I used to use Node for, like web servers, I now use
| Rust. It's pretty nice, with a strong OCaml-like type system
| which I've used before (better than TypeScript even in some
| cases), plus it's much faster and more memory efficient such
| that I can run way more services on my 5 dollar Hetzner box
| with Dokploy compared to Node or Java or C#.
| TeamDman wrote:
| I use Rust for command line applications.
|
| I find that CLI is a great way to model problems. When I find
| myself doing something that has graduated beyond a comfortable
| amount of PowerShell, Rust is there for me.
|
| I have a template I've been evolving so it's super easy to get
| started with something new; I just copy the template and slam
| Copilot with some rough ideas on what I want and it works out.
|
| https://github.com/teamdman/teamy-rust-cli
|
| Just today used it to replace a GitHub stats readme svg
| generator thing that someone else made that was no longer
| working properly.
|
| https://github.com/TeamDman/teamy-github-readme-stats
|
| Decomposes the problem very nicely into incrementally
| achievable steps
|
| 1. `fetch <username>` to get info from github into a cache
| location 2. `generate <username> <output.svg>` to load stats
| and write an svg 3. `serve` to run a webserver to accept GET
| requests containing the username to do the above
|
| Means that my stuff always has `--help` and `--version`
| behaviours too
| raphinou wrote:
| I'm working on a multisig sign-off solution, with the first use
| case being file downloads like GitHub releases authentication:
| https://github.com/asfaload/asfaload
|
| I'm coming from F# and find rust a good compromise: great type
| safety (though I prefer the F# language) with an even better
| ecosystem. It can also generate decently sized statically
| compiled executables, useful for CLI tools, and the library
| code I wrote should be available to mobile apps (to be
| developed).
| ChadNauseam wrote:
| I'm having fun using it to make websites. Rust-WASM works
| really well. Definitely a very enjoyable way to make web apps.
| I've been trying to think how I can contribute to the
| ecosystem, seeing as I enjoy it so much. Rust gives you a
| control over memory that is impossible to replicate in
| javascript, and which allows much more performant code
| jadenPete wrote:
| I couldn't disagree more. Most of my company's backend code is
| written in Scala, and most of our engineers dislike it because
| the language is difficult to understand, has way too many
| features, and has many ways to solve the same problem. I don't
| want Rust to continue down this path, and I already worry with
| some of the syntactic sugar and type system additions being
| discussed that it already has.
|
| A language's type system doesn't need to model every possible
| type of guarantee. It just needs to provide a type safe way to do
| 95% of things and force its users to conform to use the
| constructs it provides. Otherwise it becomes a buggy hodge podge
| of features that interact in poor and unpredictable ways. This is
| already the case in Scala; we've discovered almost 20 bugs in the
| compiler in the past year.
| satvikpendem wrote:
| There is a middle ground. People seem to use Haskell and OCaml
| just fine and both are as expressive, so maybe it is just Scala
| having shoved in too many things. Based on what the article
| shows, it doesn't seem like they're making ten different ways
| to do the same thing but rather one way to (optionally) get
| more type safety out. I doubt everyone will be writing
| dependent type contracts for every single function, it's more
| for certain pieces of the codebase.
| MrBuddyCasino wrote:
| Ah yes Haskell, the reasonable centrist position in language
| design.
| satvikpendem wrote:
| Compared to the other languages listed in this thread, it
| definitely is, and it has production systems unlike them.
|
| https://news.ycombinator.com/item?id=47259148
| MrBuddyCasino wrote:
| You got a point there.
| pjmlp wrote:
| Ever heard of Apple, Facebook, Jane Street, HP?
| Animats wrote:
| This may be too much advanced type theory for a useful language.
|
| You can go all the way to formal verification. This is not enough
| for that. Or you can stop at the point all memory error holes
| have been plugged. That's more useful.
|
| You can go way overboard with templates/macros/traits/generics.
| Remember C++ and Boost. I understand that Boost is now
| deprecated.
|
| I should work some more on my solution to the back-reference
| problem in Rust. The general idea is that
| Rc/Weak/upgrade/downgrade provide enough expressive power for
| back references, but the ergonomics are awful. That could be
| fixed, and some of the checking moved to compile time for the
| single owner/multiple users case.
| wofo wrote:
| Thanks for posting this! As a long-time Rust user (and
| contributor, in the good old days), the thing that has always
| fascinated me about Rust is the healthy balance it strikes
| between academic brilliance and industry pragmatism. Radical
| changes like the ones suggested by the OP risk damaging that
| balance IMO. I'd rather put up with some language quirks and
| see Rust achieve "boring technology" status...
|
| But who knows, maybe the "academic brilliance" from the article
| is more pragmatic than I give it credit for. I sure hope for it
| if these changes ever go through.
| tensor wrote:
| How are these suggestions not pragmatic? You don't _have_ to
| use them, but if you need them they are there. From a
| security point of view I can see many of these being
| incredibly useful.
| usrusr wrote:
| If it slows down Rust development it's not pragmatic. And
| if it creates a cultural schism between full commitment and
| pragmatic approaches, it's also trouble. Remember Scala?
| Animats wrote:
| The lack of use cases in that document is a concern. They're
| all "nice to have" features, but is the payoff there for real
| work? The "effects" section mentions properties useful for a
| proof system. But it's not part of a proof system. If it
| were, most of those could be found automatically by static
| analysis, without bothering the programmer. (I was doing that
| decades ago in a very early proof of correctness system.)
| Getting programmers to annotate items is tough. Just getting
| C++ programmers to use "const" enough is hard.
|
| "View types" are interesting. But how much of that generality
| is really needed? We already have it for arrays, with
| "split_at_mut" and its friends. That's a library function
| which uses "unsafe" but exports a safe interface. The
| compiler will already let you pass two different fields of a
| struct as "&mut". That covers the two most pressing cases.
| simonask wrote:
| I would also have liked to see some motivational examples,
| but I think the most interesting upside of an effect system
| is composability.
|
| Rust is actually really unique among imperative languages
| in its general composability - things just compose really
| well across most language features.
|
| The big missing pieces for composability are higher-kinded
| types (where you could be generic over Option, Result,
| etc.), and effects (where you could be generic over async-
| fn, const-fn, hypothetical nopanic-fn, etc.)
|
| The former becomes obvious with the amount of interface
| duplication between types like Option and Result. The
| latter becomes obvious with the number of variants of
| certain functions that essentially do the same thing but
| with a different color.
| pjmlp wrote:
| Boost is as actual as ever.
|
| Also the way nowadays is with constexpr, templates, and around
| the corner, static reflection.
| throwaway27448 wrote:
| > You can go way overboard with
| templates/macros/traits/generics.
|
| You can go overboard on any language concept imaginable, but
| conflating all these mechanisms makes it sound like you haven't
| interacted much with non-C++ languages--particularly since rust
| doesn't have templates or anything like templates, traits are
| an entirely unrelated composition mechanism, and macros are
| entirely unrelated to the type discussion in the article.
|
| This isn't really "advanced type theory" so much as picking up
| programming language developments from the 90s. I suppose it's
| "advanced" in the sense that it's a proper type system and not
| a glorified macro ala templating, but how is that a bad thing?
| Cpoll wrote:
| Agreed. Generics are in most modern typed languages, and
| traits are essentially interfaces. Maybe templates means C++
| templates, which are essentially generics?
| mihaelm wrote:
| My guess is they meant metaprogramming in general
| (templates/generics, macros), but traits are not quite like
| the others.
| nesarkvechnep wrote:
| In C++, concepts are essentially generics where templates
| are more like weird macros.
| Ygg2 wrote:
| > This may be too much advanced type theory for a useful
| language.
|
| Maybe but:
|
| - Move fixes Pin
|
| - Linear types, prevent memory leaks
|
| - potentially effects simplify so many things
|
| Each of these functionalities unlock capabilities people have
| complained about Rust. Namely async, gen blocks, memory leaks.
| dnautics wrote:
| I'm not 100% convinced that "plugging memory error holes" was
| right at the compiler level.
|
| Currently building out clr, which uses a heuristic (not formal
| verification) method for checking soundness of zig code, using
| ~"refinement types". In principle one could build a more formal
| version of what I'm doing.
|
| https://github.com/ityonemo/clr
| usrusr wrote:
| Counterpoint: if any language could thrive in that valley of
| despair between pragmatic and theoretical excellence you're
| referring to, it would be Rust. Because so much of the cost is
| already paid for once you have satisfied the borrow checker. At
| least that's what I'd imagine, I could certainly be wrong.
| Conscat wrote:
| > I understand that Boost is now deprecated.
|
| Huh?? Boost is used basically everywhere.
| zamalek wrote:
| I'm terrified by the notion of try fns. Are we getting exceptions
| (and therefore losing one of rust's greatest features)?
| Pedro_Ribeiro wrote:
| Isn't his point exactly that we don't want to have too many
| function colors and instead want a generic way of declaring
| side effects so people can do what they want (be it try fns,
| IO, async, etc..., no panicking)?
| pkal wrote:
| From the historical sources I could find online, it appears that
| Rust's borrow system was independently invented, or at least they
| don't mention linear logic or anything substructural. This is
| kind of interesting to me, especially given the reactions in this
| thread, and ties into the general difficulty of PL research to
| find acceptance among practitioners, especially when presented by
| researchers (which I think is regretful, I like the ideas in the
| article!). Perhaps we really should stick to terminology like
| "function colors" to make effect systems more popular (or not,
| because the color framing makes it sound bad to have different
| colors in a program, IIRC).
| jltsiren wrote:
| It's the jargon, I think. PL research is in an awkward
| position, where the jargon is not shared with the much wider
| community of people using programming languages daily. From the
| other side, it looks like there is a small body of
| theoreticians using impenetrable language for discussing topics
| I'm supposed to be familiar with, because they are a core part
| of my day job. It's much easier to accept jargon, when it's
| used in a clearly separate field.
|
| Some of the terminology is just unfortunate. For example, I
| have an intuitive understanding of what a type means. The
| meaning used in PL theory is somehow wider, but I don't really
| understand how.
|
| And then there is my pet peeve: side effect. Those should be
| effects instead, because they largely define the observable
| behavior of the program. Computation, on the other hand, is a
| side effect, to the extend it doesn't affect the observable
| behavior.
|
| But then PL theory is using "effect" for something completely
| different. I don't know what exactly, but clearly not something
| I would consider an effect.
| voxl wrote:
| Man who uses arithmetic upset at research mathematicians for
| using words like R-module when they clearly do not mean a
| module in C++
|
| More at 11
| phplovesong wrote:
| async rust is the worse async out there. I prayed that rust did
| not include a async at all. But the JS devs pushed it thru. That
| pretty much sealed my rust use. Im still salty.
| simonask wrote:
| You know what, I've heard people say this and thought "OK,
| maybe these other languages with GCs and huge runtimes really
| do something magical to make async a breeze".
|
| But then I actually tried both TypeScript and C#, and no.
| Writing correct async code in those languages is not any nicer
| at all. What the heck is ".ConfigureAwait(false)"? How fun do
| you really think debugging promise resolution is? Is it even
| possible to contain heap/GC pressure when every `await`
| allocates?
|
| Phooey. Rust async is doing just fine.
| palata wrote:
| How does it compare to Kotlin async? I find Kotlin generally
| hits a good balance across the board.
| wewewedxfgdf wrote:
| No-one ever has the "Grand Vision" to cut something down to it's
| essential 25% and delete the rest.
___________________________________________________________________
(page generated 2026-03-08 23:00 UTC)