Zig is hard but worth it • Hacker News Board

Re: Zig is hard but worth it

#71

Post by 59nadir » Thu, Jun 01, 2023, 2:35 PM UTC

eatonphil wrote: post #49

rowls66 wrote: post #45

Earlier quoted context omitted.

I am truly puzzled by this. I understood Zig to be a very low level language like 'C'. Why would you write scripts in it?

It's significantly nicer to write than C (my opinion obviously). I see it as a general purpose language. But mostly the team decided to do this because we wanted to unify on one language and double down on the investment in Zig. I'm not a fanboy (nothing wrong if anyone is, just clarifying about myself); I think this choice was right.

For what it's worth I think this is an excellent choice. Back in 2019 I was deciding whether I wanted to pursue Zig full-time and one of the upsides that I determined was that once you reach critical mass writing all of your code for tools and things in Zig you end up with things that are really exactly what you need and with a very high baseline for speed, flexibility, and so on.

Right now I'm considering the same thing but with Odin and for many of the same reasons that I had for Zig; it's an excellent language to write foundational code in and once you do, you end up being able to build significantly more understandable, reliable, stable and consistent things.

This, but on a company level, is a real multiplier. Once you adopt a couple of Python scripts and that's OK, you give up the possibility of wielding this sharp spear.

Edit:

I think "How I program C" by Eskil Steenberg is an interesting window into what you can get if you laser focus on a language and environment and allow yourself to build up a mountain of code that you dogfood: https://www.youtube.com/watch?v=443UNeGrFoM

At some point I will likely soft-retire and at that point it's exceedingly unlikely that I'll bother with using other people's libraries except a few key ones that I think are decent, and at that point there really is no reason I'd sit down and write these fundamentals in anything but a lower-level language. Odin, Zig or something like it would pretty much be the only thing on the table.

Re: Zig is hard but worth it

#72

Post by epage » Thu, Jun 01, 2023, 2:37 PM UTC

stared wrote: post #62

What are the use-cases in which it might be worth switching from Rust to Zig?

matklad, of rust-analyzer fame among many other things, wrote up their thoughts on Zig: https://matklad.github.io/2023/03/26/zig-and-rust.html

I've seen some put it as "zig is good when `unsafe` heavy code".

Personally, even when writing life-or-death software, allocation errors were too much of a pain to deal with and much prefer Rust's approach for 99% of software. The question is if another language like zig provides enough value to justify existing for that 1% of use cases (all numbers made up :) ).

Re: Zig is hard but worth it

#73

Post by arp242 » Thu, Jun 01, 2023, 2:41 PM UTC

zoogeny wrote: post #55

latch wrote: 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

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.

Re: Zig is hard but worth it

#74

Post by Fiahil » Thu, Jun 01, 2023, 2:42 PM UTC

ldelossa wrote: post #21

I'm surprised that the reason I'm mostly interested in Zig is not mentioned. This is C interop. I work with C quite a bit and I enjoy it, however writing a large project in C can be tiresome. Having an option like Zig which can import C headers and call C functions without bindings is pretty attractive, especially when you want to write something a big larger but still stay in C world.

C interop is not as much a "killer feature" as it used to be. When you deal with data science, web and other similar domains, reading and writing JSON ergonomically is much more important than being able to call a C function directly. It's just a nice-to-have.

Re: Zig is hard but worth it

#75

Post by loeg » Thu, Jun 01, 2023, 2:43 PM UTC

helen___keller wrote: post #9

My main issue with Zig is that I’m scared to invest time in writing something nontrivial to see the community/adoption flounder then regret not using Rust or C++ later The language itself is fun. The explicit-ness of choosing how allocation is done feels novel, and comptime is a clean solution for problems that are ugly in most languages. Aside from lack of community I’d say the biggest nuisance is error handling in…

> Aside from lack of community I’d say the biggest nuisance is error handling in nearly everything including allocations. I get that allocation can fail but the vast majority of programs I write, I just want to panic on an allocation failure (granted these aren’t production programs…)

The C strategy for this was just to wrap malloc() with something called xmalloc or malloc_nofail or whatever:

  void *malloc_nofail(...) {
    void *res = malloc(...);
    if (res == NULL) {
      abort();
    }
    return res;
  }

(Or whatever.) The same would work in Zig, I think.

Re: Zig is hard but worth it

#76

Post by tuhats » Thu, Jun 01, 2023, 2:45 PM UTC

jsheard wrote: post #7

I get what Zig is going for in making all operations as explicit as possible, but I fear that it's going to turn away fields like graphics and game development where it would be a good fit except for the lack of operator overloading forcing you to go back to C-style math function spaghetti. It's all fun and games until what should be a straightforward math expression turns into 8 nested function calls.

I have played around with using @Vector for linear algebra.

This removes the need for operator overloading for a vector type, which covers most use cases of operator overloading and I often in fact think is the only legitimate use case.

I don't get to use `*` for matrix multiplication, but I have found I do not mind using a function for this.

I have only been playing with this in small toy programs that don't to much serious linear algebra and I haven't looked at the asm I am generating with this approach, but I have been enjoying it so far!

Re: Zig is hard but worth it

#77

Post by whateveracct » Thu, Jun 01, 2023, 2:47 PM UTC

pron wrote: post #66

auggierose wrote: post #63

Earlier quoted context omitted.

It's not really surprising that purely functional programming is expressive. Indeed, it is as expressive as "opaque" programming.

There's nothing pure functional here (perhaps the term "referential transparency", which some FP fans have come to misunderstand and perpetuate its misunderstanding is what may have given you that impression). Referential transparency is very much less expressive than referential opacity, as there are certain statements that simply cannot be expressed if your language is referentially transparent. For example, in pro…

Can you give me an example of a Haskell expression which isn't reverentially transparent (without unsafePerformIO)?

> An expression is called referentially transparent if it can be replaced with its corresponding value (and vice-versa) without changing the program's behavior.

^ that is the definition of referential transparency I am aware of.

You seem to be implying that FPers have bastardized the term through their misunderstanding.

But the bog standard FP definition is a real and useful concept. Maybe it stole something else's name? But I don't think it's due to being mistaken. Because the FP concept itself is pretty rigorous.

Re: Zig is hard but worth it

#78

Post by kapperchino » Thu, Jun 01, 2023, 2:48 PM UTC

jsheard wrote: post #7

I get what Zig is going for in making all operations as explicit as possible, but I fear that it's going to turn away fields like graphics and game development where it would be a good fit except for the lack of operator overloading forcing you to go back to C-style math function spaghetti. It's all fun and games until what should be a straightforward math expression turns into 8 nested function calls.

For the math stuff you can do things like a builder pattern where you can flatten the nested functions. But operator overloading is definitely preferred

Re: Zig is hard but worth it

#79

Post by 59nadir » Thu, Jun 01, 2023, 2:49 PM UTC

sarchertech wrote: post #54

I tried Zig for a few weeks but ended up choosing Odin for a game dev side project I’m working on. Odin feels a lot more high level, but still gives you low level control when you need it.

I've settled on Odin as well and I think it's currently way ahead for game development than Zig is. Even for other things I'm currently more likely to write it in Odin, despite writing Zig from 2019 to 2022. The reasons really come down to error handling being better in Odin overall with payloads being attachable to errors as well as the context system and zero values making it relatively painless to really only talk about the things that need talking about and letting the rest be unsaid.

There are also several similarities: Custom allocators as part of the ecosystem and language, no RAII, easy ways to propagate and handle errors the right way, tagged unions with table stakes like exhaustiveness checking.

I think Odin and Zig have some fundamental differences (and plenty of similarities) and when trying Odin out I was surprised to find that I preferred the Odin way overall.

For gamedev stuff Odin wins due to a few things; swizzling on a code level is super nice, array programming built-in to the language, vendor libraries shipped with the language that allow you to just get going almost no matter what you're doing, and so on.

Re: Zig is hard but worth it

#80

Post by auggierose » Thu, Jun 01, 2023, 2:50 PM UTC

pron wrote: post #66

auggierose wrote: post #63

Earlier quoted context omitted.

It's not really surprising that purely functional programming is expressive. Indeed, it is as expressive as "opaque" programming.

There's nothing pure functional here (perhaps the term "referential transparency", which some FP fans have come to misunderstand and perpetuate its misunderstanding is what may have given you that impression). Referential transparency is very much less expressive than referential opacity, as there are certain statements that simply cannot be expressed if your language is referentially transparent. For example, in pro…

Referentially transparent means that you can replace an expression with its value without changing the meaning of the program. If everything you can do must be referentially transparent, then that's purely functional programming, because applying functions without side-effects is pretty much the only thing you can do then. Of course, there are some other techniques like rewriting, which strictly speaking are different from purely functional programming, but I consider these two things to be pretty much the same thing.