Live data from Hacker News

Zig is hard but worth it

ratfactor.com

81–90 of 307 posts

Re: Zig is hard but worth it

#81
post #37

Alternative languages are cool, but I struggle to see the point of a systems programming language that doesn't offer static memory safety in 2023. Rust isn't necessarily the best and final answer--it seems like there is a broad design space to explore for memory-safe systems programming languages. But Zig seems to occupy the same local maximum as C--a relatively simple, non-safe systems language--and doesn't have a k…

If we’re comparing C to Zig I’m not sure what memory safety even needs to be mentioned for. For C to Zig there’s plenty of reasons one might prefer Zig. For memory safety obviously you might opt to choose neither.

In a vacuum, one might prefer Zig. But given that everyone already knows C and the ecosystem is so highly developed, it takes a gamechanging feature like Rust's memory safety to make an alternative language attractive (beyond a "this is cool" project--which I totally support).

Re: Zig is hard but worth it

#82
post #73
post #55

Earlier quoted context omitted.

I've lately thought that a package manager is as essential to a new language as a standard library. I would also add a LSP and standard code formatter to that list. It is a bit unfortunate because all of the above is a pretty tall order. We're getting to the point that new languages are expected to boil the ocean by the time they reach 1.0

Zig has a pretty decent LSP. I'm not so sure a package manager is really all that essential; it can certainly be convenient but especially in the space Zig is looking at it's pretty workable without one (without complex deep dependency trees you can use git submodules or just copy a directory). Or let me put it this way: I never really missed a package manager in Zig.

> I'm not so sure a package manager is really all that essential;

For open source software (libraries or programs, that depend on other libraries or programs), it is essential (if you're not distributing single functions like with Unison). For closed source it doesn't matter that much.

Re: Zig is hard but worth it

#83
post #24

Earlier quoted context omitted.

I'm not a Zig expert, but I have a different take here. Zig has comptime, which is essentially a compile time macro written in the main language and with type reflection capabilities. They can introduce complex behaviour and fail in very cryptic and unexpected ways, which results in an experience very similar to macros or C++ template literals.

The objects that are manipulatable by comptime are ordinary program objects and types -- not ASTs. That means that while it's true you can get compile-time errors in similar situations to macros, the errors themselves are like ordinary runtime errors in an untyped language -- while occurring at compile-time, they look like runtime error in Python or JS -- rather than errors due to some "second-order" manipulation of…

I haven't had a chance to play with comptime in Zig yet but I'm sort of curious how it compares to Nim's compile time facilities. You can declare variables with 'var' for true variables, 'let' for things that are runtime constant within a scope, or 'const' for compile time constants whose values can come from functions or whatever as long as it can be resolved by the compiler. And then you've got 'when' as a compile time equivalent of 'if'.

Re: Zig is hard but worth it

#84
I don't know Zig so I can't comment much on the content, but the author's writing style I enjoyed immensely; enough to make me want to pick up Zig for fun. I do have some C background, albeit decades ago, so maybe I'm in the right spot for it.

Re: Zig is hard but worth it

#85
post #55
post #22

I've now written a lot of zig code (http.zig, websocket.zig, log.zig, zuckdb.zig, etc.) I think Zig falls into an "easy to learn, average/hard to master" category. Some insiders underestimate the effort required for newcomers to build non-trivial things. I think this is because some of that complexity has to do with things like poor documentation, inconsistent stdlib, incompatible releases, slow release cycle, lack o…

I've lately thought that a package manager is as essential to a new language as a standard library. I would also add a LSP and standard code formatter to that list. It is a bit unfortunate because all of the above is a pretty tall order. We're getting to the point that new languages are expected to boil the ocean by the time they reach 1.0

package managers are relatively easy to put together and release with your language—provided that you want your new package manager and surrounding ecosystem to work exactly the same as other, popular ones, without putting any effort into improving the status quo. doing better than other languages' package managers takes significant effort, because it's both a computer engineering problem and a social engineering problem.

it's nice when a new language has a package manager right out of the gate, but I would like to see more new languages take a more measured approach and aim to significantly improve upon past efforts, instead of merely replicating them out of some sense of obligation.

Re: Zig is hard but worth it

#86
post #3

> Crucially, there is basically no documentation for the standard library except for the source code itself. From the viewpoint of someone learning about a new language, I find the accessibility of the standard libraries goes a long way toward helping me understand how things fit together. It is a first stop to see how experts in the language use it. Browsing through the standard libraries of languages like Zig, Go,…

Afaik Zig has the issue that basically everything happens on the Discord server, where it can't be indexed via search engines, or found by anyone who wants to have a quick question answered. This would be "fine" if the standard library and language were much better documented, but it isn't, and it's still ripe with bugs. In other words, you're forced to use the Zig Discord server if you want to find answers to any si…

This is true for Nim as well, in that most of the discussion is on the Discord/Matrix server. I’m not a fan personally, at least IRC was easily archived and searchable in practice.

I really dislike how Discord has become “forums in the 2020s”

Re: Zig is hard but worth it

#87
One annoying thing I ran into when trying zig is they don't distribute debs any more for Debian distributions. They just tell you to use a snap. I don't have snap, and don't want it.

Compiling it requires the latest llvm toolchian (16), which is only realistically going to be available as a package if you're on a bleeding edge distribution.

Re: Zig is hard but worth it

#88
post #73

Earlier quoted context omitted.

Zig has a pretty decent LSP. I'm not so sure a package manager is really all that essential; it can certainly be convenient but especially in the space Zig is looking at it's pretty workable without one (without complex deep dependency trees you can use git submodules or just copy a directory). Or let me put it this way: I never really missed a package manager in Zig.

> I'm not so sure a package manager is really all that essential; For open source software (libraries or programs, that depend on other libraries or programs), it is essential (if you're not distributing single functions like with Unison). For closed source it doesn't matter that much.

"cp -r ~/some-lib ~/my-project/" works well enough if some-lib doesn't have dependencies on its own. Or git submodules if you want something a bit more fancy. I sometimes do this even for languages with package managers, as it avoids a world of complexity.

Obviously a package manager is useful, but Zig is relatively low-level and long dependency chains are much less common than in e.g. Python, Ruby, and of course NodeJS. So I'd argue it's not essential. All the other things mentioned in the to top comment are far bigger issues IMO.

Re: Zig is hard but worth it

#89
In new last version 0.10.1 it seems that for is not working with two arguments?

  const std = @import("std");
  const expect = std.testing.expect;

  test "for basics"  {
    const items = [_]i32 {4,5,3,4,0};
    var sum: i32 = 0;
    for(items, 0.. ) |value,_| {
      sum += value;
     }
     try expect(sum == 16);
  }

  ubuntu 22.04, snap zig version 0.10.1 , 
  zig test 1.zig produces:

  1.zig:7:12: error: expected ')', found ','
  for(items, 0.. ) |value,_| {
           ^
Edited: To update, I tried snap, but using snap install --classic --beta zig is a security risk because it can change the system and is not sandboxed.

Re: Zig is hard but worth it

#90
post #22

I've now written a lot of zig code (http.zig, websocket.zig, log.zig, zuckdb.zig, etc.) I think Zig falls into an "easy to learn, average/hard to master" category. Some insiders underestimate the effort required for newcomers to build non-trivial things. I think this is because some of that complexity has to do with things like poor documentation, inconsistent stdlib, incompatible releases, slow release cycle, lack o…

I just start to learn Zig,any suggest to beginners?Bro
Post reply on HN