Live data from Hacker News

Ladybird adopts Rust, with help from AI

ladybird.org

681–690 of 731 posts

Re: Ladybird adopts Rust, with help from AI

#681

Earlier quoted context omitted.

Look at any HN thread that has a project that uses AI in any way, shape or form. People quickly remark that it is slop, without even reviewing the code. If that's not blind hatred of AI, I don't know what is. 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…

Vibe Coding is like porn for programmers. It probably isn't good for you, and you'd probably be better off actually doing the thing yourself, but it feels good and satisfies our desires for instant gratification

[flagged]

Re: Ladybird adopts Rust, with help from AI

#682

Earlier quoted context omitted.

UPDATE: tried compiling stalwart on my machine, and it took 14 minutes, with a really weird timing profile: - 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…

Disabling codegen units = 1 speeds up the compilation further. But it’s still too many dependencies and too slow. The binary is pretty huge too.

> But it’s still too many dependencies and too slow. The binary is pretty huge too.

Ah yes, my never-ending crusade to raise awareness that the cost of free (as in effort) dependencies is bloat.

You can make useful tools that are tiny and compile fast [1], but it takes a lot of effort; exactly what developers don't want to spend.

[1]: Like https://github.com/parasyte/hd -- And I wrote about one of the tricks that it uses: https://blog.kodewerx.org/2023/04/improving-build-times-for-...

Re: Ladybird adopts Rust, with help from AI

#683
post #300

The byte-for-byte identical output requirement is the smartest part of this whole thing. You basically get to run the old and new pipelines side by side and diff them, which means any bug in the translation is immediately caught. Way too many rewrites fail because people try to "improve" things during the port and end up chasing phantom bugs that might be in the old code, the new code, or just behavioral differences.…

That reminds me of the "Strangler Fig" pattern where you replace a service by first sending the requests to both the old and new implementation so you can compare their outputs. Then only when you're confident the new service functions as expected do you actually retire the old service.

Re: Ladybird adopts Rust, with help from AI

#684

Earlier quoted context omitted.

Disabling codegen units = 1 speeds up the compilation further. But it’s still too many dependencies and too slow. The binary is pretty huge too.

> But it’s still too many dependencies and too slow. I definitely agree that it's too slow. I just don't think the cause is "too many dependencies" because I've compiled Rust codebases with twice as many dependencies in half the time! It seems to produce a 94MB binary. So it may be partly that there are some very big dependencies. But the amount of compilation time that ends up in the top-level crate (even with LTO d…

I agree it's probably monomorphization (speculation without looking at it). Generic function parameters might be the root cause, but number of dependencies is a combinatorial multiplier.

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

Re: Ladybird adopts Rust, with help from AI

#685
post #339
post #329

Earlier quoted context omitted.

Agents are a "self-driving car for the mind". I don't enjoy or dislike driving, but lots of Americans love to drive. In the future they will lament their driving skills' decline.

We as the general population have consistently lost lots of skills from just 200 years back. Most likely we will not miss them (though coding used to be my hobby). Though if apocalypse happens and all of our built tech goes away, we are in for a serious survival issu.

Though if ~~apocalypse~~ war happens and all of our built tech goes away, we are in for a serious survival issue.

A lot closer than you think, too

Re: Ladybird adopts Rust, with help from AI

#686

> This is not becoming the main focus of the project. We will continue developing the engine in C++, and porting subsystems to Rust will be a sidetrack that runs for a long time. I don't like this bit. Wouldn't it be better to decide on a memory-safe language, and then commit to it by writing all new code in Rust, or whatever. This looks like doing double the work.

> Wouldn't it be better to decide on a memory-safe language, it is totally possible to use some strict subset of C++, which will be memory safe.

Only in theory. In practice it never happens like that. I mean, you think Google wouldn't use that for Chrome if they could?

Re: Ladybird adopts Rust, with help from AI

#687

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

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.

Working code talks.

Bullshit walks.

Re: Ladybird adopts Rust, with help from AI

#688

Earlier quoted context omitted.

Optimists will imagine it to one day be as taxing and thus as wasteful as firing up MS Paint. No that’s a stretch, but firing up a AAA game.

At least you (hopefully) get hours of entertainment from firing up an AAA game. Whereas generating vast amounts of code that you're never going to use has… some novelty value, I suppose. Luckily the novelty is going to wear off soon, I can't really see many people getting their daily happiness boost from making code machine say brrrrt straight to /dev/null. Even generating smut is a vastly more understandable (and va…

The bigger use for case for AAA games? Employment for highly talented artists, 3D modellers and sculptors, texture artists, sound and music artists, and even programmers.

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).

Re: Ladybird adopts Rust, with help from AI

#689

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

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.

If AI gets sufficiently good what will be the point of rust? I can just whip out some C code, tell the AI to make it safe (or just ask it if the code contains any undefined behavior), done.

Re: Ladybird adopts Rust, with help from AI

#690
post #660

Earlier quoted context omitted.

I guess to have the LLM write a lengthy descrption of why the code is bad? Otherwise it doesn't make sense to ask an LLM instead of typing // TODO: bad coding style.

Why do I want length? Good docs are terse. Longer isn't better. When I read docs I want to get to know the developer and what they're thinking. I want to see their vision, not their calculator. It's not about quantity, it's about quality. Just give your users and fellow devs some basic respect. I mean would you be okay with me just handing our conversation over to an LLM? Honestly I'd be insulted if you did that. Why…

I didn't say that length was a requirement, I was only thinking about why one would want to use an LLM to write a comment that is only a few words long, while the prompt might be as long as the (short version of the) comment itself.
Post reply on HN