9 ms·

I've seen Zig popup a lot recently. What's the value proposition of Zig? It's not immediately obvious to me. Is it kind of like the Kotlin of C, going for a b

I've seen Zig popup a lot recently. What's the value proposition of Zig? It's not immediately obvious to me. Is it kind of like the Kotlin of C, going for a better syntax/modern features but otherwise being very similar?

logicchains 1y ago
It's a powerful alternative to Rust and C++ for writing ultra low latency code when safety isn't important, like games or HFT. Its standard library and ecosystem have excellent support for passing around allocators and no hidden dynamic allocation (every function that allocates takes an allocator as a parameter), which makes it much harder to hit the latency pitfalls common to Rust and C++. It also encourages the latency-optimal approach of using local bump-a-pointer arena allocators where possible rather than the slow global allocator. And finally, the superior metaprogramming support makes it more convenient to use high performance techniques like struct-of-arrays.
- lossolo 1y ago
  Your comment was corrected or written by ChatGPT, right? It's super interesting that I can recognize these things now. The specific usage of punctuation, certain words and sentence construction.
- pclmulqdq 1y ago
  Rusty rust and C++-y C++ are both often slower than hand-rolled C for a given function, and zig is intended to be a better way to hand-roll some C. C as a language is obsessed with the fact that C runs everywhere. Even on a DSP with a 24-bit char and a 24-bit int. If you take out those complexities and you add 40 years of lessons on language design, you can make something a lot simpler.
  - metaltyphoon 1y ago
    > Rusty rust and C++-y C++ are both often slower than hand-rolled C for a given function This makes no sense whatsoever and very far from the truth.
  - Arch-TK 1y ago
    Rusty rust? I don't think there is such a specific thing and certainly disagree that all idiomatic rust is somehow slower by default. You can write rust like you might write a higher level language and then that can end up slower but if you write idiomatic low level rust, the performance is much harder to compare with C. There are things which will be faster in C and things which will be faster in Rust but broadly things will be extremely similar in performance. I write bare metal embedded rust a lot these days and there are quite complex concepts you can represent in rust which make your code a lot safer without a performance hit.
    - pclmulqdq 1y ago
      Idiomatic "low level" rust clocks in at about 10-50% slower than hand-coded C every time I try it. It is also about 10x easier to write the Rust code. Unsafe is just required a lot of the time. Sometimes it's code size or struct size just being larger to express a similar concept. To get back your performance you have to do things that are un-idiomatic (but you have to do in C anyway).
      - Arch-TK 1y ago
        Show examples please.
      - simonask 1y ago
        That is an unbelievable claim. 1. Rust structs are generally smaller due to layout optimization. 2. A 10-50% difference is well within the “are you measuring debug builds?” territory. I’m curious what code you are writing that requires unsafe all the time? I do a lot of low-level optimization, and unsafe is barely ever actually needed.
        pclmulqdq 1y ago
        It sounds like you work with people who don't really know C. Understanding how to pack a struct is a pretty basic skill. Write an optimized database or network stack without unsafe for me. https://benchmarksgame-team.pages.debian.net/benchmarksgame/fastest/rust-gcc.html https://benchmarksgame-team.pages.debian.net/benchmarksgame/...
- speed_spread 1y ago
  Safety not important in HFT? You'd better make sure those precious microseconds buy you enough to make up for when things go awry. Also, modern online gaming with microtransactions isn't something I'd entrust to "hold my beer" languages and gaming industry development practices.
  - Cloudef 1y ago
    > modern online gaming with microtransactions I don't think anyone should develop such games either
  - logicchains 1y ago
    >Safety not important in HFT? You'd better make sure those precious microseconds buy you enough to make up for when things go awry. Memory safety bugs are very rare in modern, well-written and tested C++. The key difference is that there are no adversarial inputs, while something like a browser or server needs to deal with potentially adversarial inputs, making absolute memory safety much more important (as even a single memory safety issue could be exploited).
  - clanky 1y ago
    Crashes from safety bugs are rare in HFT because they can replay years of data against code changes. For a strategy that trades in and out of positions quickly and is flat most of the time, it's also often not a big deal if the program crashes in the midst of running, as long as some technique has been arranged to cancel resting orders and alert a trader (who is generally monitoring the system's operations at all times). They're certainly not inclined to pursue safety at any expense of performance in their code.
- Validark 1y ago
  "Safety" is always important, and you can write safe software in Zig.
  - simonask 1y ago
    “Safety” as defined in the context of the Rust language - the absence of Undefined Behavior - is important 100% of the time. Without it, you are not writing programs in the language you think you are using. That’s a convoluted way to say that UB is much, much worse than you think. A C program with UB is not a C program, but something else.
    - kiitos 1y ago
      curious, where is the definition of "undefined behavior" for rust specified?
      - simonask 1y ago
        Here: https://doc.rust-lang.org/reference/behavior-considered-undefined.html https://doc.rust-lang.org/reference/behavior-considered-unde...
        kiitos 1y ago
        mmm, no, that's an explicitly incomplete list of informally-described observable behaviors that qualify as undefined -- which is fine and good! but quite far from a specification!
epcoa 1y ago
Zig’s undefined behavior story is not nearly as much of a minefield for one. That should be enough really. If you think the CPP is good enough for metaprogramming, I don’t know what to tell you either.
Cloudef 1y ago
For me its simply better C, and the stdlib is pretty well designed overall
ViewTrick1002 1y ago
Being the anti Rust alternative for people who has spent years/decades accumulating weird knowledge about the inner workings of C and/or C++ and maintain that being able to shoot your feet off at a distance when doing the wrong incantation is a critical feature to have. I’m ranting but based the Rust/Zig discussions here on HN and the number of segfault issues in the Bun repo there is a core of truth. https://github.com/oven-sh/bun/issues?q=Segfault https://github.com/oven-sh/bun/issues?q=Segfault
- latchkey 1y ago
  To be fair, nodejs has 36 open, 474 closed: https://github.com/nodejs/node/issues?q=Segfault https://github.com/nodejs/node/issues?q=Segfault
  - ViewTrick1002 1y ago
    Which is written in C/C++. Showing that Zig is not moving the needle on UB when a project becomes sufficiently complex. Take a look at Deno and check the percentage coming from FFI with unsafe languages. https://github.com/denoland/deno/issues?q=Segfault https://github.com/denoland/deno/issues?q=Segfault
    - Jweb_Guru 1y ago
      People keep thinking that even though Microsoft, Apple, Google, etc. with all the incentive and tooling in the world couldn't evade one of the few replicable results in programming languages (people can't reliably write memory safe code in memory unsafe languages), somehow with Zig it will be different. It's honestly a pretty fascinating phenomenon to me because most of these people are smart, and some of them are even ostensibly in the security community.
      - lyu07282 1y ago
        We have language groupies now, like how teenagers have their favourite k-pop bands, I wouldn't take it all so seriously. Security has a tendency of making itself undeniable, it's lessons will be learned one way or another by everybody without exception.
ManBeardPc 1y ago
Like a modern C with lessons learned. Instead of macros it uses Zig itself to execute code at runtime (comptime). Custom allocators are the norm. No hidden control flow, everything is very explicit and easy to follow. But it’s not only the language itself, it is also the tooling around it. Single unit of compilation has some nice properties, allowing to support colorless async. Fast compile times. Being able to use existing C code easily and having optimization across language boundaries. Cross compilation out of the box. Generally caring for performance in all aspects. So for me it is a better C, low-level but still approachable and not having so much cruft.
- adgjlsfhk1 1y ago
  To be clear, the problem with C isn't macros, but text based macros. Syntax based macros are really good (as shown by Lisp and friends)
  - jeremyjh 1y ago
    To be clear, we all know GP is talking about C macros.
  - ManBeardPc 1y ago
    Not only being text based but also having another separate language is problematic. Rust also has powerful declarative macros but it is it’s own language. Procedural macros and crabtime are imho a bit better for more complex cases as you write Rust.
  - pron 1y ago
    AST macros are very powerful. As to them being "good", that's debatable. They have advantages but also disadvantages. For one, they operate on syntax, so they're a separate metalanguage and not so pleasant to debug. For another, they are referentially opaque (i.e. when passed different expressions with the same meaning, they can produce different results), which makes them powerful but also mysterious. What's interesting about Zig's comptime is that while it's strictly less powerful than AST macros, it can do a lot of what macros can do while not being a metalanguage - just Zig.
tliltocatl 1y ago
> Is it kind of like the Kotlin of C, going for a better syntax/modern features but otherwise being very similar? For me that sounds like a rather good value proposition. Too bad Zig never got the stackless corountine part they promised in the start.
bmacho 1y ago
Maybe read https://ziglang.org/ https://ziglang.org/ ? They list the goals: Zig is a general-purpose programming language and toolchain for maintaining robust, optimal and reusable software. and how they are trying to achieve that: simple language, and 'comptime' for metaprogramming (a more or less new approach). > Is it kind of like the Kotlin of C, going for a better syntax/modern features but otherwise being very similar? No, not really.
- LAC-Tech 1y ago
  I don't think it's a general-purpose programming language at all. Great systems language though.
  - tialaramex 1y ago
    Looks general purpose to me. What purposes couldn't you use Zig for? A general-purpose programming language isn't necessarily good for every purpose but it can be used. For example both Java and C are general purpose languages. Should you write an OS kernel in Java? Maybe that's unwise but people did. Should you write a web browser in C? Again unwise but people did. Some languages aren't like this. You can't write an OS kernel in WUFFS for example and that's on purpose, that's not what WUFFS is for.
pron 1y ago
It's a language that attempts to solve more of the biggest issues with low level programming than any other current low-level programming language. Of course, there is nowhere near a universal consensus on what the biggest issues are, but here's what they are to me in order of importance (and I'm not alone): 1. Language complexity/lack of expressivity. You want code, as much as possible, to clearly express the algorithm at the level of detail needed at the language's domain, no more and no less. The level of detail in low-level languages is different from high-level languages because, for example, you want to see exactly where and when memory is allocated/freed. Both C and C++ fail at this for opposite reasons. C is often not expressive enough to express an algorithm clearly (at least not without the use of macros), and C++ is often too implicit, hiding important details that are then easy to miss [1]. These problems may affect program correctness. 2. Lack of spatial memory safety, which is the cause of the #2 and #6 most dangerous software weaknesses (https://cwe.mitre.org/top25/archive/2024/2024_cwe_top25.html https://cwe.mitre.org/top25/archive/2024/2024_cwe_top25.html). Unlike spatial memory safety, Zig doesn't guarantee the lack of temporal memory safety. This would have been very nice to have, but it isn't as important and not worth compromising on the other top points. 3. Slow build times, which may also affect correctness by slowing down the test cycle. I don't find Zig similar to C or C++ at all (certainly not as similar as Rust is to C++). If anything, Zig's risk is in being a more revolutionary step than an evolutionary one. --- [1]: In the late eighties/early nineties (when I first learned C++), when we thought it might be a good idea for a language to be both low-level and high-level, C++'s notion of "zero-cost abstractions" seemed very interesting and even promising (I don't recall them being given that name then, but the problem - or advantage - was right there at the beginning; e.g. whether a call uses static or dynamic dispatch is an algorithmic detail that may be of interest in low-level programming, as well as whether a destructor is called, possibly through dynamic dispatch). Now that notion feels an outdated vestige of a bygone era. I'm aware there are still C++ programmers who still believe in writing high level applications in low-level languages and still believe in zero cost abstractions, but I think the industry has clearly been going the other way, and there's no indication it may be changing direction or may have any reason to do so.
- rollcat 1y ago
  > "zero-cost abstractions" I believe that in modern times, this term refers to stuff like: transparent conversion to a low-level representation (e.g. a bit-packed integer) from a high-level, statically checked datatype - e.g. a tagged union with exhaustive pattern matching, aka ADT. This is also something C++ etc lack.
giancarlostoro 1y ago
Check out Carbon, its the Kotlin of C++ ;) I am not a C++ guy, but when Carbon is finally stable and hits the mainstream, I will definitely start trying out Carbon. https://github.com/carbon-language/carbon-lang https://github.com/carbon-language/carbon-lang
- pjmlp 1y ago
  Everyone talking about Carbon has to remember it is foremost for Google's internal migration purposes.
Galanwe 1y ago
The way I see it, it's for people who want a more modern C, but not C++. There's not much languages in that space, essentially C3 and Zig, but the former is much less advanced IMHO (also in terms of tooling).
- scuff3d 1y ago
  Odin
  - Galanwe 1y ago
    I don't count Odin as a modern C, because it is IMHO too different syntaxically to fit that description.
    - scuff3d 1y ago
      I disagree. Maybe in syntax it's a bit different but in spirit I think it's absolutely a modern C. Purely procedural code and manually memory managed. On top of that Ginger Bills stated goal for the project is to basically grind down all the rough edges off C. Plus if you look at something like Zig, it syntactically starts to drift a lot as well. They left behind C's "use matches declaration" approach (thank God), capture groups look like nothing in C, function definitions are entirely different, the list goes on.
      - Galanwe 1y ago
        I mean, Odin is admittedly vastly different from C in terms of syntax. It's not like you can pick it up knowing C, it feels like a different language. The author even states that Odin started as a Pascal clone, and was more influenced by Pascal than C. > The language began as a Pascal clone (with begin and end and more) > The language borrows heavily from (in order of philosophy and impact): Pascal, C, Go, Oberon-2, Newsqueak, GLSL.
- user____name 1y ago
  C2 is still in development [0] and in my opinion sticks most closely to C in spirit. It seems like the best way to modernize a C project incrementally because it sticks most closely. I haven't tried any of these languages though, I genuinely enjoy writing dumb-as-bricks C despite all the downsides. Call it Stockholm Syndrome or whatever. [0] http://c2lang.org/site/introduction/evolution/ http://c2lang.org/site/introduction/evolution/
o11c 1y ago
Zig's pointless choice to avoid global constructors - something all platforms have supported for several decades by now - makes I/O extremely unwieldy. That alone prevents it from being a viable mainstream language. There is a lot of useful technical work and ideas in it though.
- deleted 1y ago
  [deleted]
epolanski 1y ago
Simpler, modern C with better tooling and less undefined behavior.
LAC-Tech 1y ago
The value proposition of Zig is it's the most ergonomic way to do systems programming I've ever seen. First class allocators, arbitrary width integer types, top notch bindings to OS syscalls in the std lib without relying on libc, and you can translate C bindings to Zig at compile time, so no FFI layers for existing libraries. They sometimes write about how they're a general purpose language, but I strongly disagree. It's unapologetically a systems programming language; that's it's entire focus.
pjmlp 1y ago
It is basically Modula-2 (in features) revamped with C syntax, and with compile time execution support. It is the route of what would have happened if Modula-2 or Object Pascal had won the industry mindshare instead of C. I think it comes too late, we know better nowadays, so it doesn't really offer anything new.

logicchains 1y ago

It's a powerful alternative to Rust and C++ for writing ultra low latency code when safety isn't important, like games or HFT. Its standard library and ecosystem have excellent support for passing around allocators and no hidden dynamic allocation (every function that allocates takes an allocator as a parameter), which makes it much harder to hit the latency pitfalls common to Rust and C++. It also encourages the latency-optimal approach of using local bump-a-pointer arena allocators where possible rather than the slow global allocator. And finally, the superior metaprogramming support makes it more convenient to use high performance techniques like struct-of-arrays.

lossolo 1y ago
Your comment was corrected or written by ChatGPT, right? It's super interesting that I can recognize these things now. The specific usage of punctuation, certain words and sentence construction.
pclmulqdq 1y ago
Rusty rust and C++-y C++ are both often slower than hand-rolled C for a given function, and zig is intended to be a better way to hand-roll some C. C as a language is obsessed with the fact that C runs everywhere. Even on a DSP with a 24-bit char and a 24-bit int. If you take out those complexities and you add 40 years of lessons on language design, you can make something a lot simpler.
- metaltyphoon 1y ago
  > Rusty rust and C++-y C++ are both often slower than hand-rolled C for a given function This makes no sense whatsoever and very far from the truth.
- Arch-TK 1y ago
  Rusty rust? I don't think there is such a specific thing and certainly disagree that all idiomatic rust is somehow slower by default. You can write rust like you might write a higher level language and then that can end up slower but if you write idiomatic low level rust, the performance is much harder to compare with C. There are things which will be faster in C and things which will be faster in Rust but broadly things will be extremely similar in performance. I write bare metal embedded rust a lot these days and there are quite complex concepts you can represent in rust which make your code a lot safer without a performance hit.
  - pclmulqdq 1y ago
    Idiomatic "low level" rust clocks in at about 10-50% slower than hand-coded C every time I try it. It is also about 10x easier to write the Rust code. Unsafe is just required a lot of the time. Sometimes it's code size or struct size just being larger to express a similar concept. To get back your performance you have to do things that are un-idiomatic (but you have to do in C anyway).
    - Arch-TK 1y ago
      Show examples please.
    - simonask 1y ago
      That is an unbelievable claim. 1. Rust structs are generally smaller due to layout optimization. 2. A 10-50% difference is well within the “are you measuring debug builds?” territory. I’m curious what code you are writing that requires unsafe all the time? I do a lot of low-level optimization, and unsafe is barely ever actually needed.
      - pclmulqdq 1y ago
        It sounds like you work with people who don't really know C. Understanding how to pack a struct is a pretty basic skill. Write an optimized database or network stack without unsafe for me. https://benchmarksgame-team.pages.debian.net/benchmarksgame/fastest/rust-gcc.html https://benchmarksgame-team.pages.debian.net/benchmarksgame/...
speed_spread 1y ago
Safety not important in HFT? You'd better make sure those precious microseconds buy you enough to make up for when things go awry. Also, modern online gaming with microtransactions isn't something I'd entrust to "hold my beer" languages and gaming industry development practices.
- Cloudef 1y ago
  > modern online gaming with microtransactions I don't think anyone should develop such games either
- logicchains 1y ago
  >Safety not important in HFT? You'd better make sure those precious microseconds buy you enough to make up for when things go awry. Memory safety bugs are very rare in modern, well-written and tested C++. The key difference is that there are no adversarial inputs, while something like a browser or server needs to deal with potentially adversarial inputs, making absolute memory safety much more important (as even a single memory safety issue could be exploited).
- clanky 1y ago
  Crashes from safety bugs are rare in HFT because they can replay years of data against code changes. For a strategy that trades in and out of positions quickly and is flat most of the time, it's also often not a big deal if the program crashes in the midst of running, as long as some technique has been arranged to cancel resting orders and alert a trader (who is generally monitoring the system's operations at all times). They're certainly not inclined to pursue safety at any expense of performance in their code.
Validark 1y ago
"Safety" is always important, and you can write safe software in Zig.
- simonask 1y ago
  “Safety” as defined in the context of the Rust language - the absence of Undefined Behavior - is important 100% of the time. Without it, you are not writing programs in the language you think you are using. That’s a convoluted way to say that UB is much, much worse than you think. A C program with UB is not a C program, but something else.
  - kiitos 1y ago
    curious, where is the definition of "undefined behavior" for rust specified?
    - simonask 1y ago
      Here: https://doc.rust-lang.org/reference/behavior-considered-undefined.html https://doc.rust-lang.org/reference/behavior-considered-unde...
      - kiitos 1y ago
        mmm, no, that's an explicitly incomplete list of informally-described observable behaviors that qualify as undefined -- which is fine and good! but quite far from a specification!

epcoa 1y ago

Zig’s undefined behavior story is not nearly as much of a minefield for one. That should be enough really. If you think the CPP is good enough for metaprogramming, I don’t know what to tell you either.

Cloudef 1y ago

For me its simply better C, and the stdlib is pretty well designed overall

ViewTrick1002 1y ago

Being the anti Rust alternative for people who has spent years/decades accumulating weird knowledge about the inner workings of C and/or C++ and maintain that being able to shoot your feet off at a distance when doing the wrong incantation is a critical feature to have. I’m ranting but based the Rust/Zig discussions here on HN and the number of segfault issues in the Bun repo there is a core of truth. https://github.com/oven-sh/bun/issues?q=Segfault https://github.com/oven-sh/bun/issues?q=Segfault

latchkey 1y ago
To be fair, nodejs has 36 open, 474 closed: https://github.com/nodejs/node/issues?q=Segfault https://github.com/nodejs/node/issues?q=Segfault
- ViewTrick1002 1y ago
  Which is written in C/C++. Showing that Zig is not moving the needle on UB when a project becomes sufficiently complex. Take a look at Deno and check the percentage coming from FFI with unsafe languages. https://github.com/denoland/deno/issues?q=Segfault https://github.com/denoland/deno/issues?q=Segfault
  - Jweb_Guru 1y ago
    People keep thinking that even though Microsoft, Apple, Google, etc. with all the incentive and tooling in the world couldn't evade one of the few replicable results in programming languages (people can't reliably write memory safe code in memory unsafe languages), somehow with Zig it will be different. It's honestly a pretty fascinating phenomenon to me because most of these people are smart, and some of them are even ostensibly in the security community.
    - lyu07282 1y ago
      We have language groupies now, like how teenagers have their favourite k-pop bands, I wouldn't take it all so seriously. Security has a tendency of making itself undeniable, it's lessons will be learned one way or another by everybody without exception.

ManBeardPc 1y ago

Like a modern C with lessons learned. Instead of macros it uses Zig itself to execute code at runtime (comptime). Custom allocators are the norm. No hidden control flow, everything is very explicit and easy to follow. But it’s not only the language itself, it is also the tooling around it. Single unit of compilation has some nice properties, allowing to support colorless async. Fast compile times. Being able to use existing C code easily and having optimization across language boundaries. Cross compilation out of the box. Generally caring for performance in all aspects. So for me it is a better C, low-level but still approachable and not having so much cruft.

adgjlsfhk1 1y ago
To be clear, the problem with C isn't macros, but text based macros. Syntax based macros are really good (as shown by Lisp and friends)
- jeremyjh 1y ago
  To be clear, we all know GP is talking about C macros.
- ManBeardPc 1y ago
  Not only being text based but also having another separate language is problematic. Rust also has powerful declarative macros but it is it’s own language. Procedural macros and crabtime are imho a bit better for more complex cases as you write Rust.
- pron 1y ago
  AST macros are very powerful. As to them being "good", that's debatable. They have advantages but also disadvantages. For one, they operate on syntax, so they're a separate metalanguage and not so pleasant to debug. For another, they are referentially opaque (i.e. when passed different expressions with the same meaning, they can produce different results), which makes them powerful but also mysterious. What's interesting about Zig's comptime is that while it's strictly less powerful than AST macros, it can do a lot of what macros can do while not being a metalanguage - just Zig.

tliltocatl 1y ago

> Is it kind of like the Kotlin of C, going for a better syntax/modern features but otherwise being very similar? For me that sounds like a rather good value proposition. Too bad Zig never got the stackless corountine part they promised in the start.

bmacho 1y ago

Maybe read https://ziglang.org/ https://ziglang.org/ ? They list the goals: Zig is a general-purpose programming language and toolchain for maintaining robust, optimal and reusable software. and how they are trying to achieve that: simple language, and 'comptime' for metaprogramming (a more or less new approach). > Is it kind of like the Kotlin of C, going for a better syntax/modern features but otherwise being very similar? No, not really.

LAC-Tech 1y ago
I don't think it's a general-purpose programming language at all. Great systems language though.
- tialaramex 1y ago
  Looks general purpose to me. What purposes couldn't you use Zig for? A general-purpose programming language isn't necessarily good for every purpose but it can be used. For example both Java and C are general purpose languages. Should you write an OS kernel in Java? Maybe that's unwise but people did. Should you write a web browser in C? Again unwise but people did. Some languages aren't like this. You can't write an OS kernel in WUFFS for example and that's on purpose, that's not what WUFFS is for.

pron 1y ago

It's a language that attempts to solve more of the biggest issues with low level programming than any other current low-level programming language. Of course, there is nowhere near a universal consensus on what the biggest issues are, but here's what they are to me in order of importance (and I'm not alone): 1. Language complexity/lack of expressivity. You want code, as much as possible, to clearly express the algorithm at the level of detail needed at the language's domain, no more and no less. The level of detail in low-level languages is different from high-level languages because, for example, you want to see exactly where and when memory is allocated/freed. Both C and C++ fail at this for opposite reasons. C is often not expressive enough to express an algorithm clearly (at least not without the use of macros), and C++ is often too implicit, hiding important details that are then easy to miss [1]. These problems may affect program correctness. 2. Lack of spatial memory safety, which is the cause of the #2 and #6 most dangerous software weaknesses (https://cwe.mitre.org/top25/archive/2024/2024_cwe_top25.html https://cwe.mitre.org/top25/archive/2024/2024_cwe_top25.html). Unlike spatial memory safety, Zig doesn't guarantee the lack of temporal memory safety. This would have been very nice to have, but it isn't as important and not worth compromising on the other top points. 3. Slow build times, which may also affect correctness by slowing down the test cycle. I don't find Zig similar to C or C++ at all (certainly not as similar as Rust is to C++). If anything, Zig's risk is in being a more revolutionary step than an evolutionary one. --- [1]: In the late eighties/early nineties (when I first learned C++), when we thought it might be a good idea for a language to be both low-level and high-level, C++'s notion of "zero-cost abstractions" seemed very interesting and even promising (I don't recall them being given that name then, but the problem - or advantage - was right there at the beginning; e.g. whether a call uses static or dynamic dispatch is an algorithmic detail that may be of interest in low-level programming, as well as whether a destructor is called, possibly through dynamic dispatch). Now that notion feels an outdated vestige of a bygone era. I'm aware there are still C++ programmers who still believe in writing high level applications in low-level languages and still believe in zero cost abstractions, but I think the industry has clearly been going the other way, and there's no indication it may be changing direction or may have any reason to do so.

rollcat 1y ago
> "zero-cost abstractions" I believe that in modern times, this term refers to stuff like: transparent conversion to a low-level representation (e.g. a bit-packed integer) from a high-level, statically checked datatype - e.g. a tagged union with exhaustive pattern matching, aka ADT. This is also something C++ etc lack.

giancarlostoro 1y ago

Check out Carbon, its the Kotlin of C++ ;) I am not a C++ guy, but when Carbon is finally stable and hits the mainstream, I will definitely start trying out Carbon. https://github.com/carbon-language/carbon-lang https://github.com/carbon-language/carbon-lang

pjmlp 1y ago
Everyone talking about Carbon has to remember it is foremost for Google's internal migration purposes.

Galanwe 1y ago

The way I see it, it's for people who want a more modern C, but not C++. There's not much languages in that space, essentially C3 and Zig, but the former is much less advanced IMHO (also in terms of tooling).

scuff3d 1y ago
Odin
- Galanwe 1y ago
  I don't count Odin as a modern C, because it is IMHO too different syntaxically to fit that description.
  - scuff3d 1y ago
    I disagree. Maybe in syntax it's a bit different but in spirit I think it's absolutely a modern C. Purely procedural code and manually memory managed. On top of that Ginger Bills stated goal for the project is to basically grind down all the rough edges off C. Plus if you look at something like Zig, it syntactically starts to drift a lot as well. They left behind C's "use matches declaration" approach (thank God), capture groups look like nothing in C, function definitions are entirely different, the list goes on.
    - Galanwe 1y ago
      I mean, Odin is admittedly vastly different from C in terms of syntax. It's not like you can pick it up knowing C, it feels like a different language. The author even states that Odin started as a Pascal clone, and was more influenced by Pascal than C. > The language began as a Pascal clone (with begin and end and more) > The language borrows heavily from (in order of philosophy and impact): Pascal, C, Go, Oberon-2, Newsqueak, GLSL.
user____name 1y ago
C2 is still in development [0] and in my opinion sticks most closely to C in spirit. It seems like the best way to modernize a C project incrementally because it sticks most closely. I haven't tried any of these languages though, I genuinely enjoy writing dumb-as-bricks C despite all the downsides. Call it Stockholm Syndrome or whatever. [0] http://c2lang.org/site/introduction/evolution/ http://c2lang.org/site/introduction/evolution/

o11c 1y ago

Zig's pointless choice to avoid global constructors - something all platforms have supported for several decades by now - makes I/O extremely unwieldy. That alone prevents it from being a viable mainstream language. There is a lot of useful technical work and ideas in it though.

deleted 1y ago
[deleted]

epolanski 1y ago

Simpler, modern C with better tooling and less undefined behavior.

LAC-Tech 1y ago

The value proposition of Zig is it's the most ergonomic way to do systems programming I've ever seen. First class allocators, arbitrary width integer types, top notch bindings to OS syscalls in the std lib without relying on libc, and you can translate C bindings to Zig at compile time, so no FFI layers for existing libraries. They sometimes write about how they're a general purpose language, but I strongly disagree. It's unapologetically a systems programming language; that's it's entire focus.

pjmlp 1y ago

It is basically Modula-2 (in features) revamped with C syntax, and with compile time execution support. It is the route of what would have happened if Modula-2 or Object Pascal had won the industry mindshare instead of C. I think it comes too late, we know better nowadays, so it doesn't really offer anything new.