And so I think the idea is more to understand tomorrow ... from first principles.
In the late 80's, as a teenager, I learned x86 assembly and C because that was the only way to squeeze out enough juice from my shitty CGA (and later VGA) card to programm the games/graphics that interested me.
I haven't written assembly in years.
But whatever I did in my career: it helped me and gave me an edge over my peers to have a foundation that is very close to the metal.
We don't know this. So many people are simply claiming this confidently, and a lot of them are betting their careers on it, but nobody has a crystal ball. Whenever someone tells you confidently, and without any doubt or qualifications, that something "is the future," be skeptical.
I remember when the Segway was definitely going to change urban planning worldwide.
Current AI can automate significant amounts of grunt work in programming and math. It's good at running web searches and writing summaries. There are a few other niches where it is currently successful. But other than that, many corporate AI projects are spectacular failures.
So just given what we have in hand, assuming no further breakthroughs, then we're maybe looking at AI being somewhat bigger than the Internet. Which would make it a revolutionary technology, sure.
But to get from "a revolutionary technology" to "the substrate the future runs on", then you need to assume more breakthroughs: long-context operation over weeks or months, displacing human workers 100% instead of 75%, and the ability to directly economically compete with actual humans. And people are investing literal trillions of dollars to make that future come true, without really thinking through what truly competitive-with-human AI would actually mean. We might be looking at massive job loss, centralization of power, fully automated "companies" with no humans dominating markets, and other dystopian scenarios.
And in those worlds, it's unclear that being good at CUDA and matrix math will be all that helpful, careerwise. The AIs are already pretty good at that stuff. Data scientists get paid OK when they actually get hired, but it's not everything college students were promised in the 2010s, either.
We can't yet build a fully-general competitor for the human mind. But we're getting closer. And if we ever do build one, the consequences will be really weird in any number of ways. So I worry about visions of the future that assume AI keeps improving significantly, but that also assume it still somehow remains a "normal" technology that doesn't, for example, render most humans fundamentally uncompetitive.
> But to get from "a revolutionary technology" to "the substrate the future runs on", then you need to assume more breakthroughs: long-context operation over weeks or months, displacing human workers 100% instead of 75%, and the ability to directly economically compete with actual humans ... without really thinking through what truly competitive-with-human AI would actually mean. We might be looking at massive job loss, centralization of power, fully automated "companies" with no humans dominating markets, and other dystopian scenarios.
At 75% replacement of a worker we would already have huge job losses as each individual would be doing what several before did.
The only alleviation would be the creation of new equivalently paid jobs, which is no better than a hypothesis right now.
I know what you are getting at, but I think that's an unfair characterization after all.
I don't want to shit-talk Ratspeak, but the foregone description of community and momentum seems far fetched. Additionally, the vibe is pretty off compared to Reticulum. Nothing here points to "successor" IMO.
> Rust is comparatively worse, because LLMs don't make the same coding mistakes that humans do that justifies the existence of the borrow checker, [...]
That's a pile of bollocks, pardon my French. Source/proof?
And to the contrary:
I've been working on a TS codebase that calls into C++ native/wasm-compiled code for six months now. The code is mostly LLM written.
Over these last six months we had four use-after-free and two other ownership-related bugs in LLM-generated TS code.
Whereas we had zero issues of any such kind with LLM-generated Rust code that sits in another two native/wasm-compiled metacrates we use.
LLMs are not much better at ownership tracking than humans.
Especially if resource acquisition and release are far apart in code and/or somehow nested/stacked/non-straightforward.
The problem with ownership tracking is that it's global. Humans are bad with global things, linters too, but LLMs are exceptionally bad at them due to the context window and (currently, at least) not knowing enough where to search. So yes I'd expect them to make the same mistakes as human and even more frequently.
I feel like LLMs and vibe coding have opened up rust to the kind of script kiddie who would previously have been begging for help on r/javascript or whatever.
If there is a problem with global lifetimes then the problem is certainly the person driving (or not) the LLM. Global lifetimes? FFS. Rust is hard because writing services that don’t have bugs is hard.
LLMs are not currently able to vibe a sophisticated application or service in rust. If it tells you it can do it in typescript or python, the it most likely certainly has not and you will have a wonderful time in production. Rust will burst that bubble.
I'm curious on what you mean by "TS use-after-free", because as you obviously know, TS is GC'd. I don't have access to your codebase of course, but it seems to me that it is an FFI/native code boundary lifetime bug in the binding between TS and C++/WASM, not part of the TS managed memory. Comparing TS to native C++ FFI and/or manually managed WASM resources interface vs Rust + Rust ownership checked resources interface is kinda comparing apples to oranges here.
And as other commenters here have said, Rust's main issue for LLMs is infectious lifetime propagation, where the borrow checker knows you violated a lifetime constraint but doesn't tell you how to actually solve it, so LLMs get error messages like:
borrowed value does not live long enough
cannot borrow `x` as mutable because it is also borrowed as immutable
lifetime may not live long enough
And instead of trying to reason through the ownership graph, they just take the shortest path to get these things to go away by bypassing the borrow checker entirely, which defeats the entire point of using Rust to begin with.
Source? I haven't heard of that failure mode being especially prevalent. (Also, by "bypassing the borrow checker" do you mean unsafe raw pointers, Rc/RefCell, or something else?)
I build a tool like this with Claude in 2hs, uses Rust with OpenCV crate, egui GUI, PDF output.
Basically it steps through a folder with images, finds corners, user presses Space if ok, or adjusts corner if not (about 1 in 20 pages has a corner wrong).
Undistort, contrast correct based on histogram, etc. happens automatically.
On the last page pressing Space creates a PDF.
My brother and I were digitizing medical bills for our mother and everything we tried to do this with out there was meh, cost money or both! It seems as soon as you need PDF anything it's $$$.
This is a throwaway tool as we're now more and more getting bills as digital files anyway.
My only input was specs, otherwise it's "vibe coded" if you want.
But consider that the Rust crate ecosystem is mature and my prof. background is computer graphics.
Oh, and I have an image manipulation crate that I wrote for work (closed source for now, unfortunately) that has corner pin with area filtering as a primitive.
I was just surprised how possible this is now.
This was earlier this year (Opus 4.8 was just out) and while we were photographing the pages with our smartphones Claude wrote the tool.
Yes, editions are a great mechanism. It still has its limits, especially if you want easy edition migrations. All existing Rust code assumes it can drop any type whenever it wants, and that is not something you can just change across editions. You have to be very careful with defaults if you don't want conflicts when crossing edition boundaries.
The naïve idea would be to just say that all generic parameters have an implicit `where T: Move` bound, and you have to explicitly opt out of it with `where T: ?Move`, just like with `?Sized`.
In fact, that's exactly how I would expect it to work, but there may be non-obvious drawbacks.
The compat issue has always been associated types on std traits.
For example, should Iterator::Item be Move or ?Move
If you leave it as Move, you can't create any iterators over !Move types. If you change it to ?Move, then functions using generic iterators can't assume that the elements of an Iterator are always moveable. Which is a breaking change compared to now.
The most critical trait is probably Deref. Using !Move types without `Deref::Target: ?Move` is painful, because calling any method on boxed types relies on Deref.
The people working on this are aware that it poses backcompat problems that don't have obvious solutions. They are looking into non-obvious solutions. https://lcnr.de/blog/2025/11/28/implicit-auto-traits-assoc-t... is the most up-to-date one I'm currently aware of.
Niko Matsakis (T-Lang) has since also published a post on only-bounds: https://smallcultfollowing.com/babysteps/blog/2026/06/09/onl.... Sized hierarchy, Move, and Forget/Leak all share the same fundamental compat issues, so we're all pretty motivated to solve the underlying problems in a way that enables all the other features to be built on top.
I had read that post, but IIUC it doesn't address the kind of backcompat issues that I meant to be referring to (the ones that would apply even if there was only ever going to be one new question-mark trait).
I'm very probably missing something, but as a user I would definitely expect `Iterator::Item: Move`, but then also that `&{mut} T: Move where T: ?Move`.
But yeah I can see how these bounds are somewhat viral. Thanks!
Imagine if MyTrait comes from core/std. Adding an opt-out bound like ?Sized (or ?Move) is a breaking change for any generic code that relies on Sized/Move. But you want some traits from std to be open for !Move types.
Editions are limited, there is this urban myth they can do anything regarding language evolution, but that isn't the case.
First of all they don't apply to the standard library currently, secondly the kind of automatic changes that are enabled and supported by rust fix, are limited.
In the Paris area, if you commute during rush hour, you'll probably been stuck between 100 people per square meter. At best, you can listen to some podcasts or audiobooks.
When I still had to work from the office, I was fortunate enough to be able to move my hours earlier so I could avoid morning rush hour and could, indeed, read in the morning. Afternoons I couldn't, more often than not.
It was just wasted time. I can also read on my couch before I start working from home. I've read many more books since I was able to WFH on most days.
Can confirm .. I grew up in a country (Australia) which is practically impossible to live in, without a car .. then I moved to California and did everything I could to avoid the commutes (really a very difficult task), lived there for 15 years and only managed to optimize my life to be able to walk around LA/my neighborhood in the last few years of it .. then moved to Japan for a year, where everything I needed to survive was within a 10 minute walk of my apartment - and then to Austria, in a city that was laid out a thousand years ago to be navigable by foot, and still is.
Commuting is one of the worst aspects of the Western world. The fact that hundreds of millions of people have to sit in their cars, for hours every day, to get to work/play/live, is just a tragedy. I truly hope the next hundred years proves much, much more fruitful for those of us who are willing to change lifestyles to avoid the commute. Its a huge drag.
I agree with you as long as it's passive commuting (NOT driving). I had a few jobs / cities with long (45+ minute) commutes and I also got a ton of reading done that I wouldn't I wouldn't normally
My experience is that for people with kids, this benefit basically disappears and they want every spare second they can get
Definitely not; I'm looking at a possible new job, but public transit to get there is an hour and a half. Even though they only ask you to be in the office two days a week, that's 6 hours a week I won't get back.
I mean I still want to apply to the job to see if they offer me a significant step up in terms of wages (doubtful), but I'd rather have something closer to home.
It's great if you can do that -- some people (I, for one) get such heavy nausea from reading in any kind of transport that the only thing I can do is listen to the music and look at the clouds.
That's relevant to why it historically had bizarre UX issues, like ctrl+s being the shortcut to erase the scene and start a new one: it predated most of those conventions, and has its own UI tooling. It's also always been designed to use three mouse buttons, coming from the Unix world, which used to be problematic when not everyone had a mouse with a clicky scroll wheel.
It's come an absurdly long way since I first dabbled with it in the early 2000s, and has gone from a niche FOSS tool to something widely used in its field.
Nowadays, Blender is an example of masterful UX for a professional tool. Immediately responsive, information dense UI with keyboard shortcuts for absolutely everything. Actions are composable, like with vim: something like "ex5" will extrude five units on the x axis.
Right, but those are for simple tasks. Much like vi or emacs, the keybindings are esoteric and historical but so much of what makes the tools great is reliant on on said historical and esoteric behaviour that changing any of it becomes an exercises in futility
And so I think the idea is more to understand tomorrow ... from first principles.
In the late 80's, as a teenager, I learned x86 assembly and C because that was the only way to squeeze out enough juice from my shitty CGA (and later VGA) card to programm the games/graphics that interested me.
I haven't written assembly in years.
But whatever I did in my career: it helped me and gave me an edge over my peers to have a foundation that is very close to the metal.