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.
the green is from moving the line
actually, they added exclamation
Zig Zen Update
31–40 of 65 posts
Re: Zig Zen Update
#32Nicely 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 un…
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 idiomat…
Because something bad might happen in 30 years is not the reason to make sure it happens in three...
Re: Zig Zen Update
#33> 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.
Re: Zig Zen Update
#34> 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…
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.
Re: Zig Zen Update
#35> 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…
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.
Re: Zig Zen Update
#36Earlier quoted context omitted.
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?
Re: Zig Zen Update
#37> 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…
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.
Re: Zig Zen Update
#38> 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…
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.
Re: Zig Zen Update
#39> 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…
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 yo…
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.
Re: Zig Zen Update
#40> 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…
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…
> 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?