5 ms·

> I am so tired of worrying about & spending lots of time fixing memory leaks and crashes and stability issues. it would be so nice if the language provided mor

> I am so tired of worrying about & spending lots of time fixing memory leaks and crashes and stability issues. it would be so nice if the language provided more powerful tools for preventing these things. haven't used zig...(only used rust) but zig doesn't solve those problems?

josephg 5mo ago
Nope! Zig is like C in this regard. There’s no borrow checker. Managing memory is your responsibility. It gives you a few more tools than C - like a debug allocator, bounds checked array slices and so on. But it’s not a memory safe language like rust.
- dnautics 5mo ago
  It's not.. but im pretty sure it could be. could probably even take this (WIP) idea and bolt on a formal verifier pretty easily. https://github.com/ityonemo/clr https://github.com/ityonemo/clr
  - josephg 5mo ago
    It'd take more than that to match rust's borrow checker. Rust's borrow checker tracks lifetimes, and sometimes needs annotations in code to help it understand what you're actually trying to do. I suppose you could work around that by adding lifetime annotations in zig comments. Then you've have a language that's a lot like rust, but without an ecosystem of borrowck-safe libraries. And with worse ergonomics (rust knows when it can Drop). And rust can put noalias everywhere in emitted code. And you'd probably have worse error messages than the rust compiler emits. Its an interesting idea. But if you want static memory safety in a low level systems language, its probably much easier to just use rust.
    - dnautics 5mo ago
      > I suppose you could work around that by adding lifetime annotations in zig comments. you can make a no-op function that gets compiled out but survives AIR > rust knows when it can Drop. and its possible to cause problems if you aren't aware where rust picks to dropp. > And rust can put noalias everywhere in emitted code. zig has noalias and it should be posssible to do alias tracking as a refinement. > But if you want static memory safety in a low level systems language, its probably much easier to just use rust. don't use that attitude to suck oxygen out of the air. rust comes with its own baggage, so "just using rust because its the only choice" keeps you in a local minimum.
      - josephg 5mo ago
        > and its possible to cause problems if you aren't aware where rust picks to drop. Can you give some examples? I've never ran into problems due to this. > don't use that attitude to suck oxygen out of the air. rust comes with its own baggage Yeah, that's a totally fair argument. One nice aspect of the approach you're proposing is it'd give you the opportunity to explore more of the borrow checker design space. I'm convinced there's a giant forest of different ways we could do compile time memory safety. Rust has gone down one particular road in that forest. But there's probably loads of other options that nobody has tried yet. Some of them will probably be better than rust - but nobody has thought them through yet. I wish you luck in your project! If you land somewhere interesting, I hope you write it up.
        dnautics 5mo ago
        > Can you give some examples? I've never ran into problems due to this. If it's doing a drop in the hot loop that may be an unexpected performance regression that could be carefully lifted. thank you. Unfortunately in the last few weeks i've been too busy with my startup to put as much work into it. We'll see =D
        josephg 5mo ago
        > If it's doing a drop in the hot loop that may be an unexpected performance regression that could be carefully lifted. Yeah, I've heard of people being surprised that when they make massive collections of Box'ed entries, then get surprised that it takes a long time to Drop the whole thing. But this would be the same in C or Zig too. Malloc and free are really complex functions. Reducing heap allocations is an essential tool for optimisation. The solution to this "unexpected performance regression" in rust is the same as it is in C, C++ and Zig: Stop heap allocating so much. Use primitive types, SSO types (SmartString and friends in rust) or memory arenas. Drop isn't the problem.
        brabel 5mo ago
        In zig the solution is to use an arena allocator. That’s about as easy as it gets. Maybe Rust also allows doing that, I don’t know.
- pjmlp 5mo ago
  Those tools exit in C tooling as well, now that many ignore them is another matter. MSVC has a debug allocator since at least Visual Studio 5.
efficax 5mo ago
zig is unmanaged memory. But rust also allows memory leaks, and they're not uncommon in large, complex programs. So this rewrite will not necessarily control for that.
- X0Refraction 5mo ago
  What language doesn't allow memory leaks?
  - dmytrish 5mo ago
    There are two kinds of memory leaks: forgotten manual freeing (all references are gone, but allocation is not) and forgetting to get rid of references that keeps an allocation alive. Both are a kind of logical error, but the first is mostly possible in languages with manual memory management. The second one is a universal logical error (only programmer knows which live references are really needed).
    - tardedmeme 5mo ago
      Rust allows reference-counting cycles, right?
    - ethanpailes 5mo ago
      In the Haskell community I’ve seen the second kind called “space leaks.” I don’t see it used much outside that community but I like the term and use it when talking about other languages as well.
  - efficax 5mo ago
    I suppose all languages allow them, depending on how you define a memory leak. Garbage collected languages generally prevent them, since you never have to explicitly free memory, but if there are reference cycles, that memory can never be freed automatically. Rust has the same problem, but since rust uses lifetimes to understand when to drop things, many people expect that this will mean there can be no memory leaks, but leaks are not considered a correctness or safety issue (oom is a panic and panic is safe!). Not only explicitly possible (through Box::leak) but also possible by mistake (again, usually through reference cycles).
nyrikki 5mo ago
Zig is a middle ground. It solves some of the common foot-guns in C, Without the costs of affine substructural typing that offers Rust its super powers. I am of the opinion that it is horses for courses and not a universal better proposition. Because my needs don’t fit in with Rust’s decisions very well I will use zig for personal projects when needed. I just need linked lists, graphs etc… While hopefully someone can provide a more comprehensive explanation here are the two huge wins for my use case. 1) In Zig, accessing an array or slice out of bounds is considered detectable illegal behavior. 2) defer[0] allows you to collocate the the freeing of resources with code. That at least ‘feels’ safer to me than a bunch of ‘unsafe’ rust that is required for my very specific use case. I was working on some eBPF code in C and did really miss zig. For me it fits the Pareto principle but zig is also just a sometimes food for me, so take that for what it is worth. [0] https://zig.guide/language-basics/defer/ https://zig.guide/language-basics/defer/
- IshKebab 5mo ago
  Fwiw you don't need unsafe for graphs or linked lists in Rust. At least not directly - these things can be abstracted. The petgraph crate is the most popular for graphs. I'm not sure about linked lists because linked lists are the wrong choice 99.9% of the time. I've written hundreds of thousands of lines of Rust and outside of FFI, I've written I think one line of unsafe Rust.
  - fao_ 5mo ago
    [flagged]
    - IshKebab 5mo ago
      It's not as simple as that. All software is abstraction and with any software if you go deep enough you'll find unsafe code. E.g. look at a Python list. Is it safe? In Python sure, but that's abstracting a C implementation which definitely isn't safe. If you look at Rust's std::Vec you'll find a very similar story - safe interface over an unsafe implementation. It isn't as binary as you think.
    - 5mo ago
SuperV1234 5mo ago
Zig doesn't even have RAII...
- reactordev 5mo ago
  which is a good thing. C++'s RAII is magic-sauce that does a lot for you when you can simply use `defer` in zig. A constructor is just a function call. A destructor is just a function call.
  - shakow 5mo ago
    And a function call is just a fancy JMP, still it's generally acknowledged to be better to have all the bookkeeping automated.
  - fooker 5mo ago
    How is defer not magic sauce?
    - zephen 5mo ago
      Whether you consider it magic is up to you, but, unlike a destructor in RAII, there is nothing automatic going on. If you don't explicitly invoke a destructor, you won't get a destructor. The fact that you can explicitly invoke the destructor to happen later is simply syntactic sugar, just like if/else/while, or any other control construct more powerful than a conditional jump instruction.
      - drysine 5mo ago
        > If you don't explicitly invoke a destructor, you won't get a destructor. When you explicitly invoke a "destructor", you do it on many code paths (and miss one or two) >The fact that you can explicitly invoke the destructor to happen later You don't specify where the `defer`-red "destructor" will be invoked.
        zephen 5mo ago
baranul 5mo ago
It is quite obvious that Zig is pre 1.0 with thousands of stranded unsolved issues (per their GitHub repo). A review of Zig hype gives the strong impression it was created by being relentlessly and suspiciously pushed on HN, beyond logic or its language rankings (per TIOBE or GitHub stats), so that many were under the illusion that the language was something more or other than what it really is. Zig is still under development and beta. Stability, crashes, and leaks should not be surprising, and even expected. To stick with a beta language, usually companies and developers are philosophically and/or financially aligned with the language. An example is JangaFX and Odin, where they not only have committed to using the language (despite being beta) in their products, but have directly hired GingerBill. Team Bun appears to have "alignment and relationship issues" with Zig, to the point they have decided to extensively explore their options. Now Bun is rewritten in Rust. They are seeing if Rust solves their requirements. As with any relationship, if one ignores or takes a partner for granted, don't be surprised if they want a divorce or jump to someone else.
- smj-edison 5mo ago
  You might want to check their Codeberg then, because they've moved all their development over there...
  - baranul 5mo ago
    Zig very much could of moved all of their GitHub issues over to Codeberg, to be resolved, but chose not to do so. Thus left thousands of issues unsolved and stranded. This maneuver was arguably obfuscated by the anti-LLM stance and finger pointing at Microsoft, but nevertheless, many still have noticed. Zig, for a long time, had been falling behind and doing poorly on their open to close ratio for resolving issues. It should be embarrassing to leave so many issues open. Even if not accepting new GitHub issues, they have demonstrated an inability to resolve existing issues, except at an extremely slow pace. Considering there are just about no new issues on their GitHub repo, it is understandable if there are those that find the pace to close and amount of issues unacceptable or questionable, in addition to the clearly bad open to close ratio.

josephg 5mo ago

Nope! Zig is like C in this regard. There’s no borrow checker. Managing memory is your responsibility. It gives you a few more tools than C - like a debug allocator, bounds checked array slices and so on. But it’s not a memory safe language like rust.

dnautics 5mo ago
It's not.. but im pretty sure it could be. could probably even take this (WIP) idea and bolt on a formal verifier pretty easily. https://github.com/ityonemo/clr https://github.com/ityonemo/clr
- josephg 5mo ago
  It'd take more than that to match rust's borrow checker. Rust's borrow checker tracks lifetimes, and sometimes needs annotations in code to help it understand what you're actually trying to do. I suppose you could work around that by adding lifetime annotations in zig comments. Then you've have a language that's a lot like rust, but without an ecosystem of borrowck-safe libraries. And with worse ergonomics (rust knows when it can Drop). And rust can put noalias everywhere in emitted code. And you'd probably have worse error messages than the rust compiler emits. Its an interesting idea. But if you want static memory safety in a low level systems language, its probably much easier to just use rust.
  - dnautics 5mo ago
    > I suppose you could work around that by adding lifetime annotations in zig comments. you can make a no-op function that gets compiled out but survives AIR > rust knows when it can Drop. and its possible to cause problems if you aren't aware where rust picks to dropp. > And rust can put noalias everywhere in emitted code. zig has noalias and it should be posssible to do alias tracking as a refinement. > But if you want static memory safety in a low level systems language, its probably much easier to just use rust. don't use that attitude to suck oxygen out of the air. rust comes with its own baggage, so "just using rust because its the only choice" keeps you in a local minimum.
    - josephg 5mo ago
      > and its possible to cause problems if you aren't aware where rust picks to drop. Can you give some examples? I've never ran into problems due to this. > don't use that attitude to suck oxygen out of the air. rust comes with its own baggage Yeah, that's a totally fair argument. One nice aspect of the approach you're proposing is it'd give you the opportunity to explore more of the borrow checker design space. I'm convinced there's a giant forest of different ways we could do compile time memory safety. Rust has gone down one particular road in that forest. But there's probably loads of other options that nobody has tried yet. Some of them will probably be better than rust - but nobody has thought them through yet. I wish you luck in your project! If you land somewhere interesting, I hope you write it up.
      - dnautics 5mo ago
        > Can you give some examples? I've never ran into problems due to this. If it's doing a drop in the hot loop that may be an unexpected performance regression that could be carefully lifted. thank you. Unfortunately in the last few weeks i've been too busy with my startup to put as much work into it. We'll see =D
        josephg 5mo ago
        > If it's doing a drop in the hot loop that may be an unexpected performance regression that could be carefully lifted. Yeah, I've heard of people being surprised that when they make massive collections of Box'ed entries, then get surprised that it takes a long time to Drop the whole thing. But this would be the same in C or Zig too. Malloc and free are really complex functions. Reducing heap allocations is an essential tool for optimisation. The solution to this "unexpected performance regression" in rust is the same as it is in C, C++ and Zig: Stop heap allocating so much. Use primitive types, SSO types (SmartString and friends in rust) or memory arenas. Drop isn't the problem.
        brabel 5mo ago
        In zig the solution is to use an arena allocator. That’s about as easy as it gets. Maybe Rust also allows doing that, I don’t know.
pjmlp 5mo ago
Those tools exit in C tooling as well, now that many ignore them is another matter. MSVC has a debug allocator since at least Visual Studio 5.

efficax 5mo ago

zig is unmanaged memory. But rust also allows memory leaks, and they're not uncommon in large, complex programs. So this rewrite will not necessarily control for that.

X0Refraction 5mo ago
What language doesn't allow memory leaks?
- dmytrish 5mo ago
  There are two kinds of memory leaks: forgotten manual freeing (all references are gone, but allocation is not) and forgetting to get rid of references that keeps an allocation alive. Both are a kind of logical error, but the first is mostly possible in languages with manual memory management. The second one is a universal logical error (only programmer knows which live references are really needed).
  - tardedmeme 5mo ago
    Rust allows reference-counting cycles, right?
  - ethanpailes 5mo ago
    In the Haskell community I’ve seen the second kind called “space leaks.” I don’t see it used much outside that community but I like the term and use it when talking about other languages as well.
- efficax 5mo ago
  I suppose all languages allow them, depending on how you define a memory leak. Garbage collected languages generally prevent them, since you never have to explicitly free memory, but if there are reference cycles, that memory can never be freed automatically. Rust has the same problem, but since rust uses lifetimes to understand when to drop things, many people expect that this will mean there can be no memory leaks, but leaks are not considered a correctness or safety issue (oom is a panic and panic is safe!). Not only explicitly possible (through Box::leak) but also possible by mistake (again, usually through reference cycles).

nyrikki 5mo ago

Zig is a middle ground. It solves some of the common foot-guns in C, Without the costs of affine substructural typing that offers Rust its super powers. I am of the opinion that it is horses for courses and not a universal better proposition. Because my needs don’t fit in with Rust’s decisions very well I will use zig for personal projects when needed. I just need linked lists, graphs etc… While hopefully someone can provide a more comprehensive explanation here are the two huge wins for my use case. 1) In Zig, accessing an array or slice out of bounds is considered detectable illegal behavior. 2) defer[0] allows you to collocate the the freeing of resources with code. That at least ‘feels’ safer to me than a bunch of ‘unsafe’ rust that is required for my very specific use case. I was working on some eBPF code in C and did really miss zig. For me it fits the Pareto principle but zig is also just a sometimes food for me, so take that for what it is worth. [0] https://zig.guide/language-basics/defer/ https://zig.guide/language-basics/defer/

IshKebab 5mo ago
Fwiw you don't need unsafe for graphs or linked lists in Rust. At least not directly - these things can be abstracted. The petgraph crate is the most popular for graphs. I'm not sure about linked lists because linked lists are the wrong choice 99.9% of the time. I've written hundreds of thousands of lines of Rust and outside of FFI, I've written I think one line of unsafe Rust.
- fao_ 5mo ago
  [flagged]
  - IshKebab 5mo ago
    It's not as simple as that. All software is abstraction and with any software if you go deep enough you'll find unsafe code. E.g. look at a Python list. Is it safe? In Python sure, but that's abstracting a C implementation which definitely isn't safe. If you look at Rust's std::Vec you'll find a very similar story - safe interface over an unsafe implementation. It isn't as binary as you think.
  - 5mo ago

SuperV1234 5mo ago

Zig doesn't even have RAII...

reactordev 5mo ago
which is a good thing. C++'s RAII is magic-sauce that does a lot for you when you can simply use `defer` in zig. A constructor is just a function call. A destructor is just a function call.
- shakow 5mo ago
  And a function call is just a fancy JMP, still it's generally acknowledged to be better to have all the bookkeeping automated.
- fooker 5mo ago
  How is defer not magic sauce?
  - zephen 5mo ago
    Whether you consider it magic is up to you, but, unlike a destructor in RAII, there is nothing automatic going on. If you don't explicitly invoke a destructor, you won't get a destructor. The fact that you can explicitly invoke the destructor to happen later is simply syntactic sugar, just like if/else/while, or any other control construct more powerful than a conditional jump instruction.
    - drysine 5mo ago
      > If you don't explicitly invoke a destructor, you won't get a destructor. When you explicitly invoke a "destructor", you do it on many code paths (and miss one or two) >The fact that you can explicitly invoke the destructor to happen later You don't specify where the `defer`-red "destructor" will be invoked.
      - zephen 5mo ago

baranul 5mo ago

It is quite obvious that Zig is pre 1.0 with thousands of stranded unsolved issues (per their GitHub repo). A review of Zig hype gives the strong impression it was created by being relentlessly and suspiciously pushed on HN, beyond logic or its language rankings (per TIOBE or GitHub stats), so that many were under the illusion that the language was something more or other than what it really is. Zig is still under development and beta. Stability, crashes, and leaks should not be surprising, and even expected. To stick with a beta language, usually companies and developers are philosophically and/or financially aligned with the language. An example is JangaFX and Odin, where they not only have committed to using the language (despite being beta) in their products, but have directly hired GingerBill. Team Bun appears to have "alignment and relationship issues" with Zig, to the point they have decided to extensively explore their options. Now Bun is rewritten in Rust. They are seeing if Rust solves their requirements. As with any relationship, if one ignores or takes a partner for granted, don't be surprised if they want a divorce or jump to someone else.

smj-edison 5mo ago
You might want to check their Codeberg then, because they've moved all their development over there...
- baranul 5mo ago
  Zig very much could of moved all of their GitHub issues over to Codeberg, to be resolved, but chose not to do so. Thus left thousands of issues unsolved and stranded. This maneuver was arguably obfuscated by the anti-LLM stance and finger pointing at Microsoft, but nevertheless, many still have noticed. Zig, for a long time, had been falling behind and doing poorly on their open to close ratio for resolving issues. It should be embarrassing to leave so many issues open. Even if not accepting new GitHub issues, they have demonstrated an inability to resolve existing issues, except at an extremely slow pace. Considering there are just about no new issues on their GitHub repo, it is understandable if there are those that find the pace to close and amount of issues unacceptable or questionable, in addition to the clearly bad open to close ratio.