2026 has really been the year of Rust. The fact that it can run in the browser as well as natively has made it an electron killer.

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

&gt; I don&#x27;t think rust is the futureYeah because it&#x27;s the present. Rust is everywhere now.

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&#x27;t need the &quot;boreness&quot; and human usability of Go anymore. Fast compile times are still nice though.Lisp syntax doesn&#x27;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&#x27;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&#x27;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.

<a href="https:&#x2F;&#x2F;xkcd.com&#x2F;927&#x2F;" rel="nofollow">https:&#x2F;&#x2F;xkcd.com&#x2F;927&#x2F;</a>

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.

I don&#x27;t think rust is the future anymore, despite having contributed to its compiler few times and been quite involved for years. It has spread too much and that impact compiles time too much.I think a newer language, having the boreness of go, the compile speed and maybe comp time of zig and safety of rust will emerge, maybe with lisp syntax.

More precisely: it wasn&#x27;t known to be blocked on the new solver (unlike some other features), because nobody dared to touch it until recently... (more seriously, there wasn&#x27;t enough investment).

There&#x27;s some movement on specialization as well: <a href="https:&#x2F;&#x2F;goals.rust-lang.org&#x2F;2026&#x2F;specialization.html" rel="nofollow">https:&#x2F;&#x2F;goals.rust-lang.org&#x2F;2026&#x2F;specialization.html</a>It&#x27;s not directly blocked on the solver, but getting the type system into a better shape definitely helps reasoning about the soundness issues involved.

&gt; It&#x27;s easy to understate how big of a deal this is for the compiler. This work resolves a major piece of technical debt that a lot of compiler developers dreamed about for years.No kidding. I’ve been waiting for the solver at least half that decade now. Hopefully it and Polonius unblock specialization which has been in purgatory for years.

A papercut is an unbelievable way to describe this. I tried forking Codex CLI and, for a terminal UI that manages chats and HTTP requests, it takes over 15 minutes to rebuild trivial changes on a top-shelf CPU with all incremental&#x2F;caching optimizations, and tens of GBs in build caches. Neither of those is acceptable. Full stop. I am aware part of the problem is that Codex CLI is a vibe-coded monstrosity (surprise, software is not solved), but I&#x27;ve not had this problem with vibe-coded monstrosities in eg. Go. Hold your language to better standards. That doesn&#x27;t mean abandon Rust; that means strive to make the Rust toolchain better than the Go toolchain rather than shrugging your shoulders and saying &quot;lol this is fine no way anybody could do anything about this&quot;.

Both (and memory) are a problem. Build sizes is definitely more easily solved just by throwing more disk at it though (unless you are using a hard constrained mac...).

~Zero build time Python vs 20 min for Rust web app

This!There&#x27;s a recurring meme here and in other social media about rust being slow to compile, but anyone who&#x27;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&#x27;t appreciably worse than any other toolchain out there for the most common workflows).

I can deal with large builds, what I cant deal with is time. My rust web application takes 20 minutes to build in release mode on a high end developer machine. I can’t build it in ci&#x2F;cd.

It would help, yes. Here&#x27;s one of my projects, that uses different subdirectories in target&#x2F; based on compiler options pre-commit runs:<pre><code> $ du -hcs target&#x2F;
 190G target&#x2F;</code></pre>

The Rust toolchain by default produces a lot of debug information for each crate being compiled and the language relies heavily on monomorphization (instantiating a different function&#x2F;type for each combination of generics) which translates to generally having duplicated functionality where the only difference in the object code is the different types. These two things combined, along with large dependency trees and that &quot;features&quot; for conditional compilation cause the same crate to be considered different across different workspaces (meaning the rlibs that were created for one can&#x27;t be reused for another), means that the target directory for Rust projects can quickly grow. That, + clippy not having stabilized an already implemented process to automatically delete files from the target directory when they are unlikely to be needed again (which can&#x27;t be 100% accurate, it uses heuristics because a developer could always potentially need an exact rlib from 6 months ago, it is just unlikely) means that you can expect that under the default configuration your target directory ends up being huge after a short period of time.A lot of those things are in different stages of being fixed. I would personally want the default for generated debug information to be changed. cargo gc will help with running out of disk space. Better cross-project reuse of existing rlibs could be accomplished with some better tracking of optional features that can be unified (think having `serde` with feature `derive` enabled in one project, and having it without it in another: features are supposed to be purely additive, so you could reuse the earlier rlib on the later, but in practice people (ab?)use features in non-additive ways so it isn&#x27;t straighforward to do something like that by default). Tools like hakari lets you create workspace-unified Cargo.toml to emulate this behavior.

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

Smaller target directory size would be such a lifesaver. Hoping the best for you, and Rust!

The &quot;hint&quot; you could provide today for polymorphization is to write code like<pre><code> fn needs_string_like(x: Into&lt;String&gt;) {
 fn actual_logic(_: String) {}
 actual_logic(x.into())
 }
</code></pre>
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())`).

&gt; polymorphismI 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&#x27;s purely just removing duplicate work - this is for cases like Vec&lt;u64&gt; and Vec&lt;i64&gt;, where we currently emit code for each one separately, even though it&#x27;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&#x27;d be useful to have source level annotation). I think it&#x27;s too early to tell how all of this is going to look like, though.

I&#x27;m curious about polymorphism. Should it be default on for debug builds just to save storage and compile time? How will rust decide whether to enable polymorphism? Will it be possible to provide source-level polymorphism hints to the compiler?

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

I don&#x27;t understandy why, but all submissions of this post so far had incorrect title. When I posted the correct one, it still got reassigned the wrong title and I had to edit it (and it didn&#x27;t allow me to do that yesterday, only today).

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 &lt;T as Trait&gt;::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&#x27;t blocked by the new solver.

What are the problems in async the new trait solver will fix? Looking forward to building more on async Rust so I&#x27;m curious

On this topic, how ironic that the Ruby dude who is getting infamous for doing this is preaching moving to Rust

Leadership matters. I don&#x27;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.

Pretty wild to see how different people’s experiences can be within the same industry but under different applications and circumstances, here is someone joyful about the future of a language whereas not long ago we had a Ruby gem maintainer in deep dissatisfaction and frustration with the future of it.Not implying to compare Rust and Ruby, just mainly observing how these two things came out near each other in the present day.

is it going to be useful in a LLM-driven code-world.

A bit out of the loop, what&#x27;s going on with clippy?

I&#x27;m wondering about the future of clippy.

Hexcat link is broken and leads to &quot;https:&#x2F;&#x2F;https&#x2F;&#x2F;hexcat.nl&quot; instead of <a href="https:&#x2F;&#x2F;hexcat.nl" rel="nofollow">https:&#x2F;&#x2F;hexcat.nl</a>

You mean progress to make the framework faster itself?I was asking about something else, i.e. basically saving whatever possible from those expensive computations on disk, so next time it starts, it can spend significantly less time (assuming things didn&#x27;t change too much). clangd has such feature and it&#x27;s super helpful.Or you mean Salsa already supports such persistent caching in some form?

(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&#x27;s not particularly fast, it&#x27;s also not a priority for the r-a team (though if you want to contribute, you&#x27;re welcome of course).

Somewhat indirectly related, but is there any progress on implementing persistent caching in rust-analyzer? It would really benefit from faster startup times.

Unless you work at a FAANG the team will ask you to make a tool and will probably be fine with a mainstream language.

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&#x27;s better to ask for forgiveness than permission if that means not having to fool with Java.

The best way to get a rust job is get a regular job and just write rust

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