Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Zig Zen Update

codeberg.org

Post reply on HN
Print view View original

41–50 of 65 posts

Re: Zig Zen Update

#41

Post by Panzerschrek »

underdeserver wrote: post #35
Panzerschrek wrote: post #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…

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.

Re: Zig Zen Update

#42

Post by jraph »

norman784 wrote: post #20
melon_tusk wrote: post #10

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.

Re: Zig Zen Update

#43

Post by Panzerschrek »

ozgrakkurt wrote: post #37
Panzerschrek wrote: post #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…

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.

Re: Zig Zen Update

#44

Post by dgellow »

Izmaki wrote: post #36
frde_me wrote: post #25

Earlier quoted context omitted.

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

Re: Zig Zen Update

#45

Post by kibwen »

lionkor wrote: post #34
Panzerschrek wrote: post #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…

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 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.

Re: Zig Zen Update

#46

Post by lionkor »

Panzerschrek wrote: post #40
lionkor wrote: post #34

Earlier quoted context omitted.

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?

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".

Re: Zig Zen Update

#47

Post by Zambyte »

Panzerschrek wrote: post #40
lionkor wrote: post #34

Earlier quoted context omitted.

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?

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.

Re: Zig Zen Update

#48

Post by Zambyte »

kibwen wrote: post #45
lionkor wrote: post #34

Earlier quoted context omitted.

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 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 k…

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.

Re: Zig Zen Update

#50

Post by ozgrakkurt »

Panzerschrek wrote: post #43
ozgrakkurt wrote: post #37

Earlier quoted context omitted.

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).

Post reply on HN