So, steady-state performance that's about as good as Java or C# on average, but with memory safety, much smaller baseline executable size (yes, even compared to GraalVM Native Image; I haven't checked current .NET AOT), faster startup (yes, I know that's what Native Image does optimize), and lower memory footprint? I'll take that deal, even if there's a substantial gap between safe Rust and C++ or Zig. I badly wanted something like safe Rust when working on desktop applications throughout the 2000s and into the 2010s, and now it's here, with a strong and growing library ecosystem.

If that were the actual tradeoff, I'd take it, too (and BTW, Java's memory safety is much better than Rust's, but that's beside the point now). Remember that even 25 years ago you had a very similar thing with C++ vs Java, aside from memory safety, but people didn't make an exceptionally big deal about it then. The main problem with C++ was that, over time, it gets harder and harder to evolve the program, especially while keeping performance reasonable (you can make C++ programs easier to evolve by using a lot of dynamic dispatch and the refcounting GC, but in low-level languages you pay for those in performance dearly).

So what you're really getting is, typically, a smaller executable, a faster startup, and lower footprint (which is actually a much more complicated matter, but I won't get into it now) in exchange for significantly higher evolution and maintenance costs forever. This is a good and reasonable tradeoff for small programs, especially CLI tools, and not a very good tradeoff for larger and/or longer-lived programs.

> People don’t get it. I’ve given up trying to explain. Systems thinking isn’t as titillating as conspiracism, doomerism, or misanthropic cynicism I guess.

OK, you've explained it, and I think I buy that explanation. But now what do we do about it? At least the conspiracism gives us an enemy to be angry at and maybe try to fight.

> Their stuff is already better than what nVidia is offering with stuff like the DGX Spark.

How so? In tokens per second when running major open-weights models, or something else?

A heavy way that, as typically used, goes against the grain of the web, particularly for document-centric sites. For example, on the Oxide RFD site, the RFD links don't do a real browser page load, but use JavaScript to fetch the new content and update the page in-place. This breaks the experience of screen-reader users unless the site or framework does some kind of workaround (which, somewhat to my surprise, the Oxide RFD site doesn't do), and even then, it doesn't match the experience of doing a real transition between pages with a screen reader. For something like the Oxide RFD site, I'd be much more inclined to use something like Astro or Marko, with minimal client-side JavaScript and no SPA-style navigation.

I would also be surprised that the RFD site breaks screen readers, generally they're pretty good about that.

And yeah, you also can use react with no client side JS as well.

The difference is that with software before the rise of giant machine-learning models, the software is derived entirely from human-understandable source, and often a full software stack can be built on a single computer, as anyone who ever ran Gentoo knows. While the source of any non-trivial software stack is too large for any single human to understand in full, a single human can understand any part of it. That's not true of model weights. And my understanding is that even the smallest open-weights models that are remotely in the same class as LLMs require large computing clusters with powerful GPUs to train. That puts training a model, or retraining one from its true source materials (the training data and processes), in an entirely different class than rebuilding Gentoo, even with GNOME, Firefox, LibreOffice, etc., even if the training data and processes are available, which they're usually not. So, we should treat these models as a different kind of thing than the tools that we developers have worked with until now.

> It's just not that hard to link to the system's UI libraries.

Are you concerned that as SwiftUI and Jetpack Compose continue to become the preferred native UI frameworks on Apple and Android respectively, you're going to need to figure out a way to bridge to them from Rust?

I think I might need to bridge to them from rust. But that doesn’t sound impossible. Just … tricky. Especially to bridge to them in a performant way. I’m not sure if SwiftUI has a lower level api.

Wait, why involve wasm in this?

Wasm will be optional. Really, I have 2 goals with this:

1. Short term, I want a good, clean, rust UI library for building native applications.

2. Long term, I'm making my own OS / computing environment. I have a whole bunch of strange sounding ideas for how I want that to work. For example, I want to be able to just launch an app via a URL like we do on the web. I want to be able to write a program once and run it on any computer or phone. (Though it may want platform specific tweaks).

For (2) to work, I'm experimenting with a design where I separate the application into 2 parts: the platform specific layout engine & UI, and the application's logic & code. Like webpages and a web browser. This could bring a bunch of benefits - including allowing apps to be write-once, run-anywhere. This separation would make it easy to allow apps to be written in other languages, like C#, Go, C, etc. And I think we can make a special host app for LLMs to interact directly with applications.

But the downside is wasm. Apps will run slower, and lose raw access to the raw platform APIs. But, since the interaction between the application and the host is just function calls, it should be easy to just skip wasm entirely. My plan is 2 separate compilation modes: 1. Compile a native app. No wasm. The result is a simple binary. And 2. Cross platform wasm mode.

That's the plan at least. We'll see!

I respect the people who still haven't tried. They held a firm line when the rest of us were drawn to the shiny new thing. They're not becoming dependent on yet another centralized service (let's be real, the big centralized models are still way better than the open-weights models that most of us can run, particularly for coding). They can still develop software with nothing but their own computer, and that computer doesn't even have to be particularly new.

To steelman the haters, I think their view is that the industry is so uniquely shitty that it's unconscionable to help the industry at all by using the tech, which is a product of that industry.

It’s far less shitty than the social media industry (except where it overlaps) but that’s IMO.

Still kind of shitty. But if you really hate it use open models hosted commodity.

I wonder how you arrived at that number. Is it perhaps a number that we should aspire to, if we want to write high-quality, maintainable code by hand?

I've been doing some reading recently around what the literature expects a professional software engineer to produce in a day.

In ~1976 Mythical Man Month era it was around 5 lines of fully debugged assembly.

Code Complete 2nd edition ~2004 bumped that up to 10-50 delivered lines of code per day.

I found other estimates of around 20-60. I need to pull them altogether into a cited article.

Based on that plus my own experience I think 100 lines per day of production-level, reviewed and debugged code was a reasonably higher target for a professional software engineer up until just a couple of years ago.

Today I'm frequently pushing 2,000 to 4,000 - and that's not vibe coded junk (I can easily hit 10,000+ if I'm not reviewing anything), that's code that I've reviewed and am happy to put my name to.

Obviously counting lines of code is a stupid, easily gamed metric. But I still think there's signal there. If you want to build a sophisticated piece of software you're going to have to write a bunch of code to do it. Writing at 1,000+ lines of code per day vs 100 will get you there faster.