I always felt that Python's "There should be one-- and preferably only one --obvious way to do it." was a bit of a mess.
Obviously (to anyone who was around at the time), that plank was written in response to Perl's motto: "There is more than one way to do it."
Zig's original take on this, "Only one obvious way to do things" seems even worse. You see, both languages agree that Perl had it wrong: it is unhelpful to have several different ways to write any future. But they went a little too far: it is not actually bad for it to be possible to write the same thing in more than one way.
Zig's new phrasing: "There is an idiomatic way to do it." captures the CORRECT alternative to Perl's motto. It is not important that there be no alternative ways of writing something, Rather, it is important that there be a single idiomatic way to write it.
This is a losing proposition.
Because just like in Python, it may also generate endless debates on "ok, but what exactly is the idiomatic way for this particular thing here"? Is it A, or B, or maybe C? Since many are always possible, each optimizing for slightly different things, like simplicity, or maintainability, or performance, or readability, or coverage, etc. Groups may form furiously asserting that the idiomatic way must be C, others defending B, or A, and for what. Why does it matter? A young language free from cruft, after a long history of various decisions that led it on certain paths, can boldly claim such nonsense, but makes one wonder how it may look in 30 or 40 years, when other languages/ecosystems will point at its mistakes.
Arguably Perl had it right all along, it's just a simple fact of life, expressed in such a generic manner that there is no need to fight it, since it's obviously true. Python's retort at the time was just clever marketing (aka lies), that worked (fooled a lot of people), it targeted Perl specifically just because that was the main competition back then.
I think people criticize that line in the zen of Python because Python has now become very maximalist. On it's own merits, I think "There should be one obvious way to do it" is much better, less clunky, than "There is an idiomatic way to do it".
Also, importantly, the Zen of Python is kinda written as a set of ideas that Python should aspire to ("there should be one obvious way to do it") instead of a sales pitch of Python's merits. I prefer that.
It all sounds great until someone writes nested list comprehensions. They are the recommended, idiomatic way to things most sane people would use ‘map’, ‘filter’, and ‘reduce’ chains, although chains are another thing python very much dislikes.
I always read this as a tongue in cheek joke b/c of how the — appears left aligned, then right aligned, then elsewhere in the Zen center aligned, sort of pointing to how yeah there’s multiple ways to do things …
Yeah, I actually don't care how other people program in the languages I'm using. Give me all the ways to do things. I'll make my own choices, thank you.
Someone cooked up a language just like this ages ago, and today it's one of the most popular languages on the planet! Unfortunately, in modern times people don't like to write/code in this language, so they built some beast on top of it which is the de facto standard right now. But you can still write JavaScript, and you can avoid all the shit parts like "classes" and what not, do classic prototype-style programming, or even layer your own functional/OOP programming on top. Not much you cannot do in JavaScript, probably only a lisp would enable more programming paradigms, but for mainstream languages, it's as close as you can get to True Freedom.
Glad to see "Together we serve the users" come back. I miss the old Zig readme that said Zig comes with an MIT license and a humble request to build software that serves the users.
Yes it can. But it's nearly impossible to handle such cases properly. That's why checking each allocation manually is a bad idea. Other languages do this better - they provide nice abstractions, but if something fails, the language runtime terminates the process. The result is the same, but has much less friction.
Also on some systems (like Linux) memory allocation may not fail, but the "allocated" memory may not be available and a program can crash accessing this memory.
Zig is in the space of languages where an abstraction that decides that memory allocations are irrecoverable is not good enough.
If you work in an environment where memory allocations can't fail or can't be handled if they fail, you might not want to use Zig, or C for that matter. Not every language should be designed to live in the space of "somehow low level but also a good choice for your basic web backend", like Rust.
Rust doesn't stop you from checking if memory allocation has failed. Its libstd provides many operations that don't bother to surface memory allocation failure (for the reasons given above), but that's why Rust provides a libcore that does no allocation, while continually working to push more things down from libstd into libcore, while providing alternative APIs in libstd to let you handle allocation failure if you know you actually need to.
Conversely, Rust doesn't force you to explicitly handle if memory allocation failures. The least you can do in Zig is explicitly ignore allocation failures.
You can certainly write data structures in Zig that swallow allocation failures rather than surfacing them. We're talking about library-level concerns, not language-level concerns. Both Rust and Zig give you the power to allocate raw memory and handle the result of that syscall however you want, it's the standard libraries that differ beyond that point.
Yes, it is a standard library difference. But unless you plan on rewriting the entire Rust ecosystem, you're going to be dealing with invisible failure points in Rust code that you would not be dealing with when writing the equivalent Zig code. The standard library is almost as fundamentally important to a language as it's built-in operators.
And Zig does have language-level features that combine to require you to explicitly handle propagated errors (error sets, requiring all return values be explicitly handled, requiring all switch cases be explicitly handled). Rust has a similar set of features (pattern matching, requiring all match cases be explicitly handled), but does not use them for allocation (Box::new, vec![], etc. does not return a Result value).
> If you work in an environment where memory allocations can't fail or can't be handled if they fail, you might not want to use Zig,
It's most of environments. Basically any program running under a modern OS. So, why do this language exists, if its practical applicability is so small?
This language exists so you can reuse the same code in environments where memory allocations may fail, and where memory allocations can't fail.
Let's say you write an application that runs as a Unix daemon in Zig. Later you may decide that your application is really the only thing you're interested in running on the target machine, and for performance and predictability reasons, you'd prefer to boot directly to your application, instead of to an OS that launches your daemon. You can just swap out the implementation of the std.Io runtime for one that targets the hardware directly, instead of a Unix. You don't have to make any changes to your application.
That's kind of an extreme case, but it's the kind of flexibility Zig provides.
> This language exists so you can reuse the same code in environments where memory allocations may fail, and where memory allocations can't fail.
In my hypothetical example of a language where allocation fails aren't exposed it's possible too. An allocation fail just triggers a full system reboot.
> On modern OSs you can write Zig and just ignore allocation errors.
I can ignore errors, but I still need to free memory manually if I want to avoid memory leaks. Languages like C++ or Rust have destructors, which do the job for me.
> This language exists to supercede or supplement C
There are way better alternatives, like Rust. Even C++ is better.
* There are many useful ways to handle it properly, and your choice depends on your program's constraints. The very small amount of friction (once you're used to it) encourages you to consider what ways to handle it are viable, such as allocating all memory at startup.
* If your strategy is to crash immediately, there is very little additional friction but you get the benefit of it being obvious in your code that this is the case.
* There are environments where memory allocation fails immediately, including if you turn off over-commit on Linux. If your hardware is dedicated to running a high reliability system, configuring it in this way is reasonable.
* Memory is not the only resource. Indeed, removing the special call out is what changed here. That different resources are handled with the same mechanism (errors, instead of eg returning null from malloc) is good.
Autors of Zig did a choice for me. I can't use RAII in it. In C++ it's better - when I don't care, I just use standard library containers, when I do care, I can bypass them.
You might have a limited budget per incoming request in a http server for example. Then you want all of the code that http handler calls to be able to handle an error of type something like OutOfMemory.
This is a very good ability to have in an application like a database.
Such things should be solved in more nice way, not by manually checking every allocation. Like via lightweight threads, with each of them having their own memory and a scheduler, which kills threads exceeding their memory limit.
This compilicates things more compared to functions returning Result<>.
You also get locality benefits from bump style allocators. And you don't need SmallVec or similar optimization containers. And you also avoid mental overhead of managing many allocations in your head (or using a language with borrow checking).
Nearly impossible in some contexts, where the trade-off makes sense.
There are many scenarios, especially in embedded systems, where it can happen and you want to handle it robustly, e.g. by evicting a cache or flushing a buffer to disk.
In embedded systems you have enough control. But as soon as an OS is involved, you have much less control. Basically an OS may do with your process whatever it wants, but it happens to be polite most of the time.
the maintainers seem happy, especially now that CI is actually working how it's supposed to. but a non-rare complaint in the Zig discord is how slow Codeberg can be, and other things like the lack of codesearch hurt as well.
I saw what changed syntactically. I meant I don't really understand what changed semantically. And whether there is any context to why the change was necessary.
I'm guessing the parent is wondering why this is noteworthy enough to be posted and discussed in this thread, and so if there's context they are missing
I recommend you to watch Andrew Kelly interview[0], while I'm not the target audience of Zig, I don't see him driving away any user. Also Jai as for now is a non existing language, just a selected few has access to it, but Jai approach is a kitchen sink, from what I saw it is all over the place in terms of features, now Zig vision feels cohesive.
Activism as in their move away from GitHub? Andrew K recently said in the JetBrains interview that because of moving away, their CI/CD now actually works.
I think they banned AI and moved from GitHub to Codeberg. They don't seem too controversial to me, and IMO they've already comprehensively trounced Odin, Jai and C3.
Jai isn't even available publicly. The license isn't decided. Jonathan Blow doesn't want to deal with open source.
Comparing Jai and Zig on that behalf is crazy.
Edit: If that is about political activism it's even more crazy. A dude that rambles about woke stuff is political as well. Maybe just aligns with yours.
Excuse me, but I think zig grows ever better from driving away users who are driven away by flashy headlines and whatever is the opposite of this “activism” you suggest.
Nicely done!
I always felt that Python's "There should be one-- and preferably only one --obvious way to do it." was a bit of a mess.
Obviously (to anyone who was around at the time), that plank was written in response to Perl's motto: "There is more than one way to do it."
Zig's original take on this, "Only one obvious way to do things" seems even worse. You see, both languages agree that Perl had it wrong: it is unhelpful to have several different ways to write any future. But they went a little too far: it is not actually bad for it to be possible to write the same thing in more than one way.
Zig's new phrasing: "There is an idiomatic way to do it." captures the CORRECT alternative to Perl's motto. It is not important that there be no alternative ways of writing something, Rather, it is important that there be a single idiomatic way to write it.
This is a losing proposition. Because just like in Python, it may also generate endless debates on "ok, but what exactly is the idiomatic way for this particular thing here"? Is it A, or B, or maybe C? Since many are always possible, each optimizing for slightly different things, like simplicity, or maintainability, or performance, or readability, or coverage, etc. Groups may form furiously asserting that the idiomatic way must be C, others defending B, or A, and for what. Why does it matter? A young language free from cruft, after a long history of various decisions that led it on certain paths, can boldly claim such nonsense, but makes one wonder how it may look in 30 or 40 years, when other languages/ecosystems will point at its mistakes. Arguably Perl had it right all along, it's just a simple fact of life, expressed in such a generic manner that there is no need to fight it, since it's obviously true. Python's retort at the time was just clever marketing (aka lies), that worked (fooled a lot of people), it targeted Perl specifically just because that was the main competition back then.
Because something bad might happen in 30 years is not the reason to make sure it happens in three...
Are you a Perl dev?
I think people criticize that line in the zen of Python because Python has now become very maximalist. On it's own merits, I think "There should be one obvious way to do it" is much better, less clunky, than "There is an idiomatic way to do it".
Also, importantly, the Zen of Python is kinda written as a set of ideas that Python should aspire to ("there should be one obvious way to do it") instead of a sales pitch of Python's merits. I prefer that.
It all sounds great until someone writes nested list comprehensions. They are the recommended, idiomatic way to things most sane people would use ‘map’, ‘filter’, and ‘reduce’ chains, although chains are another thing python very much dislikes.
I always read this as a tongue in cheek joke b/c of how the — appears left aligned, then right aligned, then elsewhere in the Zen center aligned, sort of pointing to how yeah there’s multiple ways to do things …
The correct alternative is to make no motto at all. It's code. Makes computer go brrr.
Yeah, I actually don't care how other people program in the languages I'm using. Give me all the ways to do things. I'll make my own choices, thank you.
Someone cooked up a language just like this ages ago, and today it's one of the most popular languages on the planet! Unfortunately, in modern times people don't like to write/code in this language, so they built some beast on top of it which is the de facto standard right now. But you can still write JavaScript, and you can avoid all the shit parts like "classes" and what not, do classic prototype-style programming, or even layer your own functional/OOP programming on top. Not much you cannot do in JavaScript, probably only a lisp would enable more programming paradigms, but for mainstream languages, it's as close as you can get to True Freedom.
Glad to see "Together we serve the users" come back. I miss the old Zig readme that said Zig comes with an MIT license and a humble request to build software that serves the users.
It was already there though.
the green is from moving the line
actually, they added exclamation
They moved it out of the bullet list in the CLI version, and added it to the web version.
> Resource allocation may fail
Yes it can. But it's nearly impossible to handle such cases properly. That's why checking each allocation manually is a bad idea. Other languages do this better - they provide nice abstractions, but if something fails, the language runtime terminates the process. The result is the same, but has much less friction.
Also on some systems (like Linux) memory allocation may not fail, but the "allocated" memory may not be available and a program can crash accessing this memory.
Zig is in the space of languages where an abstraction that decides that memory allocations are irrecoverable is not good enough.
If you work in an environment where memory allocations can't fail or can't be handled if they fail, you might not want to use Zig, or C for that matter. Not every language should be designed to live in the space of "somehow low level but also a good choice for your basic web backend", like Rust.
Rust doesn't stop you from checking if memory allocation has failed. Its libstd provides many operations that don't bother to surface memory allocation failure (for the reasons given above), but that's why Rust provides a libcore that does no allocation, while continually working to push more things down from libstd into libcore, while providing alternative APIs in libstd to let you handle allocation failure if you know you actually need to.
Conversely, Rust doesn't force you to explicitly handle if memory allocation failures. The least you can do in Zig is explicitly ignore allocation failures.
You can certainly write data structures in Zig that swallow allocation failures rather than surfacing them. We're talking about library-level concerns, not language-level concerns. Both Rust and Zig give you the power to allocate raw memory and handle the result of that syscall however you want, it's the standard libraries that differ beyond that point.
Yes, it is a standard library difference. But unless you plan on rewriting the entire Rust ecosystem, you're going to be dealing with invisible failure points in Rust code that you would not be dealing with when writing the equivalent Zig code. The standard library is almost as fundamentally important to a language as it's built-in operators.
And Zig does have language-level features that combine to require you to explicitly handle propagated errors (error sets, requiring all return values be explicitly handled, requiring all switch cases be explicitly handled). Rust has a similar set of features (pattern matching, requiring all match cases be explicitly handled), but does not use them for allocation (Box::new, vec![], etc. does not return a Result value).
> If you work in an environment where memory allocations can't fail or can't be handled if they fail, you might not want to use Zig,
It's most of environments. Basically any program running under a modern OS. So, why do this language exists, if its practical applicability is so small?
This language exists so you can reuse the same code in environments where memory allocations may fail, and where memory allocations can't fail.
Let's say you write an application that runs as a Unix daemon in Zig. Later you may decide that your application is really the only thing you're interested in running on the target machine, and for performance and predictability reasons, you'd prefer to boot directly to your application, instead of to an OS that launches your daemon. You can just swap out the implementation of the std.Io runtime for one that targets the hardware directly, instead of a Unix. You don't have to make any changes to your application.
That's kind of an extreme case, but it's the kind of flexibility Zig provides.
> This language exists so you can reuse the same code in environments where memory allocations may fail, and where memory allocations can't fail.
In my hypothetical example of a language where allocation fails aren't exposed it's possible too. An allocation fail just triggers a full system reboot.
On modern OSs you can write Zig and just ignore allocation errors. It doesn't force you to handle them properly.
This language exists to supercede or supplement C, not JavaScript or C#.
It's practical applicability is similar to that of C, so I struggle to comprehend how it is "so small".
> On modern OSs you can write Zig and just ignore allocation errors.
I can ignore errors, but I still need to free memory manually if I want to avoid memory leaks. Languages like C++ or Rust have destructors, which do the job for me.
> This language exists to supercede or supplement C
There are way better alternatives, like Rust. Even C++ is better.
Several things:
* There are many useful ways to handle it properly, and your choice depends on your program's constraints. The very small amount of friction (once you're used to it) encourages you to consider what ways to handle it are viable, such as allocating all memory at startup.
* If your strategy is to crash immediately, there is very little additional friction but you get the benefit of it being obvious in your code that this is the case.
* There are environments where memory allocation fails immediately, including if you turn off over-commit on Linux. If your hardware is dedicated to running a high reliability system, configuring it in this way is reasonable.
* Memory is not the only resource. Indeed, removing the special call out is what changed here. That different resources are handled with the same mechanism (errors, instead of eg returning null from malloc) is good.
Autors of Zig did a choice for me. I can't use RAII in it. In C++ it's better - when I don't care, I just use standard library containers, when I do care, I can bypass them.
You might have a limited budget per incoming request in a http server for example. Then you want all of the code that http handler calls to be able to handle an error of type something like OutOfMemory.
This is a very good ability to have in an application like a database.
Such things should be solved in more nice way, not by manually checking every allocation. Like via lightweight threads, with each of them having their own memory and a scheduler, which kills threads exceeding their memory limit.
This compilicates things more compared to functions returning Result<>.
You also get locality benefits from bump style allocators. And you don't need SmallVec or similar optimization containers. And you also avoid mental overhead of managing many allocations in your head (or using a language with borrow checking).
> This compilicates things more compared to functions returning Result<>.
Checking each Result in a large program is more complicated than having a runtime library handling memory limits properly.
> And you also avoid mental overhead of managing many allocations in your head
That's exactly what languages like Zig force you to do, compared to something like C++ or Rust.
> or using a language with borrow checking
borrow checking gives memory safety. It's also important to have.
Nearly impossible in some contexts, where the trade-off makes sense.
There are many scenarios, especially in embedded systems, where it can happen and you want to handle it robustly, e.g. by evicting a cache or flushing a buffer to disk.
In embedded systems you have enough control. But as soon as an OS is involved, you have much less control. Basically an OS may do with your process whatever it wants, but it happens to be polite most of the time.
OT: any word on how Codeberg has been working out for Zig?
the maintainers seem happy, especially now that CI is actually working how it's supposed to. but a non-rare complaint in the Zig discord is how slow Codeberg can be, and other things like the lack of codesearch hurt as well.
I'm out of the loop. Is there any context? Can't pick up on what really changed here.
The link shows the exact diff
I saw what changed syntactically. I meant I don't really understand what changed semantically. And whether there is any context to why the change was necessary.
The commit message feels clear to me? It seems Andrew wanted to clean the zig zen slightly, it’s not a big change:
> - rewordings
> - "memory is a resource" goes without saying
> - emphasize the final point
I'm guessing the parent is wondering why this is noteworthy enough to be posted and discussed in this thread, and so if there's context they are missing
I'm wondering the same: why is this change significant enough to reach the frontpage on Hacker News?
Someone felt that was interesting and submitted it. People noticed Zig and upvoted. That would be my guess
I don't see how Zig will ever contend with Odin, Jai, C3 and others when they drive away half of the prospective users with activism.
I recommend you to watch Andrew Kelly interview[0], while I'm not the target audience of Zig, I don't see him driving away any user. Also Jai as for now is a non existing language, just a selected few has access to it, but Jai approach is a kitchen sink, from what I saw it is all over the place in terms of features, now Zig vision feels cohesive.
[0] https://youtu.be/iqddnwKF8HQ
Thanks for sharing that link. That guy seems so nice, quite inspiring.
Activism as in their move away from GitHub? Andrew K recently said in the JetBrains interview that because of moving away, their CI/CD now actually works.
What activism is that?
trying to make good software :^)
truly a tragedy! how dare you make good software!?!
I think they banned AI and moved from GitHub to Codeberg. They don't seem too controversial to me, and IMO they've already comprehensively trounced Odin, Jai and C3.
I've never seen any activism from the Zig crowd (I assume you need Woke and rubbing "pride" or "Ukraine" into everything). Did I miss something?
> I assume you need Woke and rubbing "pride" or "Ukraine" into everything
wow, what a self report
Jai isn't even available publicly. The license isn't decided. Jonathan Blow doesn't want to deal with open source.
Comparing Jai and Zig on that behalf is crazy.
Edit: If that is about political activism it's even more crazy. A dude that rambles about woke stuff is political as well. Maybe just aligns with yours.
Excuse me, but I think zig grows ever better from driving away users who are driven away by flashy headlines and whatever is the opposite of this “activism” you suggest.
>when they drive away half of the prospective users with activism.
Like what? Plenty of people here follows Zig here and haven't seen any of it. And by any measure it is the least activism per language usage.