A drum I've been banging increasingly often recently is that having friction and time to work ideas over in your mind adds huge amounts of value. Vibe coded projects have this very specific, well, vibe to them where you can clearly see that the lack of time to digest has allowed the person to not challenge their own worst impulses. You can see it in the feature bloat, the lack of depth and polish in core features and the wild asides you tend to talk yourself out of still on display.

>Ideas have always been cheap. Now, proof of concepts have become as cheap. I don’t care about your Show HN unless you have spent a month on it.

Yes. I'm as pro-AI coding as people come, but this is the part that bugs me too. If you whip something useful up in a weekend, great!

But you don't have to present it like you are building an actual product. It's fine if no one else knows about it. Because the fact is, most people don't care, even before AI. Building for yourself is fine.

It’s the same reason why everyone doesn’t wanna read LLM generated blog posts. The agreement used to be generally that you would spend more time writing than I would have to spend reading and when the agreement changes the quality changes as well.

I wonder how much they spend on this rewrite, in tokens and $ using commercial pricing

Maybe those ideas aren’t so brilliant.

> They get abandoned because they get generated on a whim.

I think it's more than that. These greenfield projects are actually things that, up until the inception of LLMs, they were not worth creating.

With AI code assistants, the cost of developing them is lower, but in the end you still end up with a project that no one bothered to create.

Keep in mind logic bug that ai makes are extremely hard and expensive to fix as the clanker needs to parse thousand and thousands of lines of text every prompt while a human tries to explain what it's obviously doing wrong.

I hate ai so much because its so easy to generate quick slop that "appears" functional.

> Just search "segfault" on the Zig issue tracker and you'll see why people are starting to be skeptical of the future utility of such a language in the face of something like Rust.

Zig has 110 open "segfault" issues [1] versus Rust's 175 open "segfault" issues [2]. So, by your logic, Rust is also bad.

edit: I was just trying to point out that the parent's "just search segfault" argument is lazy. Also, Zig is still in beta.

[1] https://codeberg.org/ziglang/zig/issues?state=open&type=all&...

[2] https://github.com/rust-lang/rust/issues?q=is%3Aissue%20stat...

I program C for my day-job.

I see Rust encroaching in proposed transitions. It may even happen. That said, it is a poor match for it compared to something like Zig (or Odin). It's hard to make the new Rust code use existing allocator abstractions (so now you have two systems doling out memory, how do you reliably free composite objects with memory from both? How do they share?) and you increasingly have to either abandon any actual benefits of the borrow-checker, or invest increasingly heavily into sufficiently fat bindings to wrap your existing C/C++ in a way where the borrow-checker can assist you. That's before we consider the complexity of the language - I'd doubt a seasoned C programmer has much trouble deciphering Zig or Odin FFI bindings, but in the case of Rust? Yes, there is real friction.

Also if you really value predictable- and higher performance, being in more in control of memory allocations and cleanup is preferable. This is the direction both Zig and Odin cater to.

If you asked me what solves the most issues without adding too many new liabilities, I'd say Zig (or Odin). It would simply be much, much easier to transition a C codebase to either, and either would bring a much improved stdlib with pluggable allocators capable of leak-detection etc.

I would say the flagship Zig project is TigerBeetle, not Bun.

I used to think there's a good niche for "better C" - and that Zig was the one language angling for that. A language that can be used in the same contexts as C, to do the same things as C code, in very much the same way, but with some modern features, some stronger guarantees and some helpful syntactic sugar? A welcome thing for embedded development.

On the other end, Rust to me felt like "better C++" - outside the embedded niche, aimed at complex multithreaded code that has to combine high performance with not catching on fire because someone fucked up concurrency once again.

But the main issue I had with Rust - that it's frankly a bitch to write, nearing Go levels of awful, only worthwhile if its paradigm is buying you a lot - is diminished if it's an LLM that's doing the bulk of the line to line writing.

And, on the other end, C's warts, footguns and ancient quirks also matter less if you have an LLM plow through it.

So, the niche for Zig does seem to be shrinking. The window for it to establish itself might be genuinely closing now. Which is a shame, because I like the idea of having "better C" a lot. But all of this drama sure isn't helping it gain traction.

> I think the Zig people are really just concerned that maybe Zig itself is a DOA language because it doesn't offer enough over C for any serious use and their flagship project has now abandoned it.

You hit the nail on the head there. Zig is 10 years old now and it’s pretty clear that the industry isn’t biting, compared to the behemoth that is Rust. Between Rust, C, and C++ there is very little room for another language with a woefully incomplete library ecosystem to establish itself.

A true competitor would need to offer genuine extra value, such as dependent types or other formal verification features, to carve out a niche.

Yeah, I mean … as a C++ dev I have those same existential “what’s the point” questions about Zig.

I would go further and say that anyone who doesn't immediately identify this either isn't thinking clearly about this, or is intentionally ignoring it. I have no horse in this race AT ALL and this is _obviously_ the advantage.

> clear well-scoped unsafe boundaries

This is not done by blindly porting Zig code 1:1 and calling it a day. You do have to make conscious decisions about code architecture to manage Unsafe code, since you need choose the right invariants for your Safe Rust code to conform inside the module (Note that unsafe pollutes the whole module containing it, not just the code inside the unsafe block!)

> making sure the JIT doesn't emit anything broken or naughty is completely outside the scope of Rust.

It's also outside the scope of the project if they're using Webkit's engine for that part. Which means Bun itself isn't a JIT, it's all the stuff built around the Webkit JIT, so whether or not Rust is useful for the JIT is entirely immaterial to the question of if Bun would benefit from Rust.

I think their original post lays out the benefits pretty well. I think the realization of some of these benefits is debatable (for example, they probably could have made their existing Zig code faster), but others are straightforward (like having fewer crashes because more of your code is provably “safe” in Rust terms).

(I think wrapping a large, complex C/C++ codebase is where Rust often shines, if you build the right joiner abstractions. PyO3 is a really great example of that.)

It's funny, but I think the article is showing it's age. It's no longer true.

In hindsight having automated auto complete rewriting your code base wasn't something on 2000's radar.

Now switching from language to language is much easier. Just for Rust, there was Ladybird and Bun complete rewrite.

Context matters. Big announcements and uninformed blog posts can kill your momentum.

I still remember the Twitter dev blog where they abandoned Ruby/Rails and the damage that did. It turned out Twitter was doing a lot of stupid things and there was a mismatch of tools and their goals. They loudly blamed the tools and people ate it up because Twitter was big, visible and adored at the time. Their conclusions bypassed most people’s ability to reason.

Anthropic/Bun are big, visible and adored…