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

Zig is becoming more production-worthy

zigmonthly.org

Post reply on HN
Print view View original

51–60 of 73 posts

Re: Zig is becoming more production-worthy

#51

Post by chienandalou »

ihateolives wrote: post #42
chienandalou wrote: post #38

Earlier quoted context omitted.

If the 'unused variable'-handling is the only thing that holds you back: it's quite simple to build the zig compiler and patch it. See this post by ryuukk in the corresponding issue on github: https://github.com/ziglang/zig/issues/335#issuecomment-10138... and also https://github.com/ziglang/zig/issues/335#issuecomment-10184... I use this method to build a zig compiler to work with, and when I build a release build o…

Having to build your own version of the compiler to fix this annoyance is like using a sledgehammer to crack a nut. It should be a simple flag, whichever way the default, but it shouldn't require building a compiler. That's nuts, both in a bad and a good way.

I agree, it should be a flag. Or it should be a warning in debug builds, and an error in release builds.

I'm not sure it's nuts to build the compiler to 'fix' this, though. Customizing and building a tool really isn't such a big deal when you think about it.

Re: Zig is becoming more production-worthy

#52

Post by japhib »

I used Zig for a couple of Advent of Code problems last year. I decided that Zig is not a language I’m going to be using. Here’s why:

- If you ever want to allocate memory, you have to pass in an allocator to the function doing the allocating. You also have to explicitly allocate and deallocate.

- Zig has no concept of a string - it’s just a slice of bytes. This also means Zig has no support for string concatenation, UTF-8, regex, or any of the other many niceties we’ve come to expect as standard.

Zig is not the next Rust or the next C++ - it’s very much the next C.

Zig may be fine for people programming an OS or very highly performance sensitive application. But it’s too low level, and too obtuse about being low-level, for me to ever want to actually use it.

Re: Zig is becoming more production-worthy

#53

Post by giancarlostoro »

NinoScript wrote: post #8
giancarlostoro wrote: post #5

Earlier quoted context omitted.

> I think the future is in languages that prioritize simplicity and developer velocity like Zig is doing. I kind of dont like Zig because of the syntax its just a little out of the norm from what I'm used to. I like D more if I want to go the C-like route, just hate that its not quite as popular as Go or Rust seem to be. Currently I'm diving into Nim more than anything though, it feels like the sweet spot for me.

One gets used to syntax, don’t let that be the reason you don’t like a language.

It's not just syntax, it is obviously C-like which I like, but it is the way programs look, I think Zig is maybe more low level than I care for.

Re: Zig is becoming more production-worthy

#54

Post by pornel »

anonymoushn wrote: post #49
pornel wrote: post #47

Earlier quoted context omitted.

Make that JS+Python then. OTOH languages that can spawn threads and use synchronization primitives are able to bridge sync and async.

You can spawn threads in Python. Async/await is (among other things) a control-flow primitive for single-threaded programs. C# also includes more or less the same async/await as these languages, as far as I know. Not only do threads not really do the thing (in part because of the high cost of threads compared to alternatives), the alternative isn't only threads. Users of Lua, Greenlet, ucontext_t, libco, etc. have be…

I'm not talking about trade-offs of async vs sync. I'm talking about the color article saying languages have "color" when one type of functions (sync) can't use results of another type of functions (async). If you have threads and mutexes, then one type can use the other, regardless of whether that's a good idea or not. The point is that there either is a hard unsolvable api-infecting limitation (like in JS) or there isn't.

Re: Zig is becoming more production-worthy

#55

Post by dantillberg »

anonymoushn wrote: post #27
ghoward wrote: post #26

Earlier quoted context omitted.

Yes, why does that matter? It still shows that Zig's async/await is not colorblind.

It seemed like most of your post was about not being able to use the two functions through pointers of the same type, but you can use the two functions through pointers of the same type, so maybe now you can delete a majority of your post and submit a retraction to Hacker News or something. I'm not sure you are using the same notion of "colorblind" as most people. All that is claimed is that much application code can…

I'm new to Zig this year, and I'll share my own learning experience. ziglang.org's overview[0] says, "Zig functions avoid colors." I interpreted that as similar to Go's lack of function colors. Given the rest of the language design, I didn't think it really possible.

Months later I read Gavin's post (linked above). I found that post immensely helpful to understand Zig's design around sync/async function colors (thanks Gavin!). Gavin's post helped to illuminate for me that Zig functions do have colors, but that the compiler can infer the color in most usual cases. This is still very exciting!

As I see it, it's not to Zig's detriment whether it "has" function colors or not, I don't really care. I'm really excited about Zig either way. But I personally (coming from a decade+ of JS/Python/Go) found the verbiage I found used to describe Zig's behavior here confusing.

[0]: https://ziglang.org/learn/overview/

Re: Zig is becoming more production-worthy

#56

Post by kristoff_it »

pornel wrote: post #43
ghoward wrote: post #13

Earlier quoted context omitted.

Zig's async/await isn't actually colorblind. [1] It just seems that way at first. [1]: https://gavinhoward.com/2022/04/i-believe-zig-has-function-c...

"Colorblind" is an arbitrary goalpost made to satisfy an imprecisely defined term of one blog post. The original color article is soo annoying, because it presents two things as one: a JS-specific limitation, and author's arbitrary opinion on how async syntax should (not) look like. Since then even languages that don't have JS's limitation still keep chasing the other point, because otherwise they're shamed for havin…

"having colors" is an unfortunate property of async/await, not of JS. C# has the same exact set of problems, made even worse by Microsoft's love for horrid APIs and inconsistent runtimes.

Re: Zig is becoming more production-worthy

#57

Post by rowanG077 »

verdagon wrote: post #4

I love how Zig is pushing the state of the art forward. I have some expertise in the area, and I think the future is in languages that prioritize simplicity and developer velocity like Zig is doing. > The core team will then be able to begin thinking about: ... Exploring hot-code-swapping Hot code swapping, plus Zig's ability to cross-compile, plus release-safe's memory assistance without mental overhead, all seem to…

To me simple and not getting in the way are complete opposites of one another. C and go are prime examples. The simplistic nature of the languages mean you can't express many obviously wanted things.

Re: Zig is becoming more production-worthy

#58

Post by nyberg »

japhib wrote: post #52

I used Zig for a couple of Advent of Code problems last year. I decided that Zig is not a language I’m going to be using. Here’s why: - If you ever want to allocate memory, you have to pass in an allocator to the function doing the allocating. You also have to explicitly allocate and deallocate. - Zig has no concept of a string - it’s just a slice of bytes. This also means Zig has no support for string concatenation,…

- Passing the allocator gives the user of the container control over where memory is allocated and the scheme used to clean it all up. You can always set a global allocator if you wish, nothing forces you to use it as a parameter.

- Regex can be provided as a library and specialized at comptime. There's never been a need for regex to be part of a primitive type and many other languages do fine without it. Concatenation is a question of "where do you allocate memory" as you have explicit allocation it's not clear what zig should do with it thus the default is to let you call std.mem.concat and dealing with the possible failure or having a look at the problem and asking if you really need concat in the first place. Often you don't as formatting string is better done with std.fmt and ArrayList(u8)'s writer().

Re: Zig is becoming more production-worthy

#59

Post by hn92726819 »

japhib wrote: post #52

I used Zig for a couple of Advent of Code problems last year. I decided that Zig is not a language I’m going to be using. Here’s why: - If you ever want to allocate memory, you have to pass in an allocator to the function doing the allocating. You also have to explicitly allocate and deallocate. - Zig has no concept of a string - it’s just a slice of bytes. This also means Zig has no support for string concatenation,…

> Zig has no concept of a string - it’s just a slice of bytes. This also means Zig has no support for ... regex

I used to think the same thing but it makes sense that for a finite state machine, the matcher doesn't need to work with validated strings at all.

You should read the first 2 paragraphs of burntsushi's (wrote rust regex implementation and a lot more) doc comment here: https://docs.rs/bstr/latest/bstr/#when-should-i-use-byte-str...

Post reply on HN