5 ms·

I like Zig but it seems to just keep redesigning itself, while other languages like Odin “shipped” long ago and don’t seem to need to look back. Is Zig sufferin

by brabel 1y ago

I like Zig but it seems to just keep redesigning itself, while other languages like Odin “shipped” long ago and don’t seem to need to look back. Is Zig suffering from perfectionism syndrome where things are never good enough??

silisili 1y ago
That's kinda my experience with watching Zig. It went from 'look how simple this is' to 'look at this new feature syntax' long ago. People used to compare it as simpler than Rust. I don't agree that it's simple anymore at all. None of this is meant to be badmouthing or insulting. I'm a polyglot but love simple languages and syntaxes, so I tend to overly notice such things.
- Laremere 1y ago
  The computer is a machine, and modern ones are complicated. When I am programming, I want to precisely control that machine. For me, simplicity is measured in how complicated it is to get the machine to do what I want it to do. So, eg, having several different operators for adding two integers sounds complicated. However there is simplicity in not having to reach far to actually get the correct behavior, and there is some simplicity in the process of being forced to make that choice as it irons about what behavior you actually want.
  - silisili 1y ago
    I think that's long been the argument of simplicity. 'Simple to remember' vs 'simple to perform.' I tend to fall into the former camp. Something like BF would be the ultimate simple language, even if not particularly useful.
    - lewdwig 1y ago
      Structured concurrency is a notoriously hard problem. This is part of Zig’s 4th attempt to get it right.
- raincole 1y ago
  Rust will be (already became?) as complex as C++, if not more. Zig will be as complex as early rust. It's like a force of nature.
  - tialaramex 1y ago
    How do you figure Rust is "as complex as C++" ?
    - pjmlp 1y ago
      I guess, two macro systems, ML type system, affine types, crates using nightly features, having a hard time keeping up with every six weeks feature drops.
      - tialaramex 1y ago
        I get two macro systems, but a coherent type system seems simpler to understand. The existence of "regular void" proposals seems to underscore that the "easy" C type system's incoherence doesn't end up being easy to work with or reason about. And I don't see "crates using nightly features" as somehow a language complexity. Are we counting "Three different compilers with their own quirks" as a C++ complexity? Nor is the six week cadence a complexity. When naked functions stabilized a handful of people went "Hooray" and nearly everybody else doesn't care. And that's not even a feature in standard C++. You have to go read your vendor instructions and do it separately each time. "Yay!".
        pjmlp 1y ago
        I like both languages, those are the issues where I see someone looking from outside and having such complexity claim as the OP. The ecosystem is part of what means to use a specific language, though. Yeah, having to guess what standards and extensions each C and C++ compiler implement, is also an issue with them, and will eventually come to Rust as implementations eventually come up, originally there was only CFront and UNIX System V compilers.
- throwawaymaths 1y ago
  the only two new feature syntaxes in about six releases have been multiple iterations in for loops and continue in switches? maybe reified tuple types too (not just implicit) and destructuring tuples. a few things have been removed, too. and async/suspend/nosuspend/await, usingnamesplace are headed for the woodchipper.
kuon 1y ago
I'd say it is taking some serious design decision for like the 30 years to come, so I am happy it breaks things now. I wish it moved to snake_case for functions, this is a cosmetic detail but it drives me crazy.
- pjmlp 1y ago
  If I look to how I was programming in 1986, and how I am programming now, it is too much hope to have such a design goal, especially since most likely there is little Zig has to add to quantum and AI based systems.
  - lionkor 1y ago
    This feels out of touch with the actual industry today.
    - pjmlp 1y ago
      Out of touch is assuming that a programming language with zero touch points with AI tooling is going to be relevant in a AI driven industry.
      - lionkor 1y ago
        What is "AI tooling"?
        pjmlp 1y ago
        Ask Chat GPT, Claude or Gemini.
cornstalks 1y ago
I’m glad they are taking their time. They’ve made solid improvements and I don’t think get the sense that they’re paralyzed with perfectionism. They’re not rushing, that’s for sure. But I’ve never felt worried about 1.0 never happening in an unending pursuit of unrealistic impossible ideals.
- vendiddy 1y ago
  They've been pretty explicit about their goals in not settling for a local optimum in the language and taking their time. It seems like folks expect stability pre 1.0.
pjmlp 1y ago
Looks like it, while at the same time still lacks any killer application that would make learning Zig a requirement, regardless of one's opinion on the language, like it already happened with many others now in mainstream. So where is Zig's OS, browser, docker, engine, security, whatever XYZ, that would make having Zig on the toolbox a requirement? I don't see Bun nor Tiger Beetle being that app.
- lionkor 1y ago
  The killer application case is slow adoption inside ancient C and C++ codebases. That's the angle.
  - pjmlp 1y ago
    It hardly brings anything new to the table in such cases, given its approach to safety. Most of it you can already get in C and C++, by using the tools that have in the market for the last 30 years.
    - lewdwig 1y ago
      And yet C/C++ developers have mostly spent the last 30 years not using those tools which is why safer successors to C and C++ appeared.
      - detaro 1y ago
        I think pjmlps point is that Zig is not adding enough to be one of those safer successors.
      - pjmlp 1y ago
        Zig is as safe as Modula-2 or Object Pascal, not the turning point of something like Swift or Rust.
    - lionkor 1y ago
      It brings a lot of nice features, the potential for a healthier ecosystem, a unified build system, explicit allocators, explicit casts, and so on.
audunw 1y ago
This is a standard library change, not a syntax change I think the main big thing that’s left for 1.0 is to resurrect async/await.. and that’s a huge thing because arguably very few if any language has gotten that truly right. As the PR description mentions: “This is part of a series of changes leading up to "I/O as an Interface" and Async/Await Resurrection.” So this work is partially related to getting async/await right. And getting IO right is a very important part of that. I think it’s a good idea for Zig to try to avoid a Python 3 situation after they reach 1.0. The project seems fairly focused to me, but they’re trying to solve some difficult problems. And they spend more time working on the compiler and compiler infrastructure than other languages, which is also good. Working on their own backend is actually critical for the language itself, because part of what’s holding Zig back from doing async right is limitations and flaws in LLVM
- dosshell 1y ago
  >> because part of what’s holding Zig back from doing async right is limitations and flaws in LLVM this was interesting! Do you have a link or something to be able to read about it?
  - audunw 1y ago
    Much of the discussion is buried in the various GitHub issues related to async. I found something of a summary in this Reddit comment https://www.reddit.com/r/Zig/comments/1d66gtp/comment/l6umbta/?utm_source=share&utm_medium=mweb3x&utm_name=mweb3xcss&utm_term=1&utm_content=share_button https://www.reddit.com/r/Zig/comments/1d66gtp/comment/l6umbt...
  - throwawaymaths 1y ago
    iirc the llvm async operation does heap allocations?
- travisgriggs 1y ago
  > I think the main big thing that’s left for 1.0 is to resurrect async/await.. and that’s a huge thing because arguably very few if any language has gotten that truly right. Interesting. I like Zig. I dabble periodically. I’m hoping that maturity and our next generation ag tech device in a few years might intersect. Throwing another colored function debacle in a language, replete with yet another round of the familiar but defined slightly differently keywords, would be a big turn off for me. I don’t even know if Grand Central Dispatch counts, but it—and of course Elixir/Erlang—are the only two “on beyond closures/callbacks” asynch system I’ve found worked well.
thelastbender12 1y ago
Sorry, I think this comparison is just unfair. Odin might have "shipped" but are there are any projects with significant usage built on it? I can count at least 3 with Zig - Ghostty, Tigerbeetle, and Bun. Programming languages which do get used are always in flux, for good reason - python is still undergoing major changes (free-threading, immutability, and others), and I'm grateful for it.
- LukaD 1y ago
  All the JangaFX products (such as EmberGen) are written in Odin.
  - thelastbender12 1y ago
    Thank you, my bad - I wasn't aware. I still think what drives languages to continuously make changes is the focus on developer UX, or at least the intent to make it better. So, PLs with more developers will always keep evolving.
- dismalaf 1y ago
  > Odin might have "shipped" but are there are any projects with significant usage built on it? JangaFX stuff is written in Odin and has some pretty big users. https://jangafx.com/ https://jangafx.com/ https://odin-lang.org/showcase/ https://odin-lang.org/showcase/
bvrmn 1y ago
Odin's IO is quite messy. I have strong feeling it evolved as an adhoc solution to tackle development requirements without much thought. I'm happy Andy wants to fix high level (and very important) interfaces while being in pre 1.0.

by brabel 1y ago

silisili 1y ago

That's kinda my experience with watching Zig. It went from 'look how simple this is' to 'look at this new feature syntax' long ago. People used to compare it as simpler than Rust. I don't agree that it's simple anymore at all. None of this is meant to be badmouthing or insulting. I'm a polyglot but love simple languages and syntaxes, so I tend to overly notice such things.

Laremere 1y ago
The computer is a machine, and modern ones are complicated. When I am programming, I want to precisely control that machine. For me, simplicity is measured in how complicated it is to get the machine to do what I want it to do. So, eg, having several different operators for adding two integers sounds complicated. However there is simplicity in not having to reach far to actually get the correct behavior, and there is some simplicity in the process of being forced to make that choice as it irons about what behavior you actually want.
- silisili 1y ago
  I think that's long been the argument of simplicity. 'Simple to remember' vs 'simple to perform.' I tend to fall into the former camp. Something like BF would be the ultimate simple language, even if not particularly useful.
  - lewdwig 1y ago
    Structured concurrency is a notoriously hard problem. This is part of Zig’s 4th attempt to get it right.
raincole 1y ago
Rust will be (already became?) as complex as C++, if not more. Zig will be as complex as early rust. It's like a force of nature.
- tialaramex 1y ago
  How do you figure Rust is "as complex as C++" ?
  - pjmlp 1y ago
    I guess, two macro systems, ML type system, affine types, crates using nightly features, having a hard time keeping up with every six weeks feature drops.
    - tialaramex 1y ago
      I get two macro systems, but a coherent type system seems simpler to understand. The existence of "regular void" proposals seems to underscore that the "easy" C type system's incoherence doesn't end up being easy to work with or reason about. And I don't see "crates using nightly features" as somehow a language complexity. Are we counting "Three different compilers with their own quirks" as a C++ complexity? Nor is the six week cadence a complexity. When naked functions stabilized a handful of people went "Hooray" and nearly everybody else doesn't care. And that's not even a feature in standard C++. You have to go read your vendor instructions and do it separately each time. "Yay!".
      - pjmlp 1y ago
        I like both languages, those are the issues where I see someone looking from outside and having such complexity claim as the OP. The ecosystem is part of what means to use a specific language, though. Yeah, having to guess what standards and extensions each C and C++ compiler implement, is also an issue with them, and will eventually come to Rust as implementations eventually come up, originally there was only CFront and UNIX System V compilers.
throwawaymaths 1y ago
the only two new feature syntaxes in about six releases have been multiple iterations in for loops and continue in switches? maybe reified tuple types too (not just implicit) and destructuring tuples. a few things have been removed, too. and async/suspend/nosuspend/await, usingnamesplace are headed for the woodchipper.

kuon 1y ago

I'd say it is taking some serious design decision for like the 30 years to come, so I am happy it breaks things now. I wish it moved to snake_case for functions, this is a cosmetic detail but it drives me crazy.

pjmlp 1y ago
If I look to how I was programming in 1986, and how I am programming now, it is too much hope to have such a design goal, especially since most likely there is little Zig has to add to quantum and AI based systems.
- lionkor 1y ago
  This feels out of touch with the actual industry today.
  - pjmlp 1y ago
    Out of touch is assuming that a programming language with zero touch points with AI tooling is going to be relevant in a AI driven industry.
    - lionkor 1y ago
      What is "AI tooling"?
      - pjmlp 1y ago
        Ask Chat GPT, Claude or Gemini.

cornstalks 1y ago

I’m glad they are taking their time. They’ve made solid improvements and I don’t think get the sense that they’re paralyzed with perfectionism. They’re not rushing, that’s for sure. But I’ve never felt worried about 1.0 never happening in an unending pursuit of unrealistic impossible ideals.

vendiddy 1y ago
They've been pretty explicit about their goals in not settling for a local optimum in the language and taking their time. It seems like folks expect stability pre 1.0.

pjmlp 1y ago

Looks like it, while at the same time still lacks any killer application that would make learning Zig a requirement, regardless of one's opinion on the language, like it already happened with many others now in mainstream. So where is Zig's OS, browser, docker, engine, security, whatever XYZ, that would make having Zig on the toolbox a requirement? I don't see Bun nor Tiger Beetle being that app.

lionkor 1y ago
The killer application case is slow adoption inside ancient C and C++ codebases. That's the angle.
- pjmlp 1y ago
  It hardly brings anything new to the table in such cases, given its approach to safety. Most of it you can already get in C and C++, by using the tools that have in the market for the last 30 years.
  - lewdwig 1y ago
    And yet C/C++ developers have mostly spent the last 30 years not using those tools which is why safer successors to C and C++ appeared.
    - detaro 1y ago
      I think pjmlps point is that Zig is not adding enough to be one of those safer successors.
    - pjmlp 1y ago
      Zig is as safe as Modula-2 or Object Pascal, not the turning point of something like Swift or Rust.
  - lionkor 1y ago
    It brings a lot of nice features, the potential for a healthier ecosystem, a unified build system, explicit allocators, explicit casts, and so on.

audunw 1y ago

This is a standard library change, not a syntax change I think the main big thing that’s left for 1.0 is to resurrect async/await.. and that’s a huge thing because arguably very few if any language has gotten that truly right. As the PR description mentions: “This is part of a series of changes leading up to "I/O as an Interface" and Async/Await Resurrection.” So this work is partially related to getting async/await right. And getting IO right is a very important part of that. I think it’s a good idea for Zig to try to avoid a Python 3 situation after they reach 1.0. The project seems fairly focused to me, but they’re trying to solve some difficult problems. And they spend more time working on the compiler and compiler infrastructure than other languages, which is also good. Working on their own backend is actually critical for the language itself, because part of what’s holding Zig back from doing async right is limitations and flaws in LLVM

dosshell 1y ago
>> because part of what’s holding Zig back from doing async right is limitations and flaws in LLVM this was interesting! Do you have a link or something to be able to read about it?
- audunw 1y ago
  Much of the discussion is buried in the various GitHub issues related to async. I found something of a summary in this Reddit comment https://www.reddit.com/r/Zig/comments/1d66gtp/comment/l6umbta/?utm_source=share&utm_medium=mweb3x&utm_name=mweb3xcss&utm_term=1&utm_content=share_button https://www.reddit.com/r/Zig/comments/1d66gtp/comment/l6umbt...
- throwawaymaths 1y ago
  iirc the llvm async operation does heap allocations?
travisgriggs 1y ago
> I think the main big thing that’s left for 1.0 is to resurrect async/await.. and that’s a huge thing because arguably very few if any language has gotten that truly right. Interesting. I like Zig. I dabble periodically. I’m hoping that maturity and our next generation ag tech device in a few years might intersect. Throwing another colored function debacle in a language, replete with yet another round of the familiar but defined slightly differently keywords, would be a big turn off for me. I don’t even know if Grand Central Dispatch counts, but it—and of course Elixir/Erlang—are the only two “on beyond closures/callbacks” asynch system I’ve found worked well.

thelastbender12 1y ago

Sorry, I think this comparison is just unfair. Odin might have "shipped" but are there are any projects with significant usage built on it? I can count at least 3 with Zig - Ghostty, Tigerbeetle, and Bun. Programming languages which do get used are always in flux, for good reason - python is still undergoing major changes (free-threading, immutability, and others), and I'm grateful for it.

LukaD 1y ago
All the JangaFX products (such as EmberGen) are written in Odin.
- thelastbender12 1y ago
  Thank you, my bad - I wasn't aware. I still think what drives languages to continuously make changes is the focus on developer UX, or at least the intent to make it better. So, PLs with more developers will always keep evolving.
dismalaf 1y ago
> Odin might have "shipped" but are there are any projects with significant usage built on it? JangaFX stuff is written in Odin and has some pretty big users. https://jangafx.com/ https://jangafx.com/ https://odin-lang.org/showcase/ https://odin-lang.org/showcase/

bvrmn 1y ago

Odin's IO is quite messy. I have strong feeling it evolved as an adhoc solution to tackle development requirements without much thought. I'm happy Andy wants to fix high level (and very important) interfaces while being in pre 1.0.