zlacker

I'm not sure about exquisite and small.

Bun genuinely made me doubt my understanding of what good software engineering is. Just take a look at their code, here are a few examples:

- this hand-rolled JS parser of 24k dense, memory-unsafe lines: https://github.com/oven-sh/bun/blob/c42539b0bf5c067e3d085646... (this is a version from quite a while ago to exclude LLM impact)

- hand-rolled re-implementation of S3 directory listing that includes "parsing" XML via hard-coded substrings https://github.com/oven-sh/bun/blob/main/src/s3/list_objects...

- MIME parsing https://github.com/oven-sh/bun/blob/main/src/http/MimeType.z...

It goes completely contrary to a lot of what I think is good software engineering. There is very little reuse, everything is ad-hoc, NIH-heavy, verbose, seemingly fragile (there's a lot of memory manipulation interwoven with business logic!), with relatively few tests or assurances.

And yet it works on many levels: as a piece of software, as a project, as a business. Therefore, how can it be anything but good engineering? It fulfils its purpose.

I can also see why it's a very good fit for LLM-heavy workflows.

>>dgrosh+(OP)
I can't speak as much about the last two examples, but writing a giant parser file is pretty common in Zig from what I've seen. Here's Zig's own parser, for example[1]. I'm also not sure what you mean by memory unsafe, since all slices have bounds checks. It also looks like this uses an arena allocator, so lifetime tracking is pretty simple (dump everything onto the allocator, and copy over the result at the end). Granted, I could be misunderstanding the code, but that's the read I get of it.

[1] https://codeberg.org/ziglang/zig/src/commit/be9649f4ea5a32fd...

>>smj-ed+c4
It used to be arena-allocated but now it's using a different technique which I outlined in this talk: https://vimeo.com/649009599

>>smj-ed+c4
As it happens, the commit I linked fixes a segfault, which shouldn't normally happen in memory-safe code.