6 ms·

> 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

by petcat 3mo 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.

ACCount37 3mo ago
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 3mo ago
  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.
  - pmarreck 3mo ago
    also, the fact that you can compile to any target from any target
  - ACCount37 3mo ago
    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 3mo ago
      A day or two ago someone posted about abandoning Haskell because compilation times had become a bottleneck with Agents. FWIW
      - robocat 3mo ago
        HN discussion: https://news.ycombinator.com/item?id=48859673 https://news.ycombinator.com/item?id=48859673 1 minute skim of that surfaces aviaviavi's comment on moving to Python not Rust: Main factors were (roughly in order): - None of us are experts in Rust, and we're all solid at Python. - Rust felt like an under-correction for what we wanted (get all friction in front of the LLM out of the way). - Our high-performance stuff is not being migrated at this time (Scarf Gateway), so we're just talking about basic CRUD backends here. Basically any language will work
- Shorel 3mo ago
  You write Better C and the first thing I think about is D-lang.
  - dnautics 3mo ago
    you write D-lang and all I can think of is too much nonsense you have to tell a team (an LLM?) to avoid the temptation to use.
    - Shorel 3mo ago
      Fall into it. I am rewriting all my projects in D-lang. It is really that good. Particularly when compared to Zig and Rust.
- olzhasar 3mo ago
  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.
- AnimalMuppet 3mo ago
  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 3mo ago
    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.
- renox 3mo ago
  > And, on the other end, C's warts, footguns and ancient quirks also matter less if you have an LLM plow through it. 'plow through it's?? An LLM can definitedly fall into these traps! Happened to me a few months ago, I couldn't believe that an LLM would generate a use-after-free in not-so-complex code but it did.. Newer LLM seems better now but buyer beware!
  - agentultra 3mo ago
    You still need an expert human to drive an LLM. And even then, with C, you need to be very careful. LLM’s generate lots of code. Code that has no obvious errors in it. The kind humans aren’t good at picking up on their own. You need other tooling in place to support human experts to prevent this kind of stuff as you would in a non-LLM contribution.
- wren6991 3mo ago
  > And, on the other end, C's warts, footguns and ancient quirks also matter less if you have an LLM plow through it. Warts and ancient quirks, I can kind of see, but in what way have LLMs solved the footguns?
  - ACCount37 3mo ago
    Mostly, by having enough diligence and attention to avoid a lot of the common ones. By now, if we're pitting a top of the line coding LLM against a B-tier programmer throwing something together in a hurry, I would expect the latter to shot more foot, and not by a narrow margin. Even those who know better don't always do better - for a human, "fucks given" is a painfully finite resource.
- SwellJoe 3mo ago
  "Rust - that it's frankly a bitch to write, nearing Go levels of awful" Go, awful? That's wild. I find Go to be maybe the most pleasant language I've ever used. It's just delightful for its niche (web services, system tools, things of that nature), I've never seen anything better.
p-e-w 3mo ago
> 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.
- hatefulheart 3mo ago
  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.
  - joshuamorton 3mo ago
    Python was being used as a teaching language at flagship universities in the mid 2000s.
    - hatefulheart 3mo ago
      Amazing! So was Scheme.
      - redsocksfan45 3mo ago
        [dead]
  - schaefer 3mo ago
    > Python ... didn’t move the needle until the mid 2010s. Nope. I was on a Python project in 2006 and earned a paycheck doing so.
  - baq 3mo ago
    I was getting paid doing django in 2005-2006
shirol 3mo ago
> 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&labels=&milestone=0&project=0&assignee=0&poster=0&sort=relevance&q=segfault https://codeberg.org/ziglang/zig/issues?state=open&type=all&... [2] https://github.com/rust-lang/rust/issues?q=is%3Aissue%20state%3Aopen%20segfault https://github.com/rust-lang/rust/issues?q=is%3Aissue%20stat...
- post-it 3mo ago
  You're not seriously out here posting raw numbers without considering the base rate are you
  - jadbox 3mo ago
    You're not seriously posting about base rates without any form of agreeable evidence around such base rates?
  - baranul 3mo ago
    I think the open to close ratio needs to be provided in any such comparison. It would arguably give a better indication of which project is doing a better job at addressing incoming user issues and bug fixes.
- VWWHFSfQ 3mo ago
  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
- brookst 3mo ago
  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.
cfiggers 3mo ago
I would say the flagship Zig project is TigerBeetle, not Bun.
- rasmus1610 3mo ago
  some may argue for ghostty but yeah :)
- eatonphil 3mo ago
  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 imitable projects in the ecosystem I would think something like Ghostty is the safer label for "flagship".
  - deleted 3mo ago
    [deleted]
  - z0ltan 3mo ago
    [dead]
  - GuB-42 3mo ago
    TigerBeetle is interesting because even though something like TigerStyle is unusual for a database, it is very much at home for embedded systems. In fact we could summarize TigerBeetle as "the financial database developed like embedded software". Determinism is a cornerstone of critical software like in avionics, and naturally, dynamic allocation is forbidden, as in TigerStyle. So even though it is not obvious, TigerBeetle represents one of Zig biggest strengths: embedded systems.
- fridder 3mo ago
  or libghostty
- Aurornis 3mo ago
  TigerBeetle has a unique static memory allocation strategy at launch time. It’s a strategy that sidesteps a lot of memory management issues but only works for very specific use cases. Their success with this strategy isn’t portable to most other projects. I think they really need more traditional flagship projects that generalize to typical memory management use cases. The way the conversation keeps coming back to TigerBeetle as a success story isn’t helpful to anyone trying to evaluate the memory management angle.
neutronicus 3mo ago
Yeah, I mean … as a C++ dev I have those same existential “what’s the point” questions about Zig.
- araoz 3mo ago
  AFAIK zig is not trying to be "better C++" (that is Rust), zig is more like "better C". a ergonomic low level lang with very little abstractions. zig explicitly doesn't want to be better C++ or rust
  - neutronicus 3mo ago
    Oh, I get that. That’s what I’m saying. I hear “Better C” and my initial reaction is “what’s the point”. Like, why would you aim for “Worse C++”? I mean, compile times. That’s fair.
    - pjmlp 3mo ago
      Even those aren't that bad, when using C++20 modules, coupled with binary libraries. Granted we "aren't modules" yet, unless being on latest compilers with msbuild/cmake/ninja tooling.
      - neutronicus 3mo ago
        Perhaps theoretically, with good practice, but at my job it’s fucking brutal. But to your larger point I would much rather work on improving that than let it drive me back to C fetishism.
pseudony 3mo ago
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.
- Xirdus 3mo ago
  If you literally want one and only one allocator instead of the Rust's built-in one, that's been supported for years[1]. Almost 8 years, to be precise. It's very easy to implement and works with the entire standard library and all its abstractions, and almost every 3rd party library will support it out of the box too (except the ones that go out of their way not to support it for some reason). Borrow checking and all the other safety features are still fully supported. Now, mixing different allocators is a different beast, and much less supported. But it sounds like you are very much not interested in this use case, right? [1] https://doc.rust-lang.org/std/alloc/index.html https://doc.rust-lang.org/std/alloc/index.html
- msdz 3mo ago
  If you allow, I’m curious: If you felt familiar with the language just as much as with C/Zig/Odin, would you prefer Rust for a completely greenfield project that requires no C interop (or none more detailed than say providing a general ABI)?
Tade0 3mo ago
> So they decided to start with just a transliteration and go from there. Huge problem with this is that typically safe, idiomatic Rust looks nothing like unsafe Rust.
dnautics 3mo ago
> the Zig people are really just concerned that maybe Zig itself is a DOA language because it doesn't offer enough over C I don't think anyone who actually uses zig thinks "it doesn't offer enough over C". Removing #define alone would have been worth it.
- locknitpicker 3mo ago
  > Removing #define alone would have been worth it. If you reach out to any project manager and pitch the idea to rewrite a whole app from scratch because you want to get rid of #define, first you will be laught out of the room and second they will reach out to HR to get a PIP going because whatever the hiring bar they used to hire a developer you clearly are not meeting it.
  - dnautics 3mo ago
    nice strawman. we're obviously talking about greenfield developmen, and then, probably not in corposlop environments.
alexrp 3mo ago
> 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 I promise you, hand on heart, that literally no one on the Zig core team is wasting their time on thoughts like this. > and their flagship project has now abandoned it. Quoting Andrew: > So, when the Anthropic aquisition finally happened, we at ZSF breathed a sigh of relief. When the donation silently stopped, our bank account was ready for it. When they neither canceled their monthly meeting with us, nor showed up, we were not surprised. The relationship was over. I advise you to take this paragraph at face value. Again, I promise you that it is the truth.

by petcat 3mo ago

ACCount37 3mo ago

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 3mo ago
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.
- pmarreck 3mo ago
  also, the fact that you can compile to any target from any target
- ACCount37 3mo ago
  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 3mo ago
    A day or two ago someone posted about abandoning Haskell because compilation times had become a bottleneck with Agents. FWIW
    - robocat 3mo ago
      HN discussion: https://news.ycombinator.com/item?id=48859673 https://news.ycombinator.com/item?id=48859673 1 minute skim of that surfaces aviaviavi's comment on moving to Python not Rust: Main factors were (roughly in order): - None of us are experts in Rust, and we're all solid at Python. - Rust felt like an under-correction for what we wanted (get all friction in front of the LLM out of the way). - Our high-performance stuff is not being migrated at this time (Scarf Gateway), so we're just talking about basic CRUD backends here. Basically any language will work
Shorel 3mo ago
You write Better C and the first thing I think about is D-lang.
- dnautics 3mo ago
  you write D-lang and all I can think of is too much nonsense you have to tell a team (an LLM?) to avoid the temptation to use.
  - Shorel 3mo ago
    Fall into it. I am rewriting all my projects in D-lang. It is really that good. Particularly when compared to Zig and Rust.
olzhasar 3mo ago
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.
AnimalMuppet 3mo ago
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 3mo ago
  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.
renox 3mo ago
> And, on the other end, C's warts, footguns and ancient quirks also matter less if you have an LLM plow through it. 'plow through it's?? An LLM can definitedly fall into these traps! Happened to me a few months ago, I couldn't believe that an LLM would generate a use-after-free in not-so-complex code but it did.. Newer LLM seems better now but buyer beware!
- agentultra 3mo ago
  You still need an expert human to drive an LLM. And even then, with C, you need to be very careful. LLM’s generate lots of code. Code that has no obvious errors in it. The kind humans aren’t good at picking up on their own. You need other tooling in place to support human experts to prevent this kind of stuff as you would in a non-LLM contribution.
wren6991 3mo ago
> And, on the other end, C's warts, footguns and ancient quirks also matter less if you have an LLM plow through it. Warts and ancient quirks, I can kind of see, but in what way have LLMs solved the footguns?
- ACCount37 3mo ago
  Mostly, by having enough diligence and attention to avoid a lot of the common ones. By now, if we're pitting a top of the line coding LLM against a B-tier programmer throwing something together in a hurry, I would expect the latter to shot more foot, and not by a narrow margin. Even those who know better don't always do better - for a human, "fucks given" is a painfully finite resource.
SwellJoe 3mo ago
"Rust - that it's frankly a bitch to write, nearing Go levels of awful" Go, awful? That's wild. I find Go to be maybe the most pleasant language I've ever used. It's just delightful for its niche (web services, system tools, things of that nature), I've never seen anything better.

p-e-w 3mo ago

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

hatefulheart 3mo ago
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.
- joshuamorton 3mo ago
  Python was being used as a teaching language at flagship universities in the mid 2000s.
  - hatefulheart 3mo ago
    Amazing! So was Scheme.
    - redsocksfan45 3mo ago
      [dead]
- schaefer 3mo ago
  > Python ... didn’t move the needle until the mid 2010s. Nope. I was on a Python project in 2006 and earned a paycheck doing so.
- baq 3mo ago
  I was getting paid doing django in 2005-2006

shirol 3mo ago

> 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&labels=&milestone=0&project=0&assignee=0&poster=0&sort=relevance&q=segfault https://codeberg.org/ziglang/zig/issues?state=open&type=all&... [2] https://github.com/rust-lang/rust/issues?q=is%3Aissue%20state%3Aopen%20segfault https://github.com/rust-lang/rust/issues?q=is%3Aissue%20stat...

post-it 3mo ago
You're not seriously out here posting raw numbers without considering the base rate are you
- jadbox 3mo ago
  You're not seriously posting about base rates without any form of agreeable evidence around such base rates?
- baranul 3mo ago
  I think the open to close ratio needs to be provided in any such comparison. It would arguably give a better indication of which project is doing a better job at addressing incoming user issues and bug fixes.
VWWHFSfQ 3mo ago
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
brookst 3mo ago
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.

cfiggers 3mo ago

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

rasmus1610 3mo ago
some may argue for ghostty but yeah :)
eatonphil 3mo ago
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 imitable projects in the ecosystem I would think something like Ghostty is the safer label for "flagship".
- deleted 3mo ago
  [deleted]
- z0ltan 3mo ago
  [dead]
- GuB-42 3mo ago
  TigerBeetle is interesting because even though something like TigerStyle is unusual for a database, it is very much at home for embedded systems. In fact we could summarize TigerBeetle as "the financial database developed like embedded software". Determinism is a cornerstone of critical software like in avionics, and naturally, dynamic allocation is forbidden, as in TigerStyle. So even though it is not obvious, TigerBeetle represents one of Zig biggest strengths: embedded systems.
fridder 3mo ago
or libghostty
Aurornis 3mo ago
TigerBeetle has a unique static memory allocation strategy at launch time. It’s a strategy that sidesteps a lot of memory management issues but only works for very specific use cases. Their success with this strategy isn’t portable to most other projects. I think they really need more traditional flagship projects that generalize to typical memory management use cases. The way the conversation keeps coming back to TigerBeetle as a success story isn’t helpful to anyone trying to evaluate the memory management angle.

neutronicus 3mo ago

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

araoz 3mo ago
AFAIK zig is not trying to be "better C++" (that is Rust), zig is more like "better C". a ergonomic low level lang with very little abstractions. zig explicitly doesn't want to be better C++ or rust
- neutronicus 3mo ago
  Oh, I get that. That’s what I’m saying. I hear “Better C” and my initial reaction is “what’s the point”. Like, why would you aim for “Worse C++”? I mean, compile times. That’s fair.
  - pjmlp 3mo ago
    Even those aren't that bad, when using C++20 modules, coupled with binary libraries. Granted we "aren't modules" yet, unless being on latest compilers with msbuild/cmake/ninja tooling.
    - neutronicus 3mo ago
      Perhaps theoretically, with good practice, but at my job it’s fucking brutal. But to your larger point I would much rather work on improving that than let it drive me back to C fetishism.

pseudony 3mo ago

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.

Xirdus 3mo ago
If you literally want one and only one allocator instead of the Rust's built-in one, that's been supported for years[1]. Almost 8 years, to be precise. It's very easy to implement and works with the entire standard library and all its abstractions, and almost every 3rd party library will support it out of the box too (except the ones that go out of their way not to support it for some reason). Borrow checking and all the other safety features are still fully supported. Now, mixing different allocators is a different beast, and much less supported. But it sounds like you are very much not interested in this use case, right? [1] https://doc.rust-lang.org/std/alloc/index.html https://doc.rust-lang.org/std/alloc/index.html
msdz 3mo ago
If you allow, I’m curious: If you felt familiar with the language just as much as with C/Zig/Odin, would you prefer Rust for a completely greenfield project that requires no C interop (or none more detailed than say providing a general ABI)?

Tade0 3mo ago

> So they decided to start with just a transliteration and go from there. Huge problem with this is that typically safe, idiomatic Rust looks nothing like unsafe Rust.

dnautics 3mo ago

> the Zig people are really just concerned that maybe Zig itself is a DOA language because it doesn't offer enough over C I don't think anyone who actually uses zig thinks "it doesn't offer enough over C". Removing #define alone would have been worth it.

locknitpicker 3mo ago
> Removing #define alone would have been worth it. If you reach out to any project manager and pitch the idea to rewrite a whole app from scratch because you want to get rid of #define, first you will be laught out of the room and second they will reach out to HR to get a PIP going because whatever the hiring bar they used to hire a developer you clearly are not meeting it.
- dnautics 3mo ago
  nice strawman. we're obviously talking about greenfield developmen, and then, probably not in corposlop environments.

alexrp 3mo ago

> 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 I promise you, hand on heart, that literally no one on the Zig core team is wasting their time on thoughts like this. > and their flagship project has now abandoned it. Quoting Andrew: > So, when the Anthropic aquisition finally happened, we at ZSF breathed a sigh of relief. When the donation silently stopped, our bank account was ready for it. When they neither canceled their monthly meeting with us, nor showed up, we were not surprised. The relationship was over. I advise you to take this paragraph at face value. Again, I promise you that it is the truth.