| ▲ | petcat 3 hours ago |
| > Now if that's further migrated to safe Rust, put into production & gathered feedback from lots of users, yes then you have something. Obviously they have to start somewhere if they want to get to safe rust with a considerable degree of battle testing. So they decided to start with just a transliteration and go from there. 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. 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. |
|
| ▲ | shirol 2 hours ago | parent | next [-] |
| > 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... |
| |
| ▲ | post-it 2 hours ago | parent | next [-] | | You're not seriously out here posting raw numbers without considering the base rate are you | | |
| ▲ | jadbox an hour ago | parent [-] | | You're not seriously posting about base rates without any form of agreeable evidence around such base rates? |
| |
| ▲ | brookst an hour ago | parent | prev | next [-] | | Yeah, well, my not-yet-written language has zero segfault issues raised, so it’s clearly superior to both Zig and Rust. I really need to get around to writing it because obviously it’s a much better design. | |
| ▲ | Ygg2 an hour ago | parent | prev | next [-] | | Without base rate you're comparing #X in a city vs #Y in a continent and drawing conclusions from that. It's not even wrong. | | |
| ▲ | shirol 21 minutes ago | parent [-] | | You’re literally agreeing that the parent’s argument is bad. I was just applying his logic, and I didn't draw any conclusions. | | |
| ▲ | Ygg2 7 minutes ago | parent [-] | | No. I just think you're taking judge by number of segfaults out of context. That said, I wrote this before the edit. |
|
| |
| ▲ | VWWHFSfQ 2 hours ago | parent | prev [-] | | It's a bad metric, but also Zig didn't migrate all of their issues from GitHub. Run the same count on GitHub and you'll see the full picture |
|
|
| ▲ | pseudony 17 minutes ago | parent | prev | next [-] |
| 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. |
|
| ▲ | cfiggers an hour ago | parent | prev | next [-] |
| I would say the flagship Zig project is TigerBeetle, not Bun. |
| |
| ▲ | eatonphil an hour ago | parent | next [-] | | If TigerBeetle is the Zig flagship then Zig is untenable for almost any team, because Tiger Style is untenable for almost any team. No, I think that Tiger Style makes Zig mostly unimportant. On the other hand, as a corporate backer for Zig, TigerBeetle is definitely a big deal. But in terms of exemplary and copyable projects in the ecosystem I would think something like Ghostty is the safer label for "flagship". | | | |
| ▲ | rasmus1610 an hour ago | parent | prev | next [-] | | some may argue for ghostty but yeah :) | |
| ▲ | fridder 20 minutes ago | parent | prev [-] | | or libghostty |
|
|
| ▲ | ACCount37 2 hours ago | parent | prev | next [-] |
| 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. |
| |
| ▲ | ctvo 2 hours ago | parent | next [-] | | I wouldn’t write Zig off yet. The faster compilation time is a giant moat. Depending on how LLM usage evolves it could be what ends up mattering. | | |
| ▲ | ACCount37 an hour ago | parent | next [-] | | I'm not writing Zig off myself. I would prefer if it succeeded. But the outlook is: not good, in my eyes. Pre-2022, Zig was doing decently, but not particularly well. It didn't have Rust level of enthusiasts and ambassadors (love them or hate them, they did succeed in driving considerable Rust adoption), it didn't have a major corpo backing it, it had too much API instability to be truly relied on. Picking a stupid fight with Bun/Anthropic and doubling down on it isn't helping with any of that. I also don't think compilation time makes for a good moat for agentic AI coding? Like, sure, less time wasted = better. But LLMs don't perceive time as humans do. They don't have the human "40 minutes of compile time = a hard forced context switch" quirk. The state of an LLM agent is as "stale" after a 40 minute build as it is after a 40 second build - no attention penalty for getting distracted. There is a hard "wall clock time" iteration speed penalty, but I expect LLM coding to be more agentic, not less. In which case a single sub-agent stalling might not matter much? The orchestrator AI would just keep doing other things, and come back to the stalled sub-agent when it's ready. Once again: long stalls hurt the worst if they route through human attention. The less human attention there is in the system the cheaper they are. | | |
| ▲ | neutronicus an hour ago | parent [-] | | A day or two ago someone posted about abandoning Haskell because compilation times had become a bottleneck with Agents. FWIW |
| |
| ▲ | pmarreck 2 hours ago | parent | prev [-] | | also, the fact that you can compile to any target from any target |
| |
| ▲ | Shorel an hour ago | parent | prev | next [-] | | You write Better C and the first thing I think about is D-lang. | |
| ▲ | AnimalMuppet an hour ago | parent | prev | next [-] | | What makes go so awful to write? My impression was that Rust was hard, at least until you understand the borrow checker, and go was pretty easy. (This is my impression from outside, that is, I don't actually use either language.) | | |
| ▲ | calgoo 4 minutes ago | parent [-] | | Not OP, but normally people complain because its boring, but these days, have an LLM generate all the template coding, the json mappings or whatever people dont like. Personally, with all the compromised NPM and PiP packages, when i PoC / vibe code something, i tend to use Golang very few external packages (native sqlite) and thats it. Also really nice to be able to package up the App and all related files into 1 binary. |
| |
| ▲ | olzhasar an hour ago | parent | prev [-] | | A typical comment on Hackernews nowadays: I used to think that there's a a room for better C -> Some unrelated complains about Rust and Go -> C has footguns, but they don't matter that much because I choose to not write my code myself anymore -> Therefore there's no room for better C. |
|
|
| ▲ | p-e-w 2 hours ago | parent | prev | next [-] |
| > 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. |
| |
| ▲ | cfiggers an hour ago | parent | next [-] | | > it’s pretty clear that the industry isn’t biting Zig isn't finished yet (they still have not released a v1.0). They're still iterating on the language itself and want the flexibility to make backwards-incompatible changes while they do so. So in a sense, they have not yet asked anybody in mainstream industry to "bite." After v1.0, when there's an understanding of stability and ongoing language support, industry adoption or lack thereof might become a relevant metric for measuring the project's health. But right now that's not relevant at all. | |
| ▲ | hatefulheart an hour ago | parent | prev [-] | | Python was invented two years before Java and didn’t move the needle until the mid 2010s. You are the typical mark for hype cycles. Get a clue will you. | | |
|
|
| ▲ | neutronicus an hour ago | parent | prev [-] |
| Yeah, I mean … as a C++ dev I have those same existential “what’s the point” questions about Zig. |