7 ms·

I am all in on Zig. I was more producitve with it in a few weeks than I was after a few months of rust. Yes the memory management is "manual" but the std librar

I am all in on Zig. I was more producitve with it in a few weeks than I was after a few months of rust. Yes the memory management is "manual" but the std library functions for dealing with it are top notch, you have to free a lot less due to the ease of using arena allocators, and the testing allocator does a valgrind-esque runtime analysis of your code - very quickly and very thoroughly. In practice, it's not an issue, and unlike with rust I have a very clear idea of when and where memory is being freed and allocated. That having been said - the core team chooses some incredibly dumb hills to die on. Last time I checked the tab character was illegal in Zig code - though I understand that's changing. More concerning is that un-named parameters are a compiler error and this cannot be adjusted. Meaning that if you want to test on save, you can't if any of your parameters are unused. Enforcing such a thing at the compiler level because of your personal coding style is so mind-numbingly short sighted. The guy who made it is clearly a very smart and insightful, but I acknowledge you probably have to be fairly stubborn to decide you're going to replace C.

pcwalton 4y ago
> In practice, it's not an issue, and unlike with rust I have a very clear idea of when and where memory is being freed and allocated. I'm very skeptical that the lack of memory safety is not going to be an issue "in practice". That's what every C++ developer thinks too until they write code people actually try to attack. One of the very nice things about memory safety is that it frees the programmer from having to think about when memory is freed most of the time. The compiler or runtime system will take care of that. Most of the time, manual frees are just noise--this observation is the entire reason behind destructors.
- LAC-Tech 4y ago
  Learn Zig and get back to me. It's nothing at all like managing memory in C++, not even close.
  - pcwalton 4y ago
    We've had close to 50 years to answer the question "is memory safety necessary to write secure code under normal industry development practices"? During this time dozens of languages have come and gone, and the evidence still overwhelmingly points to "yes". It's going to take a lot to make a convincing argument otherwise, especially since Zig doesn't really do much different from C here, semantically speaking.
    - LAC-Tech 4y ago
      I've explained how Zig memory management is different. You've chosen to ignore that and just compare it C and C++. I've suggested you learn Zig. You've ignored that too, and just zeroed in on the fact it's "manual". Here's a car analogy - old manual vehicles had unsynchronised transmissions where the clutch had to be depressed twice per gear change. Newer manual vehicles use steering wheel mounted paddle shifters and the clutch only needs to be depressed when stopping or starting. You're trying to push your weird semi-automatic transmission - that a lot of people find unusable as a daily driver - by ranting about how awful double clutching is.
      - pcwalton 4y ago
        Car analogies aren't a substitute for actually writing widely-attacked software. There are systematic reasons why I'm skeptical Zig's approach will lead to better results than what we see in modern C++. The worst memory safety issues from a security point of view tend to be use-after-free caused by complex, untested code patterns, where one programmer wrote, or implied, "free", without realizing that somewhere else in the millions-of-lines codebase some other part of the code, written by someone else, still had a reference to the object. Unit tests don't catch these problems because they're caused by strange patterns that the programmer didn't anticipate. That is the kind of vulnerability that is difficult to solve without either a compiler or a runtime system (GC) to help you, and I see nothing in Zig that solves it. You can, and people do, make raw pointers to other objects in Zig.
        anonymoushn 4y ago
- dagmx 4y ago
  I’ve met a lot of seasoned C++ developers who tell me the memory safety won’t be an issue in practice. Hell, I’m sure I’ve said it before too. I’ve yet to meet one who actually didn’t end up with some safety issue in their code. Not all of their code mind you, but even a couple times can be significant. Like you, I like memory safe languages because they let me think about my problem and trust the tooling to catch entire classes of mistakes for me
  - zackees 4y ago
  - dataflow 4y ago
    > I’ve met a lot of seasoned C++ developers who tell me the memory safety won’t be an issue in practice. Hell, I’m sure I’ve said it before too. The claim I've heard (and I think also made) is a bit different from that. It's more like: "dealing with memory corruption issues isn't a significant portion of the debugging effort in [idiomatic] C++ code". i.e. the claim is not that you somehow won't run into them; rather, the claim is that they form a small fraction of the actual bugs you run into (either count-wise or time-wise), if you're writing C++ "properly". (If I had to make up a number, I'd say < 5%.) This obviously isn't to say memory safety isn't an issue, or that security is a negligible property. Rather, it's to point out that most issues are of a different kind, and if you think that memory safety will decrease your workload significantly, that's unlikely to be the case if you're writing C++ with the correct idioms. I think this response is usually in response to claims about how (say) a language like Rust results in N times faster development than C++. If that's truly the case, it's unlikely to be due to memory safety per se, but due to other factors.
    - verdagon 4y ago
      To add to that, there are some applications for which memory unsafety just doesn't cause that much harm. I worked on a very large C++ codebase that compiled to webassembly, which runs sandboxed in people's browsers. It only talked to one (trusted) server. Like any project, we had plenty of logic bugs every release. They would often result in odd artifacts on the screen and sometimes a crash. Only 5% of our bugs were related to memory unsafety, and they also resulted in odd artifacts on the screen and sometimes a crash. In other words, memory unsafety wasn't much of a concern in practice. It was as bad as any logic bug. This was the main reason we stuck with C++, rather than spend SWE-years migrating to a more memory-safe language. (I know this is ironic coming from me, who designs a memory-safe language full-time!)
- ghoward 4y ago
  Not GP. > I'm very skeptical that the lack of memory safety is not going to be an issue "in practice". For what it's worth, I agree with you. And I'm a C programmer that managed to put out a non-trivial piece of C code ([1]) that has had no memory safety issues triggered in the wild after 1.0 (which was released on 26 Oct 2018, so almost 4 years, yay!) that I know of. The truth is that I am not able to write such code; I just fuzz the ever-living daylights out of my code with lots of asserts to test all of the assumptions that my code makes, including preconditions, postconditions, everything. I also use static analysis, -Weverything on Clang (without -Wpadded; that's a stupid warning), and a massive test suite with near 100% coverage. In my new projects, I'm even using fuzzing to generate almost all of my test cases so that my path coverage is as good as possible. That's a lot of work, and it's not fun. But what would make it even more effective would be to effectively automatically add asserts for me to test the assumption that an index is in range whenever it is used! And that's why memory-safe languages are the only way to go: not only do they save people from bad code, they help programmers turn bad code into good code with the tools at their disposal. I think the Zig people know this, which is why they have ReleaseSafe for testing and for those cases where you have to be sure. But I also don't see them test their code enough for me to trust that it's not needed. And I doubt that Zig users test their code enough for it too. All of this is to say, I completely agree with you despite (so far!) being the exception to the rule you articulated, and I dread the day when my reign of "being the exception" comes to an end. I really want to stay being the exception. [1]: https://git.yzena.com/gavin/bc https://git.yzena.com/gavin/bc
  - pjmlp 4y ago
    Congratulations for being part of the minority that cares, On my experience, only small teams with top devs do happen to care for doing the security work you describe, as tends to be proven by surveys regarding the use of unit testing or static analysis tooling, https://www.jetbrains.com/lp/devecosystem-2021/c/ https://www.jetbrains.com/lp/devecosystem-2021/c/ https://www.jetbrains.com/lp/devecosystem-2021/cpp/ https://www.jetbrains.com/lp/devecosystem-2021/cpp/ So yeah, pity that memory-safe languages have to fight back to regain what was already possible before UNIX took over the computing world and brought C for the ride. This is why I would like that Zig could offer more than Modula-2 already did in 1978, in regards to memory corruption.
peteradio 4y ago
> More concerning is that un-named parameters are a compiler error and this cannot be adjusted. Would you be willing to expand this a bit? This would save you from giving a dummy name in a function?
- neandrake 4y ago
  I think it’s a typo and they meant unused parameters.
  - LAC-Tech 4y ago
    Yes, I meant unused parameters. Makes it very hard to do TDD.
    - kuon 4y ago
      I have an editor macro that inserts _ = myvar; // TODO remove easily for all function arguments when prototyping. I agree it can be cumbersome, but I am not sure it is a bad thing.
      - 41b696ef1113 4y ago
        Not that I write Go anymore, but this was definitely one of those things that regularly made my blood boil. Any kind of experimentation/swapping around data structures always invoked the wrath of the compiler when I am just trying to quickly iterate on an idea. Always felt like it disincentivized improvements. Should have been a warning. Baked in from day-one, easily makes that a CI check without hampering development.
        kaba0 4y ago
        TS with this lint enabled as well. When these languages tout fast iteration cycles, yet for a single-line code you have to do a recursive, n-step compilation of everything that might also get unused is literally insane and indefensible position.
deleted 4y ago
[deleted]
markisus 4y ago
I agree. Zig is great in many ways but I am also so frustrated by some of the obviously horrible unergonomic decisions the core team makes. To this day, you are forced to declare loop index outside the loop body, despite many requests from the community. https://github.com/ziglang/zig/issues/358#issuecomment-491004876 https://github.com/ziglang/zig/issues/358#issuecomment-49100...
- abainbridge 4y ago
  I don't understand why fixing issue 358 in the Zig compiler isn't trivial. I don't understand the reluctance. I don't understand why: for (var i: usize = a; i < b; i += 1) { foo(); } for (var i: usize = a; i < b; i += 1) { bar(); } Is worse than: var i: usize = a; while (i < b) : (i += 1) { foo(); } while (i < b) : (i += 1) { bar(); } Which is what happens without the for-loop scoping of the variable. (ie when I cut and pasted, I introduced a logic bug where I forgot to initialize i for the second loop).
  - abainbridge 4y ago
    Maybe there is a good reason. I'd just like to know what it is. My guess is that fixing issue 358 with syntactic sugar would mean that the debug info would show scope blocks that don't correspond to {} in the source, and that is annoying.
    - abainbridge 4y ago
      I also see that this is a bike-shed issue [1]. It probably isn't as important as some other language issues that are complicated enough that I don't even know about them. However, people's first impression of the language matter, so fixing the bike shed matters. [1] https://en.wikipedia.org/wiki/Law_of_triviality https://en.wikipedia.org/wiki/Law_of_triviality
- Aransentin 4y ago
  There is an accepted (but as of yet unimplemented) proposal to fix just that: https://github.com/ziglang/zig/issues/7257#issuecomment-1030720073 https://github.com/ziglang/zig/issues/7257#issuecomment-1030...
sph 4y ago
> More concerning is that un-named parameters are a compiler error I've been ranting about it many times. Most recently: https://news.ycombinator.com/item?id=32145520 https://news.ycombinator.com/item?id=32145520 There is an upstream issue about it where we should probably get our voices heard, it's encouraging to see many people in that thread that are opposed to that change, but it doesn't seem the core devs are open to considering any alternative, rather they just hope we can learn to live with it. https://github.com/ziglang/zig/issues/335 https://github.com/ziglang/zig/issues/335 This is by far my biggest annoyance with Go, more so than writing if err != nil. I feel I write code in a different way than other people. Some are very slow, thoughtful and methodical in writing code, while I tend to experiment, throwing stuff at the wall and iterating quickly, and only after going back to polish and refactor. Stopping every iteration during my experimentation phase to lint my code because the compiler is pedantic and stubborn just slows me down immensely and turns me off a language. EDIT: went and shared my criticism upstream, in a constructive and reasoned manner, I hope. My quixotic fight against unused variables being errors carries on.
- LAC-Tech 4y ago
  I don't think there's any point addressing this through the Zig community. It's self-selecting for people who think this is perfectly fine. Public discussion of it is much more effective. Best case scenario, they take notice at the wider world meme'ing Zig for such irritating quirks and realise how many potential users they're losing. An OK case scenario is someone maintains a fork. Worst case scenario is they don't change, no one bothers with a fork, and very few people bother with Zig and general. Ball is in their court. I would hate for them to cut their nose to spite their face, but I suspect they will unfortunately.

pcwalton 4y ago

> In practice, it's not an issue, and unlike with rust I have a very clear idea of when and where memory is being freed and allocated. I'm very skeptical that the lack of memory safety is not going to be an issue "in practice". That's what every C++ developer thinks too until they write code people actually try to attack. One of the very nice things about memory safety is that it frees the programmer from having to think about when memory is freed most of the time. The compiler or runtime system will take care of that. Most of the time, manual frees are just noise--this observation is the entire reason behind destructors.

LAC-Tech 4y ago
Learn Zig and get back to me. It's nothing at all like managing memory in C++, not even close.
- pcwalton 4y ago
  We've had close to 50 years to answer the question "is memory safety necessary to write secure code under normal industry development practices"? During this time dozens of languages have come and gone, and the evidence still overwhelmingly points to "yes". It's going to take a lot to make a convincing argument otherwise, especially since Zig doesn't really do much different from C here, semantically speaking.
  - LAC-Tech 4y ago
    I've explained how Zig memory management is different. You've chosen to ignore that and just compare it C and C++. I've suggested you learn Zig. You've ignored that too, and just zeroed in on the fact it's "manual". Here's a car analogy - old manual vehicles had unsynchronised transmissions where the clutch had to be depressed twice per gear change. Newer manual vehicles use steering wheel mounted paddle shifters and the clutch only needs to be depressed when stopping or starting. You're trying to push your weird semi-automatic transmission - that a lot of people find unusable as a daily driver - by ranting about how awful double clutching is.
    - pcwalton 4y ago
      Car analogies aren't a substitute for actually writing widely-attacked software. There are systematic reasons why I'm skeptical Zig's approach will lead to better results than what we see in modern C++. The worst memory safety issues from a security point of view tend to be use-after-free caused by complex, untested code patterns, where one programmer wrote, or implied, "free", without realizing that somewhere else in the millions-of-lines codebase some other part of the code, written by someone else, still had a reference to the object. Unit tests don't catch these problems because they're caused by strange patterns that the programmer didn't anticipate. That is the kind of vulnerability that is difficult to solve without either a compiler or a runtime system (GC) to help you, and I see nothing in Zig that solves it. You can, and people do, make raw pointers to other objects in Zig.
      - anonymoushn 4y ago
dagmx 4y ago
I’ve met a lot of seasoned C++ developers who tell me the memory safety won’t be an issue in practice. Hell, I’m sure I’ve said it before too. I’ve yet to meet one who actually didn’t end up with some safety issue in their code. Not all of their code mind you, but even a couple times can be significant. Like you, I like memory safe languages because they let me think about my problem and trust the tooling to catch entire classes of mistakes for me
- zackees 4y ago
- dataflow 4y ago
  > I’ve met a lot of seasoned C++ developers who tell me the memory safety won’t be an issue in practice. Hell, I’m sure I’ve said it before too. The claim I've heard (and I think also made) is a bit different from that. It's more like: "dealing with memory corruption issues isn't a significant portion of the debugging effort in [idiomatic] C++ code". i.e. the claim is not that you somehow won't run into them; rather, the claim is that they form a small fraction of the actual bugs you run into (either count-wise or time-wise), if you're writing C++ "properly". (If I had to make up a number, I'd say < 5%.) This obviously isn't to say memory safety isn't an issue, or that security is a negligible property. Rather, it's to point out that most issues are of a different kind, and if you think that memory safety will decrease your workload significantly, that's unlikely to be the case if you're writing C++ with the correct idioms. I think this response is usually in response to claims about how (say) a language like Rust results in N times faster development than C++. If that's truly the case, it's unlikely to be due to memory safety per se, but due to other factors.
  - verdagon 4y ago
    To add to that, there are some applications for which memory unsafety just doesn't cause that much harm. I worked on a very large C++ codebase that compiled to webassembly, which runs sandboxed in people's browsers. It only talked to one (trusted) server. Like any project, we had plenty of logic bugs every release. They would often result in odd artifacts on the screen and sometimes a crash. Only 5% of our bugs were related to memory unsafety, and they also resulted in odd artifacts on the screen and sometimes a crash. In other words, memory unsafety wasn't much of a concern in practice. It was as bad as any logic bug. This was the main reason we stuck with C++, rather than spend SWE-years migrating to a more memory-safe language. (I know this is ironic coming from me, who designs a memory-safe language full-time!)
ghoward 4y ago
Not GP. > I'm very skeptical that the lack of memory safety is not going to be an issue "in practice". For what it's worth, I agree with you. And I'm a C programmer that managed to put out a non-trivial piece of C code ([1]) that has had no memory safety issues triggered in the wild after 1.0 (which was released on 26 Oct 2018, so almost 4 years, yay!) that I know of. The truth is that I am not able to write such code; I just fuzz the ever-living daylights out of my code with lots of asserts to test all of the assumptions that my code makes, including preconditions, postconditions, everything. I also use static analysis, -Weverything on Clang (without -Wpadded; that's a stupid warning), and a massive test suite with near 100% coverage. In my new projects, I'm even using fuzzing to generate almost all of my test cases so that my path coverage is as good as possible. That's a lot of work, and it's not fun. But what would make it even more effective would be to effectively automatically add asserts for me to test the assumption that an index is in range whenever it is used! And that's why memory-safe languages are the only way to go: not only do they save people from bad code, they help programmers turn bad code into good code with the tools at their disposal. I think the Zig people know this, which is why they have ReleaseSafe for testing and for those cases where you have to be sure. But I also don't see them test their code enough for me to trust that it's not needed. And I doubt that Zig users test their code enough for it too. All of this is to say, I completely agree with you despite (so far!) being the exception to the rule you articulated, and I dread the day when my reign of "being the exception" comes to an end. I really want to stay being the exception. [1]: https://git.yzena.com/gavin/bc https://git.yzena.com/gavin/bc
- pjmlp 4y ago
  Congratulations for being part of the minority that cares, On my experience, only small teams with top devs do happen to care for doing the security work you describe, as tends to be proven by surveys regarding the use of unit testing or static analysis tooling, https://www.jetbrains.com/lp/devecosystem-2021/c/ https://www.jetbrains.com/lp/devecosystem-2021/c/ https://www.jetbrains.com/lp/devecosystem-2021/cpp/ https://www.jetbrains.com/lp/devecosystem-2021/cpp/ So yeah, pity that memory-safe languages have to fight back to regain what was already possible before UNIX took over the computing world and brought C for the ride. This is why I would like that Zig could offer more than Modula-2 already did in 1978, in regards to memory corruption.

peteradio 4y ago

> More concerning is that un-named parameters are a compiler error and this cannot be adjusted. Would you be willing to expand this a bit? This would save you from giving a dummy name in a function?

neandrake 4y ago
I think it’s a typo and they meant unused parameters.
- LAC-Tech 4y ago
  Yes, I meant unused parameters. Makes it very hard to do TDD.
  - kuon 4y ago
    I have an editor macro that inserts _ = myvar; // TODO remove easily for all function arguments when prototyping. I agree it can be cumbersome, but I am not sure it is a bad thing.
    - 41b696ef1113 4y ago
      Not that I write Go anymore, but this was definitely one of those things that regularly made my blood boil. Any kind of experimentation/swapping around data structures always invoked the wrath of the compiler when I am just trying to quickly iterate on an idea. Always felt like it disincentivized improvements. Should have been a warning. Baked in from day-one, easily makes that a CI check without hampering development.
      - kaba0 4y ago
        TS with this lint enabled as well. When these languages tout fast iteration cycles, yet for a single-line code you have to do a recursive, n-step compilation of everything that might also get unused is literally insane and indefensible position.

deleted 4y ago

[deleted]

markisus 4y ago

I agree. Zig is great in many ways but I am also so frustrated by some of the obviously horrible unergonomic decisions the core team makes. To this day, you are forced to declare loop index outside the loop body, despite many requests from the community. https://github.com/ziglang/zig/issues/358#issuecomment-491004876 https://github.com/ziglang/zig/issues/358#issuecomment-49100...

abainbridge 4y ago
I don't understand why fixing issue 358 in the Zig compiler isn't trivial. I don't understand the reluctance. I don't understand why: for (var i: usize = a; i < b; i += 1) { foo(); } for (var i: usize = a; i < b; i += 1) { bar(); } Is worse than: var i: usize = a; while (i < b) : (i += 1) { foo(); } while (i < b) : (i += 1) { bar(); } Which is what happens without the for-loop scoping of the variable. (ie when I cut and pasted, I introduced a logic bug where I forgot to initialize i for the second loop).
- abainbridge 4y ago
  Maybe there is a good reason. I'd just like to know what it is. My guess is that fixing issue 358 with syntactic sugar would mean that the debug info would show scope blocks that don't correspond to {} in the source, and that is annoying.
  - abainbridge 4y ago
    I also see that this is a bike-shed issue [1]. It probably isn't as important as some other language issues that are complicated enough that I don't even know about them. However, people's first impression of the language matter, so fixing the bike shed matters. [1] https://en.wikipedia.org/wiki/Law_of_triviality https://en.wikipedia.org/wiki/Law_of_triviality
Aransentin 4y ago
There is an accepted (but as of yet unimplemented) proposal to fix just that: https://github.com/ziglang/zig/issues/7257#issuecomment-1030720073 https://github.com/ziglang/zig/issues/7257#issuecomment-1030...

sph 4y ago

> More concerning is that un-named parameters are a compiler error I've been ranting about it many times. Most recently: https://news.ycombinator.com/item?id=32145520 https://news.ycombinator.com/item?id=32145520 There is an upstream issue about it where we should probably get our voices heard, it's encouraging to see many people in that thread that are opposed to that change, but it doesn't seem the core devs are open to considering any alternative, rather they just hope we can learn to live with it. https://github.com/ziglang/zig/issues/335 https://github.com/ziglang/zig/issues/335 This is by far my biggest annoyance with Go, more so than writing if err != nil. I feel I write code in a different way than other people. Some are very slow, thoughtful and methodical in writing code, while I tend to experiment, throwing stuff at the wall and iterating quickly, and only after going back to polish and refactor. Stopping every iteration during my experimentation phase to lint my code because the compiler is pedantic and stubborn just slows me down immensely and turns me off a language. EDIT: went and shared my criticism upstream, in a constructive and reasoned manner, I hope. My quixotic fight against unused variables being errors carries on.

LAC-Tech 4y ago
I don't think there's any point addressing this through the Zig community. It's self-selecting for people who think this is perfectly fine. Public discussion of it is much more effective. Best case scenario, they take notice at the wider world meme'ing Zig for such irritating quirks and realise how many potential users they're losing. An OK case scenario is someone maintains a fork. Worst case scenario is they don't change, no one bothers with a fork, and very few people bother with Zig and general. Ball is in their court. I would hate for them to cut their nose to spite their face, but I suspect they will unfortunately.