https://codeberg.org/GramEditor/gram/releases/tag/1.0.0

The binary release for Linux is a bit rough, there's an `install.sh` script in the repo which can install the tarball for you. For the next release there will be flatpaks, .deb and .rpm available.

Sure, I definitely will not throw projects like Zig into that bucket, and I don't actually think Bun is vibe-coded. At least that _used_ to be true, we'll see I guess...

Don't read a snarky comment so literally ;)

This is just completely insane. We went through more than a decade of performance competition in the JS VM space, and the _only_ justification that Google had for creating V8 was performance.

> The V8 engine was first introduced by Google in 2008, coinciding with the launch of the Google Chrome web browser. At the time, web applications were becoming increasingly complex, and there was a growing need for a faster, more efficient JavaScript engine. Google recognized this need and set out to create an engine that could significantly improve JavaScript performance.

I guess this is the time we live in. Vibe-coded projects get bought by vibe-coded companies and are congratulated in vibe-coded comments.

https://github.com/oven-sh/bun/pull/24578

So far, someone from the bun team has left a bunch of comments like

> Poor quality code

...and all the tests still seem to be failing. I looked through the code that the bot had generated and to me (who to be fair is not familiar with the bun codebase) it looks like total dogshit.

But hey, maybe it'll get there eventually. I don't envy "taylordotfish" and the other bot-herders working at Oven though, and I hope they get a nice payout as part of this sale.

Any memory management solution will run out of space and terminate unless there is literally infinite memory available.

But I guess hash tables is what people think about when thinking about what makes something a lisp or not.

I don't find it too hard to figure out what he meant - he doesn't want to you change the case style of procedure calls, but he _does_ want you to remove redundant namespacing as in the CURL prefix.

Maybe you could have looked at some other vendored libraries to see how they handled things like constant naming and other formatting?

https://anthonymoser.github.io/writing/ai/haterdom/2025/08/2...

I haven't seen the conversations he is referring to, he didn't link to or quote anything. It's just some general complaint about Bill, which may be true but who cares?

A couple of clarifications, though: I did mean unsafe rust, not the safe subset. No need to get rude!

Second of all, I am of course not under the illusion that Odin prevents use-after-free (and thus, technically, it does allow UB I guess). I just don't think Bill is either. So clearly he doesn't mean UB by the same definition as you do.

_My_ use of UB has always been in the context of what a compiler will do during optimization, and the discussion I've seen in the context of C compilers is that they perform optimizations that remove code or change code in surprising ways because the way the code was written technically resulted in UB. But I'm neither a spec writer or a compiler author, so I don't really care that much about the actual definition of the term.

Anyway, best of luck in convincing Bill to use the term correctly as well! I won't mention UB when talking about the benefits of Odin in the future. :)

"He was mean to me once" isn't that interesting, especially without anything concrete to back it up.

My take on what he is saying is that the odin compiler won't try to exploit that there is some behavior which is platform-defined or only knowable at runtime to do aggressive optimizations etc.

https://xcancel.com/TheGingerBill/status/1495004577531367425

To point out that use after free is possible in Odin is not really a gotcha unless you really are just arguing semantics. That's by design, just like use after free is possible in C or C++ or Rust too.