4 ms·

have not played with zig for a while, remain in the C world. with the cleanup attribute(a cheap "defer" for C), and the sanitizers, static analysis tools, memo

have not played with zig for a while, remain in the C world. with the cleanup attribute(a cheap "defer" for C), and the sanitizers, static analysis tools, memory tagging extension(MTE) for memory safety at hardware level, etc, and a zig 1.0 still probably years away, what's the strong selling point that I need spend time with zig these days? Asking because I'm unsure if I should re-try it.

flohofwoe 1y ago
My 2ct: A much more useful stdlib (that's also currently the most unstable part though, and I don't agree with all the design decisions in the stdlib - but mostly still better than a nearly useless stdlib like C provides - and don't even get me started about the C++ stdlib heh), integrated build system and package manager (even great for pure C/C++ projects), and comptime with all the things it enables (like straightforward reflection and generics). It also fixes a shitton of tiny design warts that we've become accustomed to in C (also very slowly happening in the C standard, but that will take decades while Zig has those fixes now). Also, probably the best integration with C code you can get outside of C++. E.g. hybrid C/Zig projects is a regular use case and has close to no friction. C won't go away for me, but tinkering with Zig is just more fun :)
- cassepipe 1y ago
  Could you expand on what are the design decisions you disapprove of ? You got me curious
  - flohofwoe 1y ago
    Many parts of the stdlib don't separate between public interface and internal implementation details. It's possible to accidentially mess with data items which are clearly meant to be implementation-private. I think this is because many parts of the stdlib are too object-oriented, for instance the containers are more or less C++ style objects, but this style of programming really needs RAII and restricted visibility rules like public/private (now Zig shouldn't get those, but IMHO the stdlib shouldn't pretend that those language features exist). As a sister comment says, Zig is a great programming language, but the stdlib needs some sort of basic and consistent design philosophy whitch matches the language capabilities. Tbf though, C gets around this problem by simply not providing a useful stdlib and delegating all the tricky design questions to library authors ;)
    - smj-edison 1y ago
      Honestly getting to mess with internal implementation details is my favorite part of using Zig's standard library. I'm working on a multithreaded interpreter right now, where each object has a unique index, so I need effectively a 4GB array to store them all. It's generally considered rude to allocate that all at once, so I'm using 4GB of virtual memory. I can literally just swap out std.MultiArrayList's backing array with vmem, set its capacity, and use all of its features, except now with virtual memory[1]. [1] https://github.com/smj-edison/zicl/blob/bacb08153305d5ba97fcb886a193a8e029197831/src/Heap.zig#L258 https://github.com/smj-edison/zicl/blob/bacb08153305d5ba97fc...
      - flohofwoe 1y ago
        I would at least like to see some sort of naming convention for implementation-private properties, maybe like: const Bla = struct { // public access intended bla: i32, blub: i32, // here be dragons _private: struct { x: i32, y: i32, }, }; ...that way you can still access and mess up those 'private' items, but at least it's clear now which of the struct items are part of the 'public API contract' and which are considered internal implementation details which may change on a whim.
        smj-edison 1y ago
        Aah, that's a good point. I suppose you could argue that the doc notes indicate whether something it meant to be accessed directly, like when ArrayList mentions "This field is intended to be accessed directly.", but that's really hard to determine at a glance.
        KallDrexx 1y ago
        This is my main frustration with the push back against visibility modifiers. It's treated as an all or nothing approach, that any support for visibility modifiers locks anyone out from touching those fields. It could just be a compiler error/warning that has to be explicitly opted into to touch those fields. This allows you to say "I know this is normally a footgun to modify these fields, and I might be violating an invariant condition, but I am know what I'm doing".
- lukaslalinsky 1y ago
  I really like Zig as a language, but I think the standard library is a huge weakness. I find the design extremely inconsistent. It feels like a collection of small packages, not a coherent unit. And I personally think this std.Io interface is on a similar path. The idea of abstracting our all I/O calls is great, but the actual interface is sketchy, in my opinion.
  - throwawaymaths 1y ago
    https://github.com/ziglang/zig/issues/1629 https://github.com/ziglang/zig/issues/1629
pron 1y ago
I don't think any language that's not well-established, let alone one that isn't stabilised yet, would have a strong selling point if what you're looking for right now is to write production code that you'll maintain for a decade or more to come (I mean, companies do use languages that aren't as established as C in production apps, including Zig, but that's certainly not for everyone). But if you're open to learning languages for tinkering/education purposes, I would say that Zig has several significant "intrinsic" advantages compared to C. * It's much more expressive (it's at least as expressive as C++), while still being a very simple language (you can learn it fully in a few days). * Its cross-compilation tooling is something of a marvel. * It offers not only spatial memory safety, but protection from other kinds of undefined behaviour, in the form of things like tagged unions.

flohofwoe 1y ago

My 2ct: A much more useful stdlib (that's also currently the most unstable part though, and I don't agree with all the design decisions in the stdlib - but mostly still better than a nearly useless stdlib like C provides - and don't even get me started about the C++ stdlib heh), integrated build system and package manager (even great for pure C/C++ projects), and comptime with all the things it enables (like straightforward reflection and generics). It also fixes a shitton of tiny design warts that we've become accustomed to in C (also very slowly happening in the C standard, but that will take decades while Zig has those fixes now). Also, probably the best integration with C code you can get outside of C++. E.g. hybrid C/Zig projects is a regular use case and has close to no friction. C won't go away for me, but tinkering with Zig is just more fun :)

cassepipe 1y ago
Could you expand on what are the design decisions you disapprove of ? You got me curious
- flohofwoe 1y ago
  Many parts of the stdlib don't separate between public interface and internal implementation details. It's possible to accidentially mess with data items which are clearly meant to be implementation-private. I think this is because many parts of the stdlib are too object-oriented, for instance the containers are more or less C++ style objects, but this style of programming really needs RAII and restricted visibility rules like public/private (now Zig shouldn't get those, but IMHO the stdlib shouldn't pretend that those language features exist). As a sister comment says, Zig is a great programming language, but the stdlib needs some sort of basic and consistent design philosophy whitch matches the language capabilities. Tbf though, C gets around this problem by simply not providing a useful stdlib and delegating all the tricky design questions to library authors ;)
  - smj-edison 1y ago
    Honestly getting to mess with internal implementation details is my favorite part of using Zig's standard library. I'm working on a multithreaded interpreter right now, where each object has a unique index, so I need effectively a 4GB array to store them all. It's generally considered rude to allocate that all at once, so I'm using 4GB of virtual memory. I can literally just swap out std.MultiArrayList's backing array with vmem, set its capacity, and use all of its features, except now with virtual memory[1]. [1] https://github.com/smj-edison/zicl/blob/bacb08153305d5ba97fcb886a193a8e029197831/src/Heap.zig#L258 https://github.com/smj-edison/zicl/blob/bacb08153305d5ba97fc...
    - flohofwoe 1y ago
      I would at least like to see some sort of naming convention for implementation-private properties, maybe like: const Bla = struct { // public access intended bla: i32, blub: i32, // here be dragons _private: struct { x: i32, y: i32, }, }; ...that way you can still access and mess up those 'private' items, but at least it's clear now which of the struct items are part of the 'public API contract' and which are considered internal implementation details which may change on a whim.
      - smj-edison 1y ago
        Aah, that's a good point. I suppose you could argue that the doc notes indicate whether something it meant to be accessed directly, like when ArrayList mentions "This field is intended to be accessed directly.", but that's really hard to determine at a glance.
      - KallDrexx 1y ago
        This is my main frustration with the push back against visibility modifiers. It's treated as an all or nothing approach, that any support for visibility modifiers locks anyone out from touching those fields. It could just be a compiler error/warning that has to be explicitly opted into to touch those fields. This allows you to say "I know this is normally a footgun to modify these fields, and I might be violating an invariant condition, but I am know what I'm doing".
lukaslalinsky 1y ago
I really like Zig as a language, but I think the standard library is a huge weakness. I find the design extremely inconsistent. It feels like a collection of small packages, not a coherent unit. And I personally think this std.Io interface is on a similar path. The idea of abstracting our all I/O calls is great, but the actual interface is sketchy, in my opinion.
- throwawaymaths 1y ago
  https://github.com/ziglang/zig/issues/1629 https://github.com/ziglang/zig/issues/1629

pron 1y ago

I don't think any language that's not well-established, let alone one that isn't stabilised yet, would have a strong selling point if what you're looking for right now is to write production code that you'll maintain for a decade or more to come (I mean, companies do use languages that aren't as established as C in production apps, including Zig, but that's certainly not for everyone). But if you're open to learning languages for tinkering/education purposes, I would say that Zig has several significant "intrinsic" advantages compared to C. * It's much more expressive (it's at least as expressive as C++), while still being a very simple language (you can learn it fully in a few days). * Its cross-compilation tooling is something of a marvel. * It offers not only spatial memory safety, but protection from other kinds of undefined behaviour, in the form of things like tagged unions.