Naturally this will be somewhat critical, but I need to first put things into context. I do believe that we really need an alternative to Google dominating our digital life. So I don't object that we need alternatives; whether Ladybird will be an alternative, or not, will be shown in the future. Most assuredly we need competition as otherwise the Google empire moves forward like Darth Vader and the empire (but nowhere near as cool as that; I find Google boring and lame. Even skynet in Terminator was more fun than Google. Google just annoys the heck out of me, but back to the topic of browsers).

So with that out of the way ... Ladybird is kind of ... erratic.

Some time ago, perhaps two months or three, Andreas suddenly announced "Swift WILL BE THE FOREVER FUTURE! C++ sucks!!!". People back then were scratching heads. It was not clear why Swift is suddenly our saviour.

Ok, now we learn - "wait ... swift is NOT the future, but RUST is!!!". Ok ... more head-scratching. We are having a deja-vu moment here... but it gets stranger:

"We previously explored Swift, but the C++ interop never quite got there, and platform support outside the Apple ecosystem was limited. Rust is a different story."

and then:

"I used Claude Code and Codex for the translation. This was human-directed, not autonomous code generation"

So ... the expertise will be with regards to ... relying on AI to autogenerate code in ... Rust.

I am not saying this is a 100% fail strategy, mind you. AI can generate useful code, we could see that. But I am beginning to have more and more doubts about the Ladybird project. Add to this the breakage of URLs that are used by thousands or million people world-wide (see the issues reported on the github tracker); or also the fact that, once you scale-up and more and more people use ladybird, will you be able to keep up with issue trackers? Will you ban more people?

In a way it is actually good that I am no longer allowed to make comments on their repository because I can now be a lot more critical and ask questions that the ladybird team will have to evaluate. Will ladybird blend? Will it succeed? Will it fail? Yes, it is way too early to make an evaluation, so we should evaluate in some months or so, perhaps end of this year. But I am pretty certain the criticism will increase, at the least the moment they decide to leave beta (or alpha or whatever model they use; they claimd they want a first working version in this year for Linux users, let's see whether that works).

I'm not sure how I'd feel if I woke up and found a system I worked on had been translated into an another language I'm not neccessarily familiar with. And I'm not sure I'd want to fix an non-idiomatic "mess" just because it's been translated into a language I'm familiar with either (although I suspect they'll have no problem attracting rust developers).

Rust syntax is a PITA and investing a lot of effort in the language doesn’t seem worth the trouble for an experienced C++ developer, but with AI learning, porting and maintenance all become more accessible. It’s possible to integrate Rust in an existing codebase or write subparts of larger C++ projects in Rust where it makes sense.

I was recently involved in an AI porting effort, but using different languages and the results were fine. Validating and reviewing the code took longer than writing it.

    > Porting LibJS
    > Our first target was LibJS , Ladybird’s JavaScript engine. The lexer, parser, AST, and bytecode generator are relatively self-contained and have extensive test coverage through test262, which made them a natural starting point.

    > Results
    > The requirement from the start was byte-for-byte identical output from both pipelines. The result was about 25,000 lines of Rust, and the entire port took about two weeks. The same work would have taken me multiple months to do by hand.

How long until Ladybird begins to impact market dominance for Chrome and Firefox? My guess: Two years.

That's a lot of people contributing.

How many of them will be less willing to contribute in the future, and less productive when they do if a sizable portion is in Rust? Maybe there'll be more contributions and maybe there'll be less. I don't know. If you've managed to develop a community of 1200 developers who are willing to advance the project why upset the applecart?

Ah, but I see they actually haven't done that to most of their code, so maybe it's just a bit of pandering to the hype and fashion.

The article fails to explain why. What problems (besides the obvious) have been found in which "memory-safe languages" can help. Do these problems actually explain the need of adding complexity to a project like this by adding another language?

I guess AI will be involved which, at this early point in the project would make ladybird a lot less interested (at least to me).

So, even though they want the code base to be in Rust, they will continue writing new code in C++ and then translating it to Rust later to remove the C++ they just added.

There must be a really good reason for this, such as Rust doesn’t interop well with C++, otherwise this seems like a poor decision.

I am very interested to know if this time and energy spent actually improved memory safety.

Other engineers facing the same challenges want to know!

This project, of all of them, throwing in the towel on AI makes me fear AI abstainers have no future.

I guess it's a long way off, since the LLM translation would need to be refactored into natural Rust first. But the value of it would be in that it's a real world project, and not a hypothetical "well, you could probably just...".

I'm confused about this part. What part of the browser did they want GC and inheritance for? I'd get it if they were writing the UI in this, but the rest of this post is about the JS engine. They weren't going to 1:1 map JS objects to Swift objects and rely on ARC to manage memory, were they?

I watched some of his streams on the development of the JIT compiler (what this change set seems to replace) on one of his streams, and was blown away by the quality of Copilot generated suggestions/completions on an (under-represented) domain (x86 opcodes, etc). This was before Claude Code et al, and pretty early-on for LLM tooling.

The inevitable cleanup that will follow this could be done the same way. Refactoring like that can be done in more bite sized chunks, which makes it easier to review what is happening and control how it is done.

this entire project starts to look like "how am i feeling today?" rather than a serious project.

EDIT: bramhaag pointed out the error of my ways. Thanks bramhaag!

i had high hopes for ladybird to become an alternative browser anyone with a working C++ compiler could build on whatever platform.

Given it's not launched and it's donor driven, I guess conserving developer time is a key priority? Dual track sucks lots of time?

I've translated it from Rust to V in 45 minutes. Works great:

https://github.com/medvednikov/libjs_v

Compiles in 0.2 seconds on my M5 (compared to Rust's 3.3 seconds).

Yep, it was also a weird, not entirely pragmatic choice, even if it was well justified technically and all-in-all rational. D would be the same.

> The browser and libraries are all written in C++. (While our own memory-safe Jakt language is in heavy development, it’s not yet ready for use in Ladybird.)

https://awesomekling.github.io/Ladybird-a-new-cross-platform...

only thing I could find - has it been actually used in Ladybird after all?

It also doesn't have the disadvantages of Swift. Once the promise of Swift/C++ interop is gone there isn't enough left to recommend it.

[1]: https://www.swift.org/documentation/cxx-interop/

[2]: https://www.swift.org/blog/improving-usability-of-c-librarie...

I work on such project, where we use simplified C++, and it works fine, no memory corruptions in my experience.

But I'm also cheering along Ladybird's progress. There's definitely room for more than one project in the space. And IMO the more browsers being built in Rust in the better.

I see it all the time at the Director and VP level. Once big money is on the line, there are no failures, just "opportunities for strategic realignment"

  > monopolies

That choice was never made. C++ was selrcted as the language of choice for SerenityOS. Since the goal of the OS was to make its founder happy, and C++ was his faviourite language at the time, that seems like an obvious choice. Later, as part of SerenityOS, there was a need for an HTML parser. It was written in C++ as was the rest of the operating system. Then that HTML parser evolved into a full web browser. As part of the SerenityOS project, that browser was written completely in C++. Then that web browser forked off into an independent project...

Ladybird was already a fully functioning browser (not finished of course but complete enough to surf many web pages) when it was forked from SerenityOS to create a stand-alone web browser. The choice at that point was "keep evolving the current C++ code base" or start-over. I doubt the second option was even considered.

They have been evaluating other languages since before the fork. Rust was evaluated and rejectd early-on. They even created their own language at one point. https://github.com/SerenityOS/jakt

Perhaps, but in fairness the project was started in 2018 when Rust was still new and unproven.

> You can't compare the choices made to evolve a >20 years old codebase with a brand new one.

I guess not, but I'm pretty optimistic about Ladybird's ability to adopt Rust if they want to. It's a much smaller codebase than Firefox (~650K LoC).

This initial PR is already ~25k LoC, so approximately 4% of the codebase. It took 1 person 2 weeks to complete. If you extrapolate from that, it would take 1 person-year to port the whole thing, which is not so bad considering that you could spread that work out over multiple years and multiple people.

And Firefox has shown that the intermediate state where you have a mix of languages is viable over the long term, even in a much larger and more complex codebase.

But translating with automated tools is a much faster experiment.

Sometimes (not always), rewriting from scratch ends up in a big loss of time and resources and never replaces the old version.

The sort of rewrite you're talking about can work well at an early stage of a project, in the spirit of Fred Brooks's "plan to throw one away". But for a mature browser like Ladybird that's trying to not break the user experience, it's much better to have a pure translation step, and then try to improve or refactor it later.

I feel the effort and frustration to have parity with LLM is more than doing a full rewrite without.

It wasn't the cause of this change; the submitter submitted it without the “with help from AI” part, for some reason.

https://github.com/anthropics/claude-plugins-official/pull/1...

(or generally: “Is the cocaine cartel comparison fair or unfair?”)

One problem I've noticed is that both claude models and gpt-codex variants make absolutely deranged tool calls (like `cat <<'EOF' >> foo...EOF` pattern to create a file, or sed to read a couple lines), so it's sometimes hard to see what is it even trying to do.

The difference now is they can get much further along.

The C10K was a long-solved problem when Node came out; just it was not for what 99% of people used at the time, i.e. PHP/Python/Ruby.

Rust, although annoying at a micro scale, does at least enforce some structure on your code, although like Kling I miss OO.

AI has made Rust approachable to a new audience of programmers who didn't want to dedicate their life to learning the ins and outs of the language. Especially for C++ developers who already learned the ins and outs of a hyper complex programming language and don't want to go through that a second time.

Before AI, writing Rust was frustrating experience that involved spending 90% of your time reading documentation and grumbling that "I could do this in 5 minutes in C++"

Now I can write Rust in a way that makes sense to my C++ addled brain and let the AI do the important job of turning it into an idiomatic Rust program that compiles.

This doesn't mean that being agentic cannot be cultivated by regular people.

In 2026, yes, agency matters more than skill/wisdom/intelligence to get VC funds. But what's the point of agency alone if you are leading such a life?

What gives me hope is that in 2026, skillful people can delegate a lot of their work to LLMs, which gives them time to learn the "agentic" part which is basically marketing and talking with people.

(just thinking out loud)

There are many examples of good engineers that are also good leaders. I think the Venn overlap isn't that unusual, at least for a good engineer leading a team up to maybe a dozen. When a good engineer lands in a spot where they get to work on something they really care about, that doesn't hurt either!

Now, how many good engineers are also good at leading larger teams? As the team size increases, my impression is that it is less common. If so, why? Lots to explore around individual, cultural, and corporate factors.

* If one sets a prior probability to 0 or 1, a posterior probability will not change due to Bayes' Rule. This means new information has no effect. Put another way, choosing either 0 or 1 as a prior is equivalent to stating "no new information will change my belief."

The Rust compiler is incredibly solid (across all target platforms), and while it's C/C++ interop is relatively simplistic, what does exist is extensively battle tested in production codebases.

for example: "Swift fails to import clang modules with #include <math.h> with libstdc++-15 installed. Workaround: None (!!)"

As a very practical problem the assembly would consume the context window like no other. And another is having some static guardrails; sometimes LLMs make mistakes, and without guard rails it debugging some of them becomes quite a big workload.

So to keep things efficient, an LLM would first need to create its own programming language. I think we'll actually see some proposals for a token-effective language that has good abstraction abilities for this exact use.

I think, changes to languages/tooling to accomodate Agentic loops will become important.

> All of this assume that you care even a tiny bit about what is happening in your code. If you don't...

I mean, as software engineers, we most certainly do. I suspect there'll be a new class of "developers" who will have their own way of making software, dealing with bugs, building debugging tools that suit their SDLC etc. LLMs will be to software development what Relativity was to Astrophysics, imo: A fundamental & permanent shift.

- A bit more on mail mode https://x.com/hsaliak/status/2020022329154420830

- on the Lua integration https://x.com/hsaliak/status/2022911468262350976 (I've since disabled the recursion, not every code file is long and it seems simpler to not do it), but the rest of it is still there

- hotwords for skill activation https://x.com/hsaliak/status/2024322170353037788

Also /review and /feedback. /feedback (the non code version) opens up the LLM's last response in an editor so you can give line by line comments. Inspired by "not top posting" from mailing lists.

I'm guessing the direction I'd prefer, would be tooling built to accept and be driven by humans, but allowed to be extended/corrected by AI, or something like that, maybe.

Maybe a slight contradiction, and very wish-washy/hand-wavey, but I haven't personally quite figured out what I think would be best yet either, what the right level actually is, so probably the best I could say right now :) Sorry!

> Imagine if I had written a comment to explain my intent for the function before I started writing the function body.

The loon programming language (a Lisp) has "semantic functions", where the body is just the doc comment.

>Imagine if I had written a comment to explain my intent for the function before I started writing the function body.

This in particular is not dissimilar from opening a chat with a model and giving it a prompt as usual but then adding at the end:

Begin your response below:

  { func

(1) It captures the ideal so well

(2) The bitter irony of how thoroughly pre-OS X Macintosh computers failed to live up to it

I feel like there's a similar dichotomy in LLM tools now

"Bicycle for the mind", as always when it involves Jobs, sounds more fitting for the masses though, so thanks for sharing that :)

Its purpose is not to reinvent everything. It’s not a hype project.

the relevant bit here is that he's porting from a language in which he has plenty of experience into another one in which he doesn't, in a large project

that in itself sounds like putting a lot of faith in LLMs but maybe there are factors not mentioned here, which is why i said "on the surface"

In Ladybird's case, tests they could rely upon.

You get to good at schmoozing the compiler you start to create actual logical bugs faster.

Anyway I personally have asked LLMs to create more detailed TODO items for myself, on personal projects where I am the only human programmer who had laid eyes on the code. In fact, I do this frequently, including multiple times earlier today. So I don't take the idea seriously that using an LLM to generate a TODO comment is an inherently disrespectful thing to do.

And if you mean before the whole .NET Core rewrite, many big corp server applications were already written in .NET, products like SharePoint, Sitecore, Optimizely, Dynamics 365, Four51,.... and plenty of server infrastructure for XBox and Windows games.

There's a huge distinction between Vibe Coding, and actual software engineers using AI tooling effectively. I vibe code for fun sometimes too, nothing wrong with it, helps me figure out how the model behaves in some instances, and to push the limits of what I understand.

OOP, weakly-typed templates, and mutable aliasing create impedance mismatch in almost every C++ API.

Rust doesn't have data inheritance, and what looks like interface inheritance is merely extra requirements in a flat list of traits, so subclassing won't behave like C++ APIs expect. When you translate a class hierarchy to Rust, it needs lots of crutches which make it weird, boilerplatey, and tedious to use. There's no good recipe for OOP hierarchy in Rust, because the idioms are so different. The mismatch feels like writing an ORM.

For some C++ APIs mutability and circular references can be a pain too. Rust works well with DAG data structures and clear mostly-immutable data flow. Objects with some "parent" pointer are common in C++, but Rust sees them as potentially dangling, with shared mutable state, and requires much heavier control of them. It can be done, but it's ugly. Idiomatic Rust designs go to great lengths to avoid it unless necessary, but C++ APIs can have the extra pointers "for convenience".

There's a reason why Rust doesn't have typical GUI libraries - an arbitrary web of references between widgets and event handlers make it ugly in Rust, and that's on top of a view class inheritance.

C++ templates sit very uncomfortably between Rust's macros (duck typed) and Rust's generics (strictly typed at point of declaration).

C++ templates almost always are a mix of types they're attached to and some duck-typing in their expansion.

Rust's generics do not allow any duck typing at all. This makes translation of even a tiny bit clever C++ templates a chore. There's no specialization. No way to deal with SFINAE and such.

Rust macros have flexibility for all the syntax shenanigans (and even similarly bad errors at instantiation time), but macros can't see any types. Idiomatic Rust has very deliberate division between traits (usually much simpler and smaller in scope), macros and proc macros/derives. Splitting C++ templates like that can be a major redesign.

Hardly much different than dealing with traditional offshoring projects output.

1. build / compile times can be atrocious

2. crates.io inherits the npm philosophy, which means fairly unmoderated space of third party deps and because the Rust stdlib doesn't have a lot in it, extensive third party crate (lib) usage is strong in Rust. As a result most Rust projects have rather sprawling dependency trees, often with duplicated functionality (multiple Base64, rand, sha256, etc crates). I personally have a problem with this (auditability, accountability, security, complexity etc). Others don't.

3. Despite being nominally runtime agnostic, Rust async basically is tokio and it's almost impossible to use another runtime once you factor in third party deps. In many ways Rust is the language that tokio ate. In fact even if you opt out of async entirely, you often end up with tokio as a dependency simply because the community just seems to expect it.

4. Despite advertising itself as a "systems" language, some basic systems programming facilities I expect from my C++ background are still fundamentally not there. In particular, per-container/struct pluggable allocators still isn't a thing and the feature to add it (allocator-api) has sat unmerged in nightly for almost ten years at this point and it doesn't look good for it landing any time soon.

5. If you're working in the embedded space, there's still plenty of devices that will not have a workable Rust toolchain option yet.

I still choose it for new projects instead of its competitors C++ or Zig. But I think it's important to recognize there are compromises like any other tool.

As much as people might insist otherwise, there will in fact come a day when there are "multiple Rusts" by which I mean multiple styles and ways of doing things -- just like C++. For myself, for example... if it were my repository and my team and my hiring, and I was starting from scratch... I'd be extremely careful about third party crate adoption and have an extremely minimalistic approach there. And I don't use tokio. Though my paying jobs do.

As a browser, Ladybird usefulness is currently quite limited for obvious reasons. This is not meant to dismiss its achievements, nor to overlook the fact that building a truly useful browser for everyday users is something few open source teams can accomplish without the backing of a billion dollar company. Still, in its present state, its practical utility remains limited.

A release (?)

It's vibe engineering

This completely misses the purpose of the downvoting feature, which is not surprising, since upvoting seems no longer to indicate quality or truth of the comment neither.

> rust is this sort of equilibra that the world has reached for, especially security related projects

Which is amazing, since Rust only covers a fraction of safety/security concerns covered by Ada/SPARK. Of course this language has some legacy issues (e.g. the physical separation of interface and body in two separate files; we have better solutions today), but it is still in development and more robust than the C/C++ (and likely Rust) toolchain. And in the age of LLMs, robustness and features of a toolchain should matter more than the language syntax/semantics.

> Rust does seem to be good enough for this use case.

If you compare it to the very recend C++ implementations they are using, I tend to agree. But if you compare it to a much more mature technology like e.g. Ada, I have my doubts.

I agree that Rust has very conventional C-like syntax, but I'd go further and say it has fairly conventional C-like semantics too, at least in its current iteration. I think you could safely duck type Rust itself as a C-like. :)

Strong agree that Rust has drawn great inspiration from the ML family by way of OCaml. Rust is a C-like with ML characteristics, which are its greatest quality, imho. On the other hand, I don't think there's much trace of Erlang left in Rust -- there's probably more Erlang in Go than Rust, and Go is squarely a C-like.

I think it's fair to say that Rust started out more exotic than it is now, but perhaps all that safe, C-like syntax has led to convergent evolution towards other C-likes?

> Rust did copy move semantics from C++, but even that ended up being different enough to be incompatible with basic C++ design patterns. Rust chose to have only trivially movable types and guarantee absence of move constructors, so it can't even safely pass a C++ std::string.

Right, but compare all of that to Erlang's actor-based message passing, where mandatory immutability averts the need to move or lock anything at all, and I think it's clear why one would group Rust with C++, and not Erlang.

tho duplicated crates with different major versions through transitive deps is also i believe possible

At least it gives _something_ back. Until of course we've obsoleted all of them as well.

Most of the AAA games I've paid for sit there in my Steam library and never get played. At least _some_ of the money probably went to those talented people whose work was used for training GenAI and coding models (and yes I say this as someone who has used all of these tools to prototype my own games, and still think human created content is of a much higher quality, just more expensive to produce).

How long time do we have to wait before these people get bored? Or might they actually find what they generate useful and it doesn't all go straight to /dev/null, since seemingly it seems to gain usage, not drop in usage?

He did write it.

> you're banking in the LLMs quite strongly when you do that, which may just work but i would be very worried about myself if i were in his boots

I too would worry if it were you doing it.

I guess that's sort of technically true, but not even really? Like, obviously you can compile Python to C and then compile that with clang, but it doesn't make it fast. But even if that were the case, there aren't that many languages that have Rust performance so who cares? "Potentially" is sort of saying we might have a future language that's better, but of course anyone would agree.

> Also there is the alternative path to execute code via agents workestration, just like low code tooling work.

I don't understand how this is relevant.

> I see you never had the fortune to review code provided by cheap offshoring teams.

I just don't understand why you're bringing it up tbh I don't understand the relevance.

Don’t do that! On a two-day-old term?!

No wonder we’re called gatekeepers.

Only because you focus too much into the frontend, instead of the whole compiler infrastructure, with multiple frontends for the same compilation pipeline.

> I still am not understanding the offshoaring conversation.

Because you never had to review human written code by cheap offshoring teams, zero difference with LLM generated code quality, even today.

https://github.com/AdrianVollmer/FluxFeed

https://docs.rs/jmap-client/latest/jmap_client/

    > I’ve been part of at least 2 successful rewrites. I think that Joel’s post is too often taken as gospel. Sometimes a rewrite is the best way forward.

I can recall recently, listening to an Oxide and Friends podcast where they spent 30 minutes dumping all over "Agile Dev", only to have a very senior, hands-on guy join from AWS and absolutely deliver the smack down. (Personally, I have no positive experiences with Agile Dev, but this guy really stunned the room into silence.) The best part: The Oxide crew immediately recognized the positive experence and backed off the give this guy the space he needed to tell and interesting story. (Hats off the Ox crew for doing that... even if I, personally, have zero love for Agile Dev.)

If you ask me, Go is a better Rust. Rust is an ugly version of C++ with longer compile times and a band of zealous missionaries.

I mean the keywords mut and fn very annoying to read just get rid of them or spell the f*n thing function.

Rarely if ever is anything able to compete simply by being "better". As far as USPs go it's just not enough. I reckon for ladyboy the USP (if any) is going to be it being open and NOT chrome (or derivative). So "safe" "modern" language is not going to mean much to the end users.

[1]: https://developer.chrome.com/blog/memory-safety-fonts

[2]: https://github.com/googlefonts/fontations/tree/main/skrifa

We spend quite a lot of time conceptualizing around safe self mod and to build apps that can change at runtime. We ended up using custom Lua VM, type system to catch mistakes, declarative homogenous infrastructure and actor model (erlang inspired).

Actor model provides not just a good isolation but also it's much easier for AI to reason (since most of components are not that large), we already able to use it to write quite complex systems with ease.

Another upside - in actor model you don't really need any of this fluff with cron jobs, queues and etc, all the logic naturally maps to indended architecture, making implementation of agents _very_ easy.

https://wippy.ai/en/tutorials/micro-agi It takes 4-5 files to create mini sandboxed AI agent at top of actor model with ability to modify own toolkit while having system guardails and no access to core filesystem.

RE: Claude Code, no I haven't used it, but I did do the Anthropic interview problem, beating all of Anthropic's reported Claude scores even with custom harnesses etc.

It's not a dunk that agents can't produce "as fast as can be" code; their code is usually still reasonably fast; it's just often 2-10x slower than can be.

For a taste: I wish we didn’t need lifetime annotations, somehow. I wish rust had first class support for self borrows, possibly via explicit syntax indicating that a variable is borrowed, and thus pinned. Unpin breaks my brain, and I wish there were ways to do pin projections without getting a PhD first. I wish for async streams. I wish async executors were in std, and didn’t take so long to compile. I could go on and on.

I feel like there’s an even simpler & more beautiful language hiding inside rust. I can’t quite see it. But I really hope someone else can bring it into the world some day.

> > Defect free.

There's a Google talk on the matter. "Defect rate" / "defect free" is a term that is used quite a bit. I've latched onto this, because I find it true. Rust is a far more defect free language on a line by line basis measured and compared to other statically typed languages.

> And I'd never call it "the final language"

I honestly disagree, and I'm sticking to this prediction.

I don't think we're going to be writing code much longer by ourselves. The machines are going to outpace us soon.

Maybe something that's LLM-oriented will take over, but at that point these won't be "human" languages anymore. So I'll revise my claim to "Rust is the last human language".

If I want to serialize my thoughts to code, Rust is the language for it. It's probably the last one I'll be hand-writing or sending my revisions back to the LLM for.

Rust will also be an order of magnitude easier to author, at which point there shouldn't be much holding people back from producing it. If you have a choice between generating Java, C++, Go, or Rust, you're going to pick Rust almost every time unless you have to fit into those other ecosystems.

If you haven't used Claude or Codex with Rust, it's sublime and you should drop what you're doing to try it.

- 99% of the ~700 crates were done compiling in about a minute or 2 - RocksDB (a C++ dependency) was 2 minutes by itself - And then it took 10 minutes (ten!) just for the final binary at the end.

That's not normal for Rust code at all. Even large ones like Servo or Rustc or Zed.

UPDATE2: turns out they have LTO enabled by default. Disabling that brings the compile time down to 7 minutes. But that's still really unexpectedly slow.

Go doesn’t have sum types as a first class primitive.

I've hit compiler bugs that behave this way. Here's one from an LLVM upgrade [1]. The test case I discovered apparently took over 20 minutes to compile, up from 26 seconds on stable! Their value tracking algorithm was accidentally quadratic.

[1]: https://github.com/rust-lang/rust/issues/137909

I really like how flix.dev looks, but there's always a little nagging at the back of my head that something like rust will always produce more performant software.

This!

This apart from build times is my biggest request for the language.

Nopanic, nomalloc, etc.

Only the client parts. And only the client parts its actually using. JMAP clients can be much simpler than servers. A JMAP server needs the whole protocol. JMAP clients only need to implement the parts they use. Servers also need to parse email message envelopes - which is way more difficult to do correctly than people think. JMAP clients can just use pre-parsed messages from the server.

Anyway, the code is here if you wanna take a look:

https://github.com/josephg/claude-mail

Claude put its JMAP API wrapper code in a child crate (confusingly also called jmap-client).

It's not the best tool for the job for a lot of things, but if the LLMs make writing it as fast as anything else - whelp, I can't see any reason not to do it in Rust.

If you get any language outputs "for free", Rust is the way to go.

I've been using Claude to go ridiculously fast in Rust recently. In the pre-LLM years I wrote a lot of Rust, but it definitely was a slow to author language. Claude helps me produce it as fast as I can think. I spend most of my time reviewing the code and making small fixes and refactors. It's great.

But can also define a closed set of types, perfectly satisfying "sum types".

> This enables different syntax, like the match expression to be used, in which you exhaustively list all the variants.

Go does not provide this out of the box, but that is not prerequisite for sum types. The mathematical theory says nothing about "the compiler must produce an error if the user doesn't match call cases". There is sufficient information provided by the sum types if you wish to add this to your build chain yourself, of course.

We're working on that and it should get better soonish. We're working on shared caches, as well as pruning of old cached builds of dependencies that are unlikely to be reused in a future build.

Maybe I'm misunderstanding what you mean. Can you give me an example? How would you write a Result type in Go? (Result is defined as either Ok(val) or Err(err))