Live data from Hacker News

Ladybird adopts Rust, with help from AI

ladybird.org

541–550 of 731 posts

Re: Ladybird adopts Rust, with help from AI

#541

Earlier quoted context omitted.

A mitigating factor in this case is the C++ and Rust are both multi-paradigm languages. You can quite reasonably represent most C++ patterns in Rust, even if it might not be quite how you'd write Rust in the first place.

In addition, C++ and Rust are very, very similar languages. Almost everything in C++ translates easily, including low level stuff and template shenanigans. There's only a few "oh shit there's no analog" things, like template specialization or virtual inheritance. Out of all the languages rust takes inspiration from, id rank C++ at the top of the list.

Strong disagree. Rust copied C++ syntax to avoid looking weird to C++ programmers, but the similarity is skin deep. C can be tamed, because it's mostly a subset of Rust, but C++ idioms are a death from papercuts.

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.

Re: Ladybird adopts Rust, with help from AI

#542

Earlier quoted context omitted.

Same here. I had Claude write me a web based RSS feed reader in Rust. It has some minor glitches I still need to iron out, but it works great, is fast as can be, and is easy on the eyes. https://github.com/AdrianVollmer/FluxFeed

Re "is fast as can be": in my experience generating C/Zig code via Codex, agent generated code is usually several multiples slower than hand optimized code.

Yeah, I’m sure my Claude generated email client could be even faster if I wrote it by hand. Modern computers can retire billions of instructions per second per core. All operations that aren’t downloading or processing gigabytes of data should be instant on modern computers.

Claude’s toy email client gets closer to the speed limit than Gmail does. Why is Gmail so slow? I have no idea.

Re: Ladybird adopts Rust, with help from AI

#543

Earlier quoted context omitted.

Also curious why would one be proud of having an LLM rewrite something that there is already a library for. I personally feel that proud LLM users boasting sounds as if they are on amphetamines.

It made a webmail client. Not a jmap library.

Not sure I understand, wouldn’t a webmail client in rust need client code like this or to use a library like this?

Re: Ladybird adopts Rust, with help from AI

#544
post #258

If it is this easy, surely the trend is Rust output being an intermediate pass of the LLM super compiler. A security subset if you will (like other kinds of optimization), it will move from Rust specs to some deeper level of analysis and output the final executable. Some brave souls will read the intermediate Rust output (just like people used to read the assembler output from compilers) but the LLM super compiler wi…

Do you seriously think LLMs will not just spam unsafe blocks in it like they do with any task ever?

Re: Ladybird adopts Rust, with help from AI

#545
post #438

Earlier quoted context omitted.

Using interface as it was designed to be used offers first-class sum types. Although not all interface use equates to sum types. But they're not tagged unions. I expect that is still where your confusion lies. Tagged unions and sum types are not equivalent. Tagged unions are a subset of sum types.

This may be a bit too pedantic, but I consider interface {} to be a way to do polymorphism via type classes. Interface defines an open class of types which implement some interface. Sum types are a type definition defining something as A or B. Not “anything that quacks like a duck”. But concretely “one of this or one of that”. This enables different syntax, like the match expression to be used, in which you exhaustiv…

> Interface defines an open class of types

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.

Re: Ladybird adopts Rust, with help from AI

#546

This will be another bad decision just like with Swift. From what I heard, Rust is notoriously bad at letting people define their own structure and instead beats you up until you satisfy the borrow checker. I think it'll make development slow and unpleasant. There are people out there who enjoy that, but it's not a fit for when you need to deliver a really huge codebase in reasonable time. I remember Andreas mentioni…

Maybe, but will they have to fight with borrow checker for doing some other than (the very OOP) DOM components? They'll obviously use both for a long time in the future, so more functional places can get Rust, while more OOP places can benefit from C++

Re: Ladybird adopts Rust, with help from AI

#548

Earlier quoted context omitted.

Rust is the final language. Defect free. Immaculate types. Safe. Ergonomic. Beautiful to read. AI is going to be writing a lot of Rust. The final arguments of "rust is hard to write" are going to quiet down. This makes it even more accessible.

> Rust is the final language. > Defect free. I am an upstream developer on the Rust Project (lang, library, cargo, others), and obviously a big fan of Rust. This kind of advocacy doesn't help us, and in fact makes our jobs harder , because for some people this kind of advocacy is their main experience of people they assume are representative of Rust. Please take it down a notch. I think Rust is the best available lan…

I’d also add: as a lover of forward progress, I really hope rust isn’t the last good idea programming language designers have. I love rust. But there are dozens of things I find a bit frustrating. Unfortunately I don’t think I’m clever & motivated enough to write a whole new language to try to improve it. But I really hope someone else is!

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.

Re: Ladybird adopts Rust, with help from AI

#549

Earlier quoted context omitted.

I like "spec driven development" but I honestly don't care what you call it, just let me build things and leave me alone. :)

SDD is more like a subset. There are different ways to manage context in agentic engineering

> SDD

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

No wonder we’re called gatekeepers.

Re: Ladybird adopts Rust, with help from AI

#550

Looks like Andreas is a mighty fine engineer, but he's even better entrepreneur. Doesn't matter if intentional or not, but he managed to create and lead a rather visible passion project, attract many contributors and use that project's momentum to detach Ladybird into a separate endeavor with much more concrete financial prospects. The Jakt -> Swift -> Rust pivots look like the same thing on a different level. The in…

Yeah, this is glorified yak-shaving if we're being real. I'm not getting my hopes up for a true new browser
Post reply on HN