15 ms·

My “grand vision” for Rust

274 points by todsacerdoti 8mo ago

satvikpendem 8mo ago
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 8mo ago
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 7mo ago
  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 7mo ago
    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 7mo ago
      Swift is not really for systems level programming like Rust and interestingly some projects like Ladybird have moved away from Swift towards Rust.
      - pjmlp 7mo ago
        It certainly is for Apple, regardless of your opinion. It is all over the place in Swift documentation, WWDC sessions, and even last week on Meet the Team session, regarding on how to write safe systems programming code on Apple platforms. Ladybird should focus on what language they actually want to deliver something.
      - wolvesechoes 7mo ago
        > Swift is not really for systems level programming Apple seems to think differently. > and interestingly some projects like Ladybird have moved away from Swift towards Rust. Not really interesting after you spent some time tracking lifecycle of FOSS projects. I don't think it is a last "moving away" announcement we get from Ladybird.
- Ygg2 7mo ago
  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.
  - pjmlp 7mo ago
    It certainly is in what concerns ABI support, and dependency on LLVM.
    - Ygg2 7mo ago
      Scala had an unnatural dependency on Java, not JVM. I.e., imitating not just some patterns but copying its flawed interfaces. For example, Scala could express and bypass decades of cruft in the Java Collections API. Did it choose to do it? To paraphrase former Scala developer and present poker player, "If Java cut its nose, would you Scala... Oh god, stop! The blood, the blood!" Everyone who wants to talk to low-level code has to have C ABI. The equivalent Scalaism in Rust would be if Rust reimplemented the C-inspired java.util.Date. Yes. Monday should be 0, not an enum. Because C did it.
- Conscat 7mo ago
  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 7mo ago
  > 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)
  - zozbot234 7mo ago
    > I wonder if another language could be "the Kotlin of Rust"? Some people would say that Swift is that language since it's potentially memory safe like Rust and is described as friendlier to novices. There's some room for disagreement wrt. the latter point.
    - palata 7mo ago
      Well many languages are memory safe. Java has been memory safe forever. Rust is the one that is memory-safe with zero-cost abstractions, right?
      - bombela 7mo ago
        Rust is also data race safe to boot.
  - hocuspocus 7mo ago
    > But somehow Kotlin managed to stay "not too complex", unlike Scala. It's not really true anymore, Kotlin has slowly absorbed most of the same features and ideas even though they're sometimes pretty half-baked, and it's even less principled than the current Scala ecosystem. JetBrains also wants to make Kotlin target every platform under the sun. At this point, the only notable difference are HKTs and Scala's metaprogramming abilities. Kotlin stuck to a compiler plugin exposing a standard interface (kotlinx.serialization) for compile-time codegen. Scala can do things like deriving an HTTP client from an OpenAPI specification on the fly, by the LSP backend.
ozgrakkurt 7mo ago
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 7mo ago
  I agree that the complexity is getting scary. They keep on adding more and more stuff and it is hard to follow.
  - tcfhgj 7mo ago
    Could you expand a bit more?
- xiphias2 7mo ago
  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 7mo ago
    The edition mechanism covers your last paragraph.
arrty88 7mo ago
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 7mo ago
  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 7mo ago
  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 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 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 7mo ago
  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 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).
jadenPete 7mo ago
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 7mo ago
  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 7mo ago
    Ah yes Haskell, the reasonable centrist position in language design.
    - satvikpendem 7mo ago
      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 https://news.ycombinator.com/item?id=47259148
      - MrBuddyCasino 7mo ago
        You got a point there.
Animats 7mo ago
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.
- pjmlp 7mo ago
  Boost is as actual as ever. Also the way nowadays is with constexpr, templates, and around the corner, static reflection.
- wofo 7mo ago
  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 7mo ago
    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 7mo ago
      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?
zamalek 7mo ago
I'm terrified by the notion of try fns. Are we getting exceptions (and therefore losing one of rust's greatest features)?
- Pedro_Ribeiro 7mo ago
  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)?
  - zamalek 7mo ago
    From the article: > And on nightly it also has support for try fn and gen fn. I haven't been able to figure out what a try fn is.
pkal 7mo ago
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).
- deleted 7mo ago
  [deleted]
- jltsiren 7mo ago
  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 extent 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 7mo ago
    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
- egorelik 7mo ago
  I don't remember where I read it, but I think Rust cited Cyclone as an influence, a variation of C with "region-based" memory management - more or less the literature name for "lifetimes". I think Rust may be the first to use it directly for stack variables, however.
phplovesong 7mo ago
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 7mo ago
  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 7mo ago
    How does it compare to Kotlin async? I find Kotlin generally hits a good balance across the board.
  - usrnm 7mo ago
    Try golang, where they did the only sane thing: everything is async from the very beginning, no function colouring
    - simonask 7mo ago
      I think practical experience with Go reveals that this choice being “the only sane thing” is highly debatable. It comes with huge drawbacks.
      - usrnm 7mo ago
        Of course it has drawbacks, everything does, but my practical experience has been hugely in favor of what golang is doing, at least, in terms of cognitive load and code simplicity. It is very much worth it in many, many cases
wewewedxfgdf 7mo ago
No-one ever has the "Grand Vision" to cut something down to it's essential 25% and delete the rest.
- techbrovanguard 7mo ago
  By all means, write some Go instead—you might want to order a new `if err != nil` button to stave off the RSI. The rest of us are trying to make things better.
- ebiederm 7mo ago
  Chuck Moore of Forth fame.
- lioeters 7mo ago
  Unless there's a conscious and constant effort to keep things simple, a programming language or software project will grow to consume all available resources, developers' time, intellectual capacity, and funding.
- chiffaa 7mo ago
  You can't cut down a language without breaking changes. And there fairly often are internal changes to simplify the compiler and the tooling. Just in the latest release, annotation internals were finally fully unified between rustc, cargo, clippy and other tools. This was a fairly considerable effort in deduplicating code. Borrow checker is being rewritten to move to tree borrows, trait resolution is being refactored for a variety of reasons. Code is being simplified where possible, but this doesn't mean Rust doesn't have areas to improve in, especially if there is a goal of replacing Ada/SPARK
- nsm 7mo ago
  https://without.boats/blog/revisiting-a-smaller-rust/ https://without.boats/blog/revisiting-a-smaller-rust/ I think there is a programming language hole for a Rust-like language, but with GC and green threads. One that dispenses with single-ownership, and async/await footguns. Something like F#/Kotlin is closest in terms of developer experience. Unfortunately, we are really lacking a language that skews badly on some other axis - F# - tainted by being Windows only for really long and being Microsoft. - Kotlin - tainted by the JVM - Java 24+ - has virtual threads, sum types, match expressions and other niceties, but tainted by the JVM again (Verbosity included, but this is not really a factor with IDEs and LLMs.) Note that the opinions above are not mine, but "consensus". I'd say they are all unfair opinions. I feel like people end up favoring new languages, simply because of novelty. Like, inevitably, somebody is gonna say Gleam. I'm all for having existing BEAM users getting access to new languages, but I'm not sure why one would pick a BEAM language for non-server applications when the developer tooling story for CLI apps, line-of-business apps and so on is so much stronger for the .NET and JVM ecosystems. No offense to the Gleam folks intended.
irenetusuq 7mo ago
[dead]
plantain 7mo ago
I used to hate Golang for not having generics and how verbose getting basic things done was. Then I read posts like this and realise, my god, Rob Pike was so, so right. Do these people ever ship anything? Or is it just endless rearranging of deckchairs?
- beanjuiceII 7mo ago
  I already need a reference to read rust code, looks like I'll need a third reference sheet. The language is currently bordering on spaghetti
  - ozgrakkurt 7mo ago
    The most annoying part is that you can't just go to source code or docs and understand some code. I still can't do it after spending many years using it. You have to wade through 7 layers of macros and traits to understand some basic thing most of the time. It is easier to understand musl-libc code compared to understanding a http library in rust which is just insane to me.
- pjmlp 7mo ago
  I mostly agree, however it wouldn't harm Go, even to get back some of the niceties of Limbo that it still misses.
conorbergin 7mo ago
Thank God for Zig
- esafak 7mo ago
  Elaborate.
  - conorbergin 7mo ago
    I don’t think PL theory driven design produces good systems languages.
    - zozbot234 7mo ago
      Rust as it exists today is very much "PL theory" driven. It's not necessarily a good language, but it's been consistently ranked as the #1 "most loved" by Stack Overflow for the past few years.
- pjmlp 7mo ago
  For bringing us back to Modula-2?
QuantumNoodle 7mo ago
I write production Rust code that becomes critical infra for our customers. I got tired of nil checks in Go and became a squeaky wheel in incident retros, where I finally got the chance to rewrite parts of our system in Rust during a refactor. I admit the skill issue on my part, but I genuinely struggled to follow the concepts in this article. Working alongside peers who push Rust's bleeding edge, I dread reviewing their code and especially inheriting "legacy" implementations. It's like having a conversation with someone who expresses simple thoughts with ornate vocabulary. Reasoning about code written this way makes me experience profound fatigue and possess an overwhelming desire to return to my domicile; Or simply put, I get tired and want to go home. Rust's safety guardrails are valuable until the language becomes so complex that reading and reasoning about _business_ logic gets harder, not easier. It reminds me of the kid in "A Christmas Story" bundled so heavily in winter gear he cant put his arms down[0]. At some point, over-engineered safety becomes its own kind of risk even though it is technically safer in some regards. Sometimes you need to just implement a dang state machine and stop throwing complexity at poorly thought-through solutions. End old-man rant. [0]: https://youtu.be/PKxsOlzuH0k?si=-88dxtyegTxIvOYI https://youtu.be/PKxsOlzuH0k?si=-88dxtyegTxIvOYI
- QuaternionsBhop 7mo ago
  > Reasoning about code written this way makes me experience profound fatigue and possess an overwhelming desire to return to my domicile; I didn't understand that you were making fun of verbosity until the word 'domicile'. I must be one of those insufferable people who expresses simple thoughts with ornate vocabulary... The article was comprehensible to me, and the additional function colorings sound like exciting constraints I can impose to prevent my future self from making mistakes rather than heavy winter gear. I guess I'm closer to the target audience?
- baby 7mo ago
  I really think that golang makes it easy to read code, rust makes it easy to write code. If Golang had sum types it would be a much nicer language to write complex applications with
  - 7mo ago
jbritton 7mo ago
When I wrote my very first Rust code, I was trying to write to a socket. I got stuck on this task with misleading error messages for the longest time. I finally realized I had not made the socket object mutable. I’m used to Posix where you have an integer file descriptor and I don’t tend to think of socket write as a mutable operation. At least it doesn’t mutate state that my app manages. Perhaps something in the kernel gets mutated. I believe the socket interface may have been intended to support queuing which is perhaps why it needed to be mutable. I might have needed a lower level api. I just mention this because I think it’s interesting as to how it should be typed when mutation is external to the app. I didn’t follow through on using Rust and this was long ago so I’m sure some details are wrong.
- holden_nelson 7mo ago
  I also found it really unintuitive what needs to be made mutable. And still do to some degree. When I first had learned that rust had this concept of “opt-in” mutability, I thought that it must then be an accepted pattern that we make as little as possible be mutable in an attempt to help us better reason about the state of our program. I had come to rust after learning some clojure so I was like “ahh! Immutable by default! So everything’s a value!” But in reality it feels like rust code is not “designed” around immutability but instead around appeasing the borrow checker - which is actually pretty easy to reason about once you get the hang of the language. But it’s a ton to learn up front
- estebank 7mo ago
  > got stuck on this task with misleading error messages for the longest time. Could you elaborate on that? We consider misleading error messages to be bugs and would like to know more on case we could fix them.
  - jbritton 7mo ago
    It appears the error message has been improved.
- undeveloper 7mo ago
  I think part of it might be just that for modeling's sake it makes it clear when something can write vs only read the socket
esafak 7mo ago
These would be great additions. I don't get why people don't want powerful type systems. Let the language work for you!
hardwaresofton 7mo ago
Really excited for the possibilities here. People undoubtedly thought going for Affine types was too much, and even simple things like null safety or enums-with-values and the prevalence of Result saw debate with minimalists voicing concerns. A world where you could write a Rust program that is memory leak free with Affine types is one I want to live in. Haskell can do it now, but its just not easy and Rust has beat out Haskell with its mix of ML-strength types and practicality. IMO these changes maintain Rusts winning mix of academia and practicality. Heres a proof point — dependent types weren't mentioned :)
- hardwaresofton 7mo ago
  *linear types (the leak free future bit) This description is also a good crystallization of why one would want linear types
pornel 7mo ago
It's hard to see features through the programming language theory jargon, but solid theoretical foundations have worked well for Rust so far. Jargon terms like "sum types" or "affine types" may seem complicated, but when you see it's actually "enums with data fields", it makes so much sense, and prevents plenty of state-related bugs. Proposed "effects" mean that when you're writing an iterator or a stream, and need to handle error or await somewhere in the chain, you won't suddenly have a puzzle how to replace all of the functions in the entire chain and your call stack with their async or fallible equivalents. "linear types" means that Rust will be able to have more control over destruction and lifetime of objects beyond sync call stack, so the tokio::spawn() (the "Rust async sucks" function) won't have to be complaining endlessly about lifetimes whenever you use a local variable. I can't vouch for the specifics of the proposed features (they have tricky to design details), but it's not simply Rust getting more complex, but rather Rust trying to solve and simplify more problems, with robust and generalizable language features, rather than ad-hoc special cases. When it works it makes the language more uniform overall and gives a lot of bang for the buck in terms of complexity vs problems solved.
- ozgrakkurt 7mo ago
  What worked for rust is having enums, sane-ish error handling, having sane integer types and the borrow checker, good tooling. The rest is just not that useful compared to how much garbage it creates
  - ChadNauseam 7mo ago
    You didn't mention parametric polymorphism, which is incredibly useful and important to the language. I'm guessing you intentionally excluded async, but to describe it as "not that useful" would just be wrong, there is a large class of programs that can be expressed very simply using async rust but would be very complicated to express in sync rust (assuming equivalent performance).
    - ozgrakkurt 7mo ago
      Yes rust async isn’t good imo. You can do basically the same thing with stackfull coroutines. Also the ecosystem is setup so you have to use tokio and everything has to be an Arc.
undeveloper 7mo ago
I'm not sure why people are so deeply scared. these are all pretty neat features for people who will need them (off rip seemingly mostly in the embedded world). It's not like the inclusion of these forces you to use them — I've never had to deal with unsafe rust for shipping web stuff, and I highly doubt I'd have to deal with most of these. For modeling's sake it would be nice to have pattern types and view types, I can see them being useful
- simplesocieties 7mo ago
  This was the exact same argument used to push new c++ features and look where the language is now.
  - devnullbrain 7mo ago
    ...a far better place than 2011.
  - gpderetta 7mo ago
    you mean better than ever?
- ozgrakkurt 7mo ago
  People will push this crap into production codebases and link to these articles when you say you don’t want complexity. Best way to manage is to not make it possible, like go. You indirectly deal with this kind of thing when compiling web server code too. It compiles super slow and can have weird errors. This is because the people who build the web stack in rust used a million traits/generics/macros etc. Even if you look at something like an io_uring library in rust, it uses a bunch of macros instead of just repeating 3 lines of code.
  - anon291 7mo ago
    3 lines of code that may need to change is much more complex than a macro that signals intent.
simplesocieties 7mo ago
The rust maintainers need to learn from the mistakes of the c++ design committee and understand that not adding a feature at all is in itself a desirable feature. For example, your section on effects: > Functions which guarantee they do not unwind (absence of the panic effect) * I actually don’t see how this is any more beneficial than the existing no_panic macro https://docs.rs/no-panic/latest/no_panic/ https://docs.rs/no-panic/latest/no_panic/ > Functions which guarantee they terminate (absence of the div effect) > Functions which are guaranteed to be deterministic (absence of the ndet effect) > Functions which are guaranteed to not call host APIs (absence of the io effect) The vast majority of rust programs don’t need such validation. And for those that do, the Ferrocene project is maintaining a downstream fork of the compiler where this kind of feature would be more appropriate. I think rust is in a perfect spot right now. Covers 99.99% of use cases and adding more syntax/functionality for 0.001% of users is only going to make the language worse. The compiler itself provides a powerful api via build.rs and proc macros which let downstream maintainers build their desired customization.
- ozgrakkurt 7mo ago
  You just know some guy will try to make cli code no-panic/deterministic use a bunch of crap and think he achieved something. Just not allowing complex code is so much better than this. Just even being able to look at a piece of code and trace what it is doing is 1000x more valuable than this. I regretted almost every time I allowed Traits/generics into a codebase
- chiffaa 7mo ago
  There are ways to handle these effects without bloating up normal applications. For example, using attributes implemented as intrinsics, which wouldn't really affect anything that isn't using them. The thing is, some of these things are very useful in specific domains, and all these domains are closely related to the ideas of safety. Nondeterminism and IO are important for purity/referential transparency, which is a fairly important effect for business logic IMO. Guaranteed termination matters for formal verification. Unwind removal matters for embedded. I don't think wishing for these things is really all that unwarranted > I actually don’t see how this is any more beneficial than the existing no_panic macro no_panic and similar macros are doing a very hacky workaround which isn't really a great static guarantee. The simple fact that building with panic = abort makes the macro useless is an annoyance in and of itself. dtolnay did great when figuring out some path forward but it's somewhat shaky
bionhoward 7mo ago
gotta admit i groaned a bit at this because it would make rust more complicated, but on my 2nd read i realized: - some things (compile time bounds checking tensor shapes) are hard / impossible to implement now; "pattern types" could be great for that - however "no panic" is already handled by clippy, might not be much uplift for doing that at a type level. my 2c: it's great to be excited and brainstorm, some of these ideas might be gold. conveying the benefit is key. it would be good to focus on stuff for which rust doesn't already have a workable solution. i like the pattern types, the rest would take convincing
shevy-java 7mo ago
Rustee devs are strange. It feels as if they are on a mission. I don't fully understand it.
semiinfinitely 7mo ago
the most exciting thing about rust is that AI agents are good at writing it because its so highly structured
Surac 7mo ago
I do not write Rust. I have left c++ cause of the feature creep of the last years that made it even harder to read c++. Reading code is so important. Make language not unfriendly for readers and value the time people put into learning a language. I have seen many c++ programmers leaving cause they feel its an other language now
chadaustin 7mo ago
I write Rust for embedded systems and both effects and linear types would be meaningful improvements. Effects especially: if you have multiple cores in a coherent memory domain AND you run with interrupts enabled, you have to deal with three types of mutex: - data accessed by multiple cores and interrupt handlers must be modified under a spin lock and with interrupts disabled - data accessed by multiple cores but not interrupt handlers only needs the spin lock - data accessed by one core but maybe interrupt handlers only needs to pay for disabling interrupts Depending on your core and how performance sensitive the code is, the costs of the above can vary significantly. It would be nice to encode these rules in the type system. (Ordered types might be useful for “critical sections” — that is, areas where interrupts are disabled and the interrupt disablement guard absolutely must be dropped in order.)
jeffreygoesto 7mo ago
Especially borrowing parts of objects reminds me of https://vale.dev https://vale.dev
dzogchen 7mo ago
The only thing Rust needs to have a chance to succeed is better C++ interoperability. Everything else is a nice to have.
ismailmaj 7mo ago
Surprised with the push back of the comments, getting effects on Rust would be a dream. Could even enable some stuff like passing loggers around not by parameters but by effect.
poppafuze 7mo ago
"Because though we’re not doing too bad, we’re no Ada/SPARK yet" ... props to the king. A worthy aspiration. Classy.
theknarf 7mo ago
I'm surprised by the backlash in the comment section here, all of these things seems like the obvious next step for Rust. It seem people are scared of big words?
- hu3 7mo ago
  > It seem people are scared of big words? Classic "skill issue" hubris by the language community.
kpcyrd 7mo ago
I just want to be able to call Default::default() from within const {}
- estebank 7mo ago
  That's on the way. Already available in nightly for select types.
School-Cotton 7mo ago
> In formal terms, Rust’s type system is considered affine, which means that each value must be used at most once. And “use at most once” is exactly what’s needed to guarantee the absence of bugs like “use after free”. > But there are type systems which can provide even more guarantees. One step beyond “use at most once” is “use exactly once”. Types that provide that guarantee are called “linear” and in addition to guaranteeing the absence of “use after free” they can also guarantee the absence of memory leaks. Does anyone know why these are called “affine” and “linear”, respectively? What’s the analogy, if any, to the use of those terms in math? (E.g. an affine transformation of vector spaces)
room271 7mo ago
Rust needs to be careful that it doesn't invite the type-programming crowd in too much. Even if individual features are helpful, the cultural effect on the programming language in terms of the community (i.e. libraries and idioms) can really fragment and destroy a language. Scala, which I programmed in for many years, is a good example -- lots of great features but ultimately overwhelmed by typesafe abstractions that held theoretical appeal but hampered readability and fragmented the community. (Lack of backwards compatibility and poor tooling also hurt Scala no doubt about it, just as slow compile times hurt Rust.)
lsuresh 7mo ago
There are some solid ideas here and would definitely apply to the IVM engine we're building. I'm curious if some of these effects could play a role in faster rust compilation times (e.g. nopanic..)?
eviks 7mo ago
Cool features, what are the chances that's going to happen in the next decade?
nmilo 7mo ago
Rust is the wrong language for effects ironically because of its strict typing. They would probably decide that all effects have to be specified on every function or that any change in capabilities is a breaking change. Which is safest, but horrible for dev ex. Whereas Go most people would just be like “yeah, Hyrum’s law, sorry I broke your weird effect consumer, I don’t really care.”
xorvoid 7mo ago
I'm pretty conflicted on this comment section. A lot of people are expressing a lot of fear of C++ bloat. I get that. I'm not sure what the right answer for Rust is, but I'm fairly convinced that these type system ideas are the future of programming languages. Perhaps it can be added to rust in a reasonable and consistent way that doesn't ultimately feel like a kludgy language post-hoc bolt on. Time will tell. There is a serious risk to getting it wrong and making the language simply more complicated for no gain. But, these ideas are really not obscure academic stuff. This is where programming language design is at. This moment is like talking about sum-types in the 2010s. These days that concept is normalized and expected in modern programming languages. But, that's a fairly recent development. I suspect that Linear types, refinement types, etc will follow a similar trajectory. Whether new ideas like this can be reasonably added to existing languages in a good way is the age old question. Hopefully Rust makes good choices on that road.
- Levitating 7mo ago
  > There is a serious risk to getting it wrong and making the language simply more complicated for no gain. I think the Rust team/community is well-aware of this. Which is why Rust has such a well-defined RFC life-cycle. At the other end, one of the biggest complaints about Rust is that many features seem eternally locked behind nightly feature gates.
  - xorvoid 7mo ago
    I feel the same confliction about this organizational policy. It has been refreshing that they haven't just jammed half-baked ideas into stable like C++ has done for decades. But, yes, it's frustrating to bump into an issue and discover that a fix has been proposed and implemented but has never been moved to stable in 5-10 years. Some things feel like they're languishing in nightly forever. I don't personally have a solution to propose to this problem. I generally appreciate their caution and long-term considering. It's refreshing coming from C++. I suppose one could argue that they've overcorrected in the other direction. Unclear. Deeper than that, I think there's a philosophical dispute on whether languages should or shouldn't even evolve. There are people with C-stability type thinking that would argue that long-term stability is so important that we should stop making changes and etch things into stone. There is some merit to that (a lot of unhelpful churn in modern programming). But, failure to modernize is eventually death IMHO. I think C is slowly dying because of exactly this. It will take quite a while because it is critical computing infrastructure. But, few people remain that defend it's viability. The arguments that remain are of the form "we simply don't have a viable replacement yet". Perhaps you can even take the view that this is the lifecycle of programming languages. They're not supposed to live forever. That could be a reasonable take. But then you really have to confront the problem of code migration from old languages to new languages. That is a very very hard unsolved problem (e.g. see: COBOL). Language evolution is foundationally a hard problem. And I'm not unhappy with Rust's approach. I think no one has managed to find an ideal approach.
baroudi 7mo ago
Introducing more colors (or effects) without a way to abstract over them will cause a lot of issues. It is already painful to work with async, one have to either accept a lot of code duplication or to perform some obscure black magic with the macro system. Also, the language is already inelegant with each monad having its own syntactic sugar (result, option and async).
jk-pasha 7mo ago
There’s one other way to look at it - in the age of vibe coding it makes sense to make the language more safe. Easier for the AI not to shoot itself in the foot. But we’re gonna need better tools for reading this new denser code packed with gotchas. That’s for sure.

274 points by todsacerdoti 8mo ago

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 8mo ago

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 7mo ago
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 7mo ago
  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 7mo ago
    Swift is not really for systems level programming like Rust and interestingly some projects like Ladybird have moved away from Swift towards Rust.
    - pjmlp 7mo ago
      It certainly is for Apple, regardless of your opinion. It is all over the place in Swift documentation, WWDC sessions, and even last week on Meet the Team session, regarding on how to write safe systems programming code on Apple platforms. Ladybird should focus on what language they actually want to deliver something.
    - wolvesechoes 7mo ago
      > Swift is not really for systems level programming Apple seems to think differently. > and interestingly some projects like Ladybird have moved away from Swift towards Rust. Not really interesting after you spent some time tracking lifecycle of FOSS projects. I don't think it is a last "moving away" announcement we get from Ladybird.
Ygg2 7mo ago
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.
- pjmlp 7mo ago
  It certainly is in what concerns ABI support, and dependency on LLVM.
  - Ygg2 7mo ago
    Scala had an unnatural dependency on Java, not JVM. I.e., imitating not just some patterns but copying its flawed interfaces. For example, Scala could express and bypass decades of cruft in the Java Collections API. Did it choose to do it? To paraphrase former Scala developer and present poker player, "If Java cut its nose, would you Scala... Oh god, stop! The blood, the blood!" Everyone who wants to talk to low-level code has to have C ABI. The equivalent Scalaism in Rust would be if Rust reimplemented the C-inspired java.util.Date. Yes. Monday should be 0, not an enum. Because C did it.
Conscat 7mo ago
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 7mo ago
> 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)
- zozbot234 7mo ago
  > I wonder if another language could be "the Kotlin of Rust"? Some people would say that Swift is that language since it's potentially memory safe like Rust and is described as friendlier to novices. There's some room for disagreement wrt. the latter point.
  - palata 7mo ago
    Well many languages are memory safe. Java has been memory safe forever. Rust is the one that is memory-safe with zero-cost abstractions, right?
    - bombela 7mo ago
      Rust is also data race safe to boot.
- hocuspocus 7mo ago
  > But somehow Kotlin managed to stay "not too complex", unlike Scala. It's not really true anymore, Kotlin has slowly absorbed most of the same features and ideas even though they're sometimes pretty half-baked, and it's even less principled than the current Scala ecosystem. JetBrains also wants to make Kotlin target every platform under the sun. At this point, the only notable difference are HKTs and Scala's metaprogramming abilities. Kotlin stuck to a compiler plugin exposing a standard interface (kotlinx.serialization) for compile-time codegen. Scala can do things like deriving an HTTP client from an OpenAPI specification on the fly, by the LSP backend.

ozgrakkurt 7mo ago

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 7mo ago
I agree that the complexity is getting scary. They keep on adding more and more stuff and it is hard to follow.
- tcfhgj 7mo ago
  Could you expand a bit more?
xiphias2 7mo ago
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 7mo ago
  The edition mechanism covers your last paragraph.

arrty88 7mo ago

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

jadenPete 7mo ago

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 7mo ago
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 7mo ago
  Ah yes Haskell, the reasonable centrist position in language design.
  - satvikpendem 7mo ago
    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 https://news.ycombinator.com/item?id=47259148
    - MrBuddyCasino 7mo ago
      You got a point there.

Animats 7mo ago

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.

pjmlp 7mo ago
Boost is as actual as ever. Also the way nowadays is with constexpr, templates, and around the corner, static reflection.
wofo 7mo ago
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 7mo ago
  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 7mo ago
    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?

zamalek 7mo ago

I'm terrified by the notion of try fns. Are we getting exceptions (and therefore losing one of rust's greatest features)?

Pedro_Ribeiro 7mo ago
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)?
- zamalek 7mo ago
  From the article: > And on nightly it also has support for try fn and gen fn. I haven't been able to figure out what a try fn is.

pkal 7mo ago

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

deleted 7mo ago
[deleted]
jltsiren 7mo ago
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 extent 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 7mo ago
  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
egorelik 7mo ago
I don't remember where I read it, but I think Rust cited Cyclone as an influence, a variation of C with "region-based" memory management - more or less the literature name for "lifetimes". I think Rust may be the first to use it directly for stack variables, however.

phplovesong 7mo ago

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 7mo ago
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 7mo ago
  How does it compare to Kotlin async? I find Kotlin generally hits a good balance across the board.
- usrnm 7mo ago
  Try golang, where they did the only sane thing: everything is async from the very beginning, no function colouring
  - simonask 7mo ago
    I think practical experience with Go reveals that this choice being “the only sane thing” is highly debatable. It comes with huge drawbacks.
    - usrnm 7mo ago
      Of course it has drawbacks, everything does, but my practical experience has been hugely in favor of what golang is doing, at least, in terms of cognitive load and code simplicity. It is very much worth it in many, many cases

wewewedxfgdf 7mo ago

No-one ever has the "Grand Vision" to cut something down to it's essential 25% and delete the rest.

techbrovanguard 7mo ago
By all means, write some Go instead—you might want to order a new `if err != nil` button to stave off the RSI. The rest of us are trying to make things better.
ebiederm 7mo ago
Chuck Moore of Forth fame.
lioeters 7mo ago
Unless there's a conscious and constant effort to keep things simple, a programming language or software project will grow to consume all available resources, developers' time, intellectual capacity, and funding.
chiffaa 7mo ago
You can't cut down a language without breaking changes. And there fairly often are internal changes to simplify the compiler and the tooling. Just in the latest release, annotation internals were finally fully unified between rustc, cargo, clippy and other tools. This was a fairly considerable effort in deduplicating code. Borrow checker is being rewritten to move to tree borrows, trait resolution is being refactored for a variety of reasons. Code is being simplified where possible, but this doesn't mean Rust doesn't have areas to improve in, especially if there is a goal of replacing Ada/SPARK
nsm 7mo ago
https://without.boats/blog/revisiting-a-smaller-rust/ https://without.boats/blog/revisiting-a-smaller-rust/ I think there is a programming language hole for a Rust-like language, but with GC and green threads. One that dispenses with single-ownership, and async/await footguns. Something like F#/Kotlin is closest in terms of developer experience. Unfortunately, we are really lacking a language that skews badly on some other axis - F# - tainted by being Windows only for really long and being Microsoft. - Kotlin - tainted by the JVM - Java 24+ - has virtual threads, sum types, match expressions and other niceties, but tainted by the JVM again (Verbosity included, but this is not really a factor with IDEs and LLMs.) Note that the opinions above are not mine, but "consensus". I'd say they are all unfair opinions. I feel like people end up favoring new languages, simply because of novelty. Like, inevitably, somebody is gonna say Gleam. I'm all for having existing BEAM users getting access to new languages, but I'm not sure why one would pick a BEAM language for non-server applications when the developer tooling story for CLI apps, line-of-business apps and so on is so much stronger for the .NET and JVM ecosystems. No offense to the Gleam folks intended.

irenetusuq 7mo ago

[dead]

plantain 7mo ago

I used to hate Golang for not having generics and how verbose getting basic things done was. Then I read posts like this and realise, my god, Rob Pike was so, so right. Do these people ever ship anything? Or is it just endless rearranging of deckchairs?

beanjuiceII 7mo ago
I already need a reference to read rust code, looks like I'll need a third reference sheet. The language is currently bordering on spaghetti
- ozgrakkurt 7mo ago
  The most annoying part is that you can't just go to source code or docs and understand some code. I still can't do it after spending many years using it. You have to wade through 7 layers of macros and traits to understand some basic thing most of the time. It is easier to understand musl-libc code compared to understanding a http library in rust which is just insane to me.
pjmlp 7mo ago
I mostly agree, however it wouldn't harm Go, even to get back some of the niceties of Limbo that it still misses.

conorbergin 7mo ago

Thank God for Zig

esafak 7mo ago
Elaborate.
- conorbergin 7mo ago
  I don’t think PL theory driven design produces good systems languages.
  - zozbot234 7mo ago
    Rust as it exists today is very much "PL theory" driven. It's not necessarily a good language, but it's been consistently ranked as the #1 "most loved" by Stack Overflow for the past few years.
pjmlp 7mo ago
For bringing us back to Modula-2?

QuantumNoodle 7mo ago

I write production Rust code that becomes critical infra for our customers. I got tired of nil checks in Go and became a squeaky wheel in incident retros, where I finally got the chance to rewrite parts of our system in Rust during a refactor. I admit the skill issue on my part, but I genuinely struggled to follow the concepts in this article. Working alongside peers who push Rust's bleeding edge, I dread reviewing their code and especially inheriting "legacy" implementations. It's like having a conversation with someone who expresses simple thoughts with ornate vocabulary. Reasoning about code written this way makes me experience profound fatigue and possess an overwhelming desire to return to my domicile; Or simply put, I get tired and want to go home. Rust's safety guardrails are valuable until the language becomes so complex that reading and reasoning about _business_ logic gets harder, not easier. It reminds me of the kid in "A Christmas Story" bundled so heavily in winter gear he cant put his arms down[0]. At some point, over-engineered safety becomes its own kind of risk even though it is technically safer in some regards. Sometimes you need to just implement a dang state machine and stop throwing complexity at poorly thought-through solutions. End old-man rant. [0]: https://youtu.be/PKxsOlzuH0k?si=-88dxtyegTxIvOYI https://youtu.be/PKxsOlzuH0k?si=-88dxtyegTxIvOYI

QuaternionsBhop 7mo ago
> Reasoning about code written this way makes me experience profound fatigue and possess an overwhelming desire to return to my domicile; I didn't understand that you were making fun of verbosity until the word 'domicile'. I must be one of those insufferable people who expresses simple thoughts with ornate vocabulary... The article was comprehensible to me, and the additional function colorings sound like exciting constraints I can impose to prevent my future self from making mistakes rather than heavy winter gear. I guess I'm closer to the target audience?
baby 7mo ago
I really think that golang makes it easy to read code, rust makes it easy to write code. If Golang had sum types it would be a much nicer language to write complex applications with
- 7mo ago

jbritton 7mo ago

When I wrote my very first Rust code, I was trying to write to a socket. I got stuck on this task with misleading error messages for the longest time. I finally realized I had not made the socket object mutable. I’m used to Posix where you have an integer file descriptor and I don’t tend to think of socket write as a mutable operation. At least it doesn’t mutate state that my app manages. Perhaps something in the kernel gets mutated. I believe the socket interface may have been intended to support queuing which is perhaps why it needed to be mutable. I might have needed a lower level api. I just mention this because I think it’s interesting as to how it should be typed when mutation is external to the app. I didn’t follow through on using Rust and this was long ago so I’m sure some details are wrong.

holden_nelson 7mo ago
I also found it really unintuitive what needs to be made mutable. And still do to some degree. When I first had learned that rust had this concept of “opt-in” mutability, I thought that it must then be an accepted pattern that we make as little as possible be mutable in an attempt to help us better reason about the state of our program. I had come to rust after learning some clojure so I was like “ahh! Immutable by default! So everything’s a value!” But in reality it feels like rust code is not “designed” around immutability but instead around appeasing the borrow checker - which is actually pretty easy to reason about once you get the hang of the language. But it’s a ton to learn up front
estebank 7mo ago
> got stuck on this task with misleading error messages for the longest time. Could you elaborate on that? We consider misleading error messages to be bugs and would like to know more on case we could fix them.
- jbritton 7mo ago
  It appears the error message has been improved.
undeveloper 7mo ago
I think part of it might be just that for modeling's sake it makes it clear when something can write vs only read the socket

esafak 7mo ago

These would be great additions. I don't get why people don't want powerful type systems. Let the language work for you!

hardwaresofton 7mo ago

Really excited for the possibilities here. People undoubtedly thought going for Affine types was too much, and even simple things like null safety or enums-with-values and the prevalence of Result saw debate with minimalists voicing concerns. A world where you could write a Rust program that is memory leak free with Affine types is one I want to live in. Haskell can do it now, but its just not easy and Rust has beat out Haskell with its mix of ML-strength types and practicality. IMO these changes maintain Rusts winning mix of academia and practicality. Heres a proof point — dependent types weren't mentioned :)

hardwaresofton 7mo ago
*linear types (the leak free future bit) This description is also a good crystallization of why one would want linear types

pornel 7mo ago

It's hard to see features through the programming language theory jargon, but solid theoretical foundations have worked well for Rust so far. Jargon terms like "sum types" or "affine types" may seem complicated, but when you see it's actually "enums with data fields", it makes so much sense, and prevents plenty of state-related bugs. Proposed "effects" mean that when you're writing an iterator or a stream, and need to handle error or await somewhere in the chain, you won't suddenly have a puzzle how to replace all of the functions in the entire chain and your call stack with their async or fallible equivalents. "linear types" means that Rust will be able to have more control over destruction and lifetime of objects beyond sync call stack, so the tokio::spawn() (the "Rust async sucks" function) won't have to be complaining endlessly about lifetimes whenever you use a local variable. I can't vouch for the specifics of the proposed features (they have tricky to design details), but it's not simply Rust getting more complex, but rather Rust trying to solve and simplify more problems, with robust and generalizable language features, rather than ad-hoc special cases. When it works it makes the language more uniform overall and gives a lot of bang for the buck in terms of complexity vs problems solved.

ozgrakkurt 7mo ago
What worked for rust is having enums, sane-ish error handling, having sane integer types and the borrow checker, good tooling. The rest is just not that useful compared to how much garbage it creates
- ChadNauseam 7mo ago
  You didn't mention parametric polymorphism, which is incredibly useful and important to the language. I'm guessing you intentionally excluded async, but to describe it as "not that useful" would just be wrong, there is a large class of programs that can be expressed very simply using async rust but would be very complicated to express in sync rust (assuming equivalent performance).
  - ozgrakkurt 7mo ago
    Yes rust async isn’t good imo. You can do basically the same thing with stackfull coroutines. Also the ecosystem is setup so you have to use tokio and everything has to be an Arc.

undeveloper 7mo ago

I'm not sure why people are so deeply scared. these are all pretty neat features for people who will need them (off rip seemingly mostly in the embedded world). It's not like the inclusion of these forces you to use them — I've never had to deal with unsafe rust for shipping web stuff, and I highly doubt I'd have to deal with most of these. For modeling's sake it would be nice to have pattern types and view types, I can see them being useful

simplesocieties 7mo ago
This was the exact same argument used to push new c++ features and look where the language is now.
- devnullbrain 7mo ago
  ...a far better place than 2011.
- gpderetta 7mo ago
  you mean better than ever?
ozgrakkurt 7mo ago
People will push this crap into production codebases and link to these articles when you say you don’t want complexity. Best way to manage is to not make it possible, like go. You indirectly deal with this kind of thing when compiling web server code too. It compiles super slow and can have weird errors. This is because the people who build the web stack in rust used a million traits/generics/macros etc. Even if you look at something like an io_uring library in rust, it uses a bunch of macros instead of just repeating 3 lines of code.
- anon291 7mo ago
  3 lines of code that may need to change is much more complex than a macro that signals intent.

simplesocieties 7mo ago

The rust maintainers need to learn from the mistakes of the c++ design committee and understand that not adding a feature at all is in itself a desirable feature. For example, your section on effects: > Functions which guarantee they do not unwind (absence of the panic effect) * I actually don’t see how this is any more beneficial than the existing no_panic macro https://docs.rs/no-panic/latest/no_panic/ https://docs.rs/no-panic/latest/no_panic/ > Functions which guarantee they terminate (absence of the div effect) > Functions which are guaranteed to be deterministic (absence of the ndet effect) > Functions which are guaranteed to not call host APIs (absence of the io effect) The vast majority of rust programs don’t need such validation. And for those that do, the Ferrocene project is maintaining a downstream fork of the compiler where this kind of feature would be more appropriate. I think rust is in a perfect spot right now. Covers 99.99% of use cases and adding more syntax/functionality for 0.001% of users is only going to make the language worse. The compiler itself provides a powerful api via build.rs and proc macros which let downstream maintainers build their desired customization.

ozgrakkurt 7mo ago
You just know some guy will try to make cli code no-panic/deterministic use a bunch of crap and think he achieved something. Just not allowing complex code is so much better than this. Just even being able to look at a piece of code and trace what it is doing is 1000x more valuable than this. I regretted almost every time I allowed Traits/generics into a codebase
chiffaa 7mo ago
There are ways to handle these effects without bloating up normal applications. For example, using attributes implemented as intrinsics, which wouldn't really affect anything that isn't using them. The thing is, some of these things are very useful in specific domains, and all these domains are closely related to the ideas of safety. Nondeterminism and IO are important for purity/referential transparency, which is a fairly important effect for business logic IMO. Guaranteed termination matters for formal verification. Unwind removal matters for embedded. I don't think wishing for these things is really all that unwarranted > I actually don’t see how this is any more beneficial than the existing no_panic macro no_panic and similar macros are doing a very hacky workaround which isn't really a great static guarantee. The simple fact that building with panic = abort makes the macro useless is an annoyance in and of itself. dtolnay did great when figuring out some path forward but it's somewhat shaky

bionhoward 7mo ago

gotta admit i groaned a bit at this because it would make rust more complicated, but on my 2nd read i realized: - some things (compile time bounds checking tensor shapes) are hard / impossible to implement now; "pattern types" could be great for that - however "no panic" is already handled by clippy, might not be much uplift for doing that at a type level. my 2c: it's great to be excited and brainstorm, some of these ideas might be gold. conveying the benefit is key. it would be good to focus on stuff for which rust doesn't already have a workable solution. i like the pattern types, the rest would take convincing

shevy-java 7mo ago

Rustee devs are strange. It feels as if they are on a mission. I don't fully understand it.

semiinfinitely 7mo ago

the most exciting thing about rust is that AI agents are good at writing it because its so highly structured

Surac 7mo ago

I do not write Rust. I have left c++ cause of the feature creep of the last years that made it even harder to read c++. Reading code is so important. Make language not unfriendly for readers and value the time people put into learning a language. I have seen many c++ programmers leaving cause they feel its an other language now

chadaustin 7mo ago

I write Rust for embedded systems and both effects and linear types would be meaningful improvements. Effects especially: if you have multiple cores in a coherent memory domain AND you run with interrupts enabled, you have to deal with three types of mutex: - data accessed by multiple cores and interrupt handlers must be modified under a spin lock and with interrupts disabled - data accessed by multiple cores but not interrupt handlers only needs the spin lock - data accessed by one core but maybe interrupt handlers only needs to pay for disabling interrupts Depending on your core and how performance sensitive the code is, the costs of the above can vary significantly. It would be nice to encode these rules in the type system. (Ordered types might be useful for “critical sections” — that is, areas where interrupts are disabled and the interrupt disablement guard absolutely must be dropped in order.)

jeffreygoesto 7mo ago

Especially borrowing parts of objects reminds me of https://vale.dev https://vale.dev

dzogchen 7mo ago

The only thing Rust needs to have a chance to succeed is better C++ interoperability. Everything else is a nice to have.

ismailmaj 7mo ago

Surprised with the push back of the comments, getting effects on Rust would be a dream. Could even enable some stuff like passing loggers around not by parameters but by effect.

poppafuze 7mo ago

"Because though we’re not doing too bad, we’re no Ada/SPARK yet" ... props to the king. A worthy aspiration. Classy.

theknarf 7mo ago

I'm surprised by the backlash in the comment section here, all of these things seems like the obvious next step for Rust. It seem people are scared of big words?

hu3 7mo ago
> It seem people are scared of big words? Classic "skill issue" hubris by the language community.

kpcyrd 7mo ago

I just want to be able to call Default::default() from within const {}

estebank 7mo ago
That's on the way. Already available in nightly for select types.

School-Cotton 7mo ago

> In formal terms, Rust’s type system is considered affine, which means that each value must be used at most once. And “use at most once” is exactly what’s needed to guarantee the absence of bugs like “use after free”. > But there are type systems which can provide even more guarantees. One step beyond “use at most once” is “use exactly once”. Types that provide that guarantee are called “linear” and in addition to guaranteeing the absence of “use after free” they can also guarantee the absence of memory leaks. Does anyone know why these are called “affine” and “linear”, respectively? What’s the analogy, if any, to the use of those terms in math? (E.g. an affine transformation of vector spaces)

room271 7mo ago

Rust needs to be careful that it doesn't invite the type-programming crowd in too much. Even if individual features are helpful, the cultural effect on the programming language in terms of the community (i.e. libraries and idioms) can really fragment and destroy a language. Scala, which I programmed in for many years, is a good example -- lots of great features but ultimately overwhelmed by typesafe abstractions that held theoretical appeal but hampered readability and fragmented the community. (Lack of backwards compatibility and poor tooling also hurt Scala no doubt about it, just as slow compile times hurt Rust.)

lsuresh 7mo ago

There are some solid ideas here and would definitely apply to the IVM engine we're building. I'm curious if some of these effects could play a role in faster rust compilation times (e.g. nopanic..)?

eviks 7mo ago

Cool features, what are the chances that's going to happen in the next decade?

nmilo 7mo ago

Rust is the wrong language for effects ironically because of its strict typing. They would probably decide that all effects have to be specified on every function or that any change in capabilities is a breaking change. Which is safest, but horrible for dev ex. Whereas Go most people would just be like “yeah, Hyrum’s law, sorry I broke your weird effect consumer, I don’t really care.”

xorvoid 7mo ago

I'm pretty conflicted on this comment section. A lot of people are expressing a lot of fear of C++ bloat. I get that. I'm not sure what the right answer for Rust is, but I'm fairly convinced that these type system ideas are the future of programming languages. Perhaps it can be added to rust in a reasonable and consistent way that doesn't ultimately feel like a kludgy language post-hoc bolt on. Time will tell. There is a serious risk to getting it wrong and making the language simply more complicated for no gain. But, these ideas are really not obscure academic stuff. This is where programming language design is at. This moment is like talking about sum-types in the 2010s. These days that concept is normalized and expected in modern programming languages. But, that's a fairly recent development. I suspect that Linear types, refinement types, etc will follow a similar trajectory. Whether new ideas like this can be reasonably added to existing languages in a good way is the age old question. Hopefully Rust makes good choices on that road.

Levitating 7mo ago
> There is a serious risk to getting it wrong and making the language simply more complicated for no gain. I think the Rust team/community is well-aware of this. Which is why Rust has such a well-defined RFC life-cycle. At the other end, one of the biggest complaints about Rust is that many features seem eternally locked behind nightly feature gates.
- xorvoid 7mo ago
  I feel the same confliction about this organizational policy. It has been refreshing that they haven't just jammed half-baked ideas into stable like C++ has done for decades. But, yes, it's frustrating to bump into an issue and discover that a fix has been proposed and implemented but has never been moved to stable in 5-10 years. Some things feel like they're languishing in nightly forever. I don't personally have a solution to propose to this problem. I generally appreciate their caution and long-term considering. It's refreshing coming from C++. I suppose one could argue that they've overcorrected in the other direction. Unclear. Deeper than that, I think there's a philosophical dispute on whether languages should or shouldn't even evolve. There are people with C-stability type thinking that would argue that long-term stability is so important that we should stop making changes and etch things into stone. There is some merit to that (a lot of unhelpful churn in modern programming). But, failure to modernize is eventually death IMHO. I think C is slowly dying because of exactly this. It will take quite a while because it is critical computing infrastructure. But, few people remain that defend it's viability. The arguments that remain are of the form "we simply don't have a viable replacement yet". Perhaps you can even take the view that this is the lifecycle of programming languages. They're not supposed to live forever. That could be a reasonable take. But then you really have to confront the problem of code migration from old languages to new languages. That is a very very hard unsolved problem (e.g. see: COBOL). Language evolution is foundationally a hard problem. And I'm not unhappy with Rust's approach. I think no one has managed to find an ideal approach.

baroudi 7mo ago

Introducing more colors (or effects) without a way to abstract over them will cause a lot of issues. It is already painful to work with async, one have to either accept a lot of code duplication or to perform some obscure black magic with the macro system. Also, the language is already inelegant with each monad having its own syntactic sugar (result, option and async).

jk-pasha 7mo ago

There’s one other way to look at it - in the age of vibe coding it makes sense to make the language more safe. Easier for the AI not to shoot itself in the foot. But we’re gonna need better tools for reading this new denser code packed with gotchas. That’s for sure.