satvikpendem 2026-03-05 06:45 UTC link

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 2026-03-05 08:34 UTC link

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.

Animats 2026-03-08 07:01 UTC link

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.

pkal 2026-03-08 09:59 UTC link

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

wewewedxfgdf 2026-03-08 21:02 UTC link

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

its-kostya 2026-03-08 23:34 UTC link

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

jbritton 2026-03-09 00:00 UTC link

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.

esafak 2026-03-09 00:22 UTC link

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

hardwaresofton 2026-03-09 00:36 UTC link

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

pornel 2026-03-09 02:40 UTC link

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.

undeveloper 2026-03-09 03:55 UTC link

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 2026-03-09 04:17 UTC link

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/

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

bionhoward 2026-03-09 05:33 UTC link

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

chadaustin 2026-03-09 07:42 UTC link

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

ismailmaj 2026-03-09 10:16 UTC link

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.

theknarf 2026-03-09 13:17 UTC link

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?

umanwizard 2026-03-09 14:21 UTC link

> 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 2026-03-09 14:28 UTC link

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

nmilo 2026-03-09 16:12 UTC link

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 2026-03-09 16:45 UTC link

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.

satvikpendem 2026-03-08 05:30 UTC link

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

wofo 2026-03-08 07:34 UTC link

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.

throwaway27448 2026-03-08 08:58 UTC link

> 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?

Ygg2 2026-03-08 19:57 UTC link

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

Ygg2 2026-03-08 20:00 UTC link

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.

usrusr 2026-03-08 20:30 UTC link

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.

jltsiren 2026-03-08 21:09 UTC link

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.

Conscat 2026-03-08 21:53 UTC link

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 2026-03-08 22:43 UTC link

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

riffraff 2026-03-08 23:29 UTC link

> This may be too much advanced type theory for a useful language.

I think a lot of things taken for granted these days were considered "too complicated" some time ago: think of how widespread pattern matching, closures, generics, or functional idioms in imperative languages are, and compare to e.g. Java 1.0.

My feeling is that the "acceptable level of complexity" for programming languages goes up over time, so probably stuff like effect types will be almost everywhere in another 10 years.

egorelik 2026-03-09 00:31 UTC link

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.

holden_nelson 2026-03-09 01:26 UTC link

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 2026-03-09 02:04 UTC link

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

nemothekid 2026-03-09 02:48 UTC link

I've been on both sides of the fence here - I've bounced between two camps:

1. Go with a better type system. A compiled language, that has sum types, no-nil, and generics.

2. A widely used, production, systems language that implements PL-theory up until the year ~2000. (Effects, as described in this article, was a research topic in 1999).

I started with (1), but as I started to get more and more exposed to (2), you start looking back on times when you fought with the type system and how some of these PL-nerds have a point. I think my first foray into Higher-Kinded Types was trying to rewrite a dynamic python dispatch system into Rust while keeping types at compile time.

The problem is, many of these PL-nerd concepts are rare and kind of hard to grok at first, and I can easily see them scaring people off from the language. However I think once you understand how they work, and the PL-nerds dumb down the language, I think most people will come around to them. Concepts like "sum types" and "monads", are IMO easy to understand concepts with dumb names, and even more complex standard definitions.

techbrovanguard 2026-03-09 02:49 UTC link

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.

undeveloper 2026-03-09 03:46 UTC link

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

ebiederm 2026-03-09 04:17 UTC link

Chuck Moore of Forth fame.

simplesocieties 2026-03-09 04:18 UTC link

This was the exact same argument used to push new c++ features and look where the language is now.

DevelopingElk 2026-03-09 05:05 UTC link

Rust's discussion boards has an idea of "keyword generics" for expressing some of these concepts. The idea is that a function can be generic over const, async or some other keyworded effect. I like this description. It shows the benefits without too much theory.

sam0x17 2026-03-09 05:25 UTC link

I feel you, but hear me out. OP is right. I've wanted pretty much everything he's talking about here for years, I just never thought of all of this in as quite a formal way as he has. We need the ability to say "this piece of code can't panic". It's super important in the domains I work in. We also need the ability to say "this piece of code can't be non-deterministic". It's also super important in the domains I work in. Having language level support for something like this where I add an extra word to my function def and the compiler guarantees the above would be groundbreaking

ozgrakkurt 2026-03-09 06:17 UTC link

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

ozgrakkurt 2026-03-09 06:24 UTC link

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

ozgrakkurt 2026-03-09 06:30 UTC link

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.

lioeters 2026-03-09 07:01 UTC link

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 2026-03-09 07:21 UTC link

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

chiffaa 2026-03-09 07:33 UTC link

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

hardwaresofton 2026-03-09 08:39 UTC link

*linear types (the leak free future bit)

This description is also a good crystallization of why one would want linear types

aw1621107 2026-03-09 08:49 UTC link

> I actually don’t see how this is any more beneficial than the existing no_panic macro

I think looking at the caveats listed in the no_panic docs should give you some ideas as to how a "proper" no_panic effect could improve on the macro.

Furthermore, a "proper" effect system should make working with effects nicer in general - for instance, right now writing functions that work independently of effects is not particularly ergonomic.

> The vast majority of rust programs don’t need such validation.

I think you also need to consider the niches which Rust wants to target. Rust is intended to be usable for very low-level/foundational/etc. niches where being able to track such effects is handy, if not outright required, so adding such support would be unblocking Rust for use in places the devs want it to be usable in.

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

Given this bit from the Ferrocene website:

> Ferrocene is downstream from Rust

> It works with existing Rust infrastructure and the only changes made in the code were to cover testing requirements of ISO 26262, IEC 61508 and IEC 62304 qualification. All fixes are reported upstream for constant improvement.

I would suspect that such changes would be out of scope for the Ferrocene fork because that fork is more intended to be a qualified/certified Rust more than Rust + completely novel extensions.

> The compiler itself provides a powerful api via build.rs and proc macros which let downstream maintainers build their desired customization.

Given the complexity of the features listed this feels tantamount to asking each individual consumer to make their own fork which doesn't seem very likely to attract much interest. IIRC async even started off like that (i.e., using a macro), but that was painful enough and async thought to be useful enough to be promoted to a language feature.

I'm curious to what extent one can implement the described features using just build.rs/proc macros in the first place without effectively writing a new compiler.

scottlamb 2026-03-09 11:53 UTC link

`std::net::TcpStream`? Interestingly, it doesn't need to be mutable if you know the trick.

* It implements `Write` for `TcpStream` which is likely what you were using. And `Write` requires `&mut`, probably because the same trait is used for writing to application buffers (e.g. through `BufWriter` or just to a `Vec`). So this doesn't compile: [2] I think the error message is pretty good; maybe it's improved since you tried. It doesn't though suggest the trick below.

* It also implements `Write` for `&TcpStream`. So if you use the awkward phrasing `(&stream).write_all(b"asdf")`, you don't need mutable access. [3] This allows you to use it with anything that takes the trait, without requiring mutability. You might need this if say you're reading from the socket from one thread while simultaneously writing to it from another thread.

It's a vaguely similar situation with the most common async equivalent, `tokio::net::TcpStream`. The most straightforward way to write to it is with a trait that needs mutable access, but it is possible to write to a shared reference by not using a trait. They also have these `split` and `into_split` methods to get mutable access to something that implements the read traits and something that implements the write traits.

[1] https://doc.rust-lang.org/std/net/struct.TcpStream.html

[2] https://play.rust-lang.org/?version=stable&mode=debug&editio...

[2] https://play.rust-lang.org/?version=stable&mode=debug&editio...

devnullbrain 2026-03-09 12:22 UTC link

A state machine is a perfect example of a case where you would benefit from linear types.

Some things just need precise terminology so humans can communicate about them to humans without ambiguity. It doesn't mean they're inherently complex: the article provides simple definitions. It's the same for most engineering, science and language. One of the most valuable skills I've learned in my career is to differentiate between expressions, statements, items, etc. - how often have you heard that the hardest problem in software development is coordinating with other developers? If you learn proper terminology, you can say exactly what you mean. Simple language doesn't mean more clear.

I wasn't born knowing Rust, I had to learn it. So I'm always surprised by complaints about Rust being too complex directed at the many unremarkable people who have undergone this process without issues. What does it say, really? That you're not as good as them at learning things? In what other context do software people on the internet so freely share self-doubt?

I also wonder about their career plans for the future. LLMs are already capable of understanding these concepts. The tide is rising.

Editorial Channel

What the content says

Structural Channel

What the site does