2026 is an exciting year for the Rust compiler (and me)

> I don't think rust is the future

Yeah because it's the present. Rust is everywhere now.

Well, that implies there's some sort of threshold that it's still reaching for and hasn't yet achieved before it can be considered successful. But it's already everywhere now. Hell, not only is it in the Linux kernel, it's even in Windows (!).

What a weird take. At first I though you were going to predict a language with an even more featureful and strict type system.

We don't need the "boreness" and human usability of Go anymore. Fast compile times are still nice though.

Lisp syntax doesn't have much value in the age of AI I think. Lisp seems optimized to make it easy to parse, and also easy to hack on the interpreter. I don't think Lisp was ever meant to optimize human readability. The uniformity and minimalism of Lisp makes it easier to learn the syntax though. -- I don't know, maybe I underestimate the value and flexibility of Lisp syntax.

I think the most valuable features of programming languages now are human readability and type systems that give guarantees humans can rely on. Some of the most exciting code AI has written has been in Lean.

https://xkcd.com/927/

A lisp with the type safety of rust. Mmmmmm. Makes me do the homer drool

Really? With AI you can have your cake and eat it too with Rust now.

There's some movement on specialization as well: https://goals.rust-lang.org/2026/specialization.html

It's not directly blocked on the solver, but getting the type system into a better shape definitely helps reasoning about the soundness issues involved.

This!

There's a recurring meme here and in other social media about rust being slow to compile, but anyone who's worked with Rust know that target dirs are a much more annoying papercut in practice than the relative speed of the compiler (which isn't appreciably worse than any other toolchain out there for the most common workflows).

It would help, yes. Here's one of my projects, that uses different subdirectories in target/ based on compiler options pre-commit runs:

    $ du -hcs target/
    190G    target/

Could you e plain the issue for a non-rustacean?

The "hint" you could provide today for polymorphization is to write code like

    fn needs_string_like(x: Into<String>) {
        fn actual_logic(_: String) {}
        actual_logic(x.into())
    }

which is the explicit way of representing the same thing rustc would be doing automatically. The above will create an almost empty `needs_string_like` for each type that it is called with, but a single `actual_logic`. IIRC some optimization passess would completely remove specific instances of `needs_string_like` (like if you call `needs_string_like(String::new())`).

> polymorphism

I assume you ask about polymorphization, which is a term used to refer to a specific optimization mentioned in the blog post.

The base version which Rust wants the most makes sense to enable by default for all builds, because it's purely just removing duplicate work - this is for cases like Vec<u64> and Vec<i64>, where we currently emit code for each one separately, even though it's pretty much the same for both.

More general version will make sense for debug builds or in some special cases, like when optimizing for size. I believe people also want to experiment with it for some interop use cases (and for that, it'd be useful to have source level annotation). I think it's too early to tell how all of this is going to look like, though.

Hacker News has some automatic fixes for title text. Some - perhaps all - of them can walk into false positives where a change that's usually desirable instead ruins the title either because it's a joke and the change spoils the joke or just because English is complicated.

Return Type Notation (RTN) I believe is the big one blocked by the new solver. This is the primitive that makes it possible to add bounds to futures returned by async functions. This should look something like: `where <T as Trait>::method(..): Send`.

This is one of two remaining features needed to make Async Functions in Traits (AFITs) practical. Dyn dispatch support being the other missing feature, though that isn't blocked by the new solver.

Leadership matters. I don't suppose the Rust leaders have been telling their community to write more open-source code for free with the express purpose of replacing those people with LLMs trained on their work.

A bit out of the loop, what's going on with clippy?

(r-a team member here) The progress is in Salsa (the incremental framework we use), not in r-a itself yet. And there is progress but it's not particularly fast, it's also not a priority for the r-a team (though if you want to contribute, you're welcome of course).

The implication being that you're writing in a language so unsafe that you need to pay for AI data centers to periodically double-check it for you. That isn't the argument in favor of C that you think it is.

I hope this is satire.

I've never seen a proof that LLMs can fix memory safety in C or C++ like Rust does. I'll believe it when I'll see it.

And I prefer to work with Rust than both anyway. Such advancement (if it will happen) will only make other languages like Zig feasible for me.

or to save tokens you can have an LLM write a borrow checker to do this for you. Oh wait you're just rebuilding rust...

I did this once but with Elixir, and it worked - because I shipped ahead of schedule (way ahead of the other teams portions). Performance and quality met the standards. Sometimes it's better to ask for forgiveness than permission if that means not having to fool with Java.