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

Zig is hard but worth it

ratfactor.com

Post reply on HN
Print view View original

11–20 of 307 posts

Re: Zig is hard but worth it

#11

Post by bodge5000 »

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'm no expert on zig, but the one area I have seen it shooting up in popularity is game dev. Though I guess that is largely as a replacement for C, so "C-style" wouldnt be much of a concern

Re: Zig is hard but worth it

#12

Post by tialaramex »

thadt wrote: 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,…

I certainly wouldn't recommend trying to figure out C++ by reading either of the three major C++ standard libraries.

Re: Zig is hard but worth it

#13

Post by kuroguro »

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…

I suppose you could write a few line wrapper that panics :)

But yeah, most of the time I don't even want to think which allocator to use let alone handle it's errors.

Re: Zig is hard but worth it

#14

Post by jgalt212 »

bakuninsbart wrote: post #6

Where do you guys see good use cases for Zig? I'm intrigued by the language but don't really have any good ideas on where to try it out. I thought about trying it out in as small data engineering project, but I'm not sure if language support is sufficient for the kind of tooling I would need eg. Database adapters.

I've been thinking about using it for Python hot paths. I'm not smart enough to write rust (at least without limitless supplies of aspirin). And I'd like to avoid C for all the obvious reasons.

Re: Zig is hard but worth it

#15

Post by TwentyPosts »

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 am not much of a Zig-head, but the best compromise I can think of is having a few operators which purely and solely exist for this purpose. In other words, there is no operator overloading, but you can define, say, "#+" for any two structs, or something like that.

So if you want to encode matrix multiplication, then you'll always have to write `mat1 #* mat2`. This feels like a hack, and isn't all that elegant, but it'd be clear that every usage of such an operator is a disguised function call. (And according to what Andrew Kelley said, it's all about not hiding function calls or complex operations in seemingly innocent 'overloaded' symbols.)

If you want to take this one step further you'd probably have to allow users to define infix functions, which would be its own can of worms.

Honestly, I am not particularly happy with any of these ideas, but I can't think of anything better either!

Re: Zig is hard but worth it

#16

Post by jsheard »

bodge5000 wrote: post #11
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'm no expert on zig, but the one area I have seen it shooting up in popularity is game dev. Though I guess that is largely as a replacement for C, so "C-style" wouldnt be much of a concern

Zig looks like a fine C replacement, but C isn't what people are using to make games in the vast majority of cases. It's all C++, and operator overloading is part of the "sane subset" that everyone uses even if they hate the excesses of modern C++ as a whole.

Re: Zig is hard but worth it

#17

Post by nickelcitymario »

> [...] easy things seem easy primarily because they are familiar. Easy is subjective. But simple things are simple because they do not complicate; they have fewer concepts. Simple is objective.

This should be printed out as a large poster in every office.

Re: Zig is hard but worth it

#18

Post by eatonphil »

kuroguro wrote: post #13
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…

I suppose you could write a few line wrapper that panics :) But yeah, most of the time I don't even want to think which allocator to use let alone handle it's errors.

This is basically what I've come to do in the Zig scripts I write at work.

It took a bit of getting used to when I joined but we agreed as a team to have all meaningful scripts written in Zig not bash (for one, bash doesn't work on Windows without WSL and we need to support Windows builds/testing/etc.).

It makes about as much sense as any other cross-platform scripting option once I got used to it!

Some examples:

Docs generation: https://github.com/tigerbeetledb/tigerbeetle/blob/main/src/c...

Integration testing sample code: https://github.com/tigerbeetledb/tigerbeetle/blob/main/src/c...

Running a command wrapped in a TigerBeetle server run: https://github.com/tigerbeetledb/tigerbeetle/blob/main/src/c...

Re: Zig is hard but worth it

#19

Post by TwentyPosts »

thadt wrote: 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 simple questions, and this is (sadly) not obvious at all to newcomers to the language.

Re: Zig is hard but worth it

#20

Post by chjj »

bakuninsbart wrote: post #6

Where do you guys see good use cases for Zig? I'm intrigued by the language but don't really have any good ideas on where to try it out. I thought about trying it out in as small data engineering project, but I'm not sure if language support is sufficient for the kind of tooling I would need eg. Database adapters.

Do you maintain any C projects? Personally, I tried using zig for its build system (which can also compile C and whose build files are written in zig). One of the benefits of this was easy cross-compilation to all major platforms.

It might not be a _real_ use-case or anything, but writing a `build.zig` file for an existing C project might be a good way to at least dip your toe in the water.

Post reply on HN