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

241–250 of 307 posts

Re: Zig is hard but worth it

#241

Post by bsder »

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…

> 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

This is 100% a real concern.

If I'm going to choose Zig, it's because it is SO much better on some axis that the community/adoption isn't an issue as I gain the benefits almost immediately. That means that C++ and Rust probably aren't in the scope of choice anyway.

I especially like the comment from elsewhere in thread where they are using it for scripting, of all things, because they can pop out code that builds and works on Windows and Linux. That's a good example--you gain the benefits immediately even if you later have to unwind that to something like Python.

Re: Zig is hard but worth it

#242

Post by Tozen »

VyseofArcadia wrote: post #127
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 used Zig for a weekend project and loved it, but I am resolved to not use it for anything else until it hits 1.0. I don't have time to write and re-write and re-re-write my code as the language and stlib stabilize.

If that's the thinking, looks like it will be a long wait. Appears to be another 2 to 3 years before 1.0 hits. And it publicly came out in 2016, so add all those years up.

Re: Zig is hard but worth it

#243

Post by pornel »

JohnFen wrote: post #212
pornel wrote: post #203

Earlier quoted context omitted.

Is every language supposed to come with HTTP and TLS stack, clients for every database, de/serializers for every format, every image and video codec, every de/compressor, GUI toolkits, 3D rendering, Bluetooth… where do you stop? And then how do you maintain all of this bloat to a competitive level, so that users don't need to reach for faster/newer alternative packages anyway? And how do you maintain portability and…

I suppose that I just never had a problem maintaining any dependencies in code I write. Package managers have long been a bit of a pain for me as a developer, and with some languages (like Python), they are a huge PITA for me as a normal user of applications. So overall I don't view them in a very positive light. They're something I have to put up with. No matter, it is what it is. Carry on. :)

When Python was originally designed disk space was precious, and access to the Internet was rare, and its dependency management was designed for that world. Its multiple retrofitted package managers never fully fixed it.

However, better integrated package managers can work well. In case of Node.js and Cargo, the main argument against them is that it's too easy to add dependencies.

Re: Zig is hard but worth it

#244

Post by Tozen »

truckerbill wrote: post #95
59nadir wrote: post #79

Earlier quoted context omitted.

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…

I want to invest in Odin but I see the velocity and growing mindshare that Zig has and I wonder if it's not better to settle for that. Also how do you find the compile times?

Part of "mindshare" are organizations pushing it on social media and marketing. Choose the language that solves your problems and that you like. Don't make a choice because a group is telling you what to like, is bullying others because they like something different, or are trying to shove something down your throat for their profit or benefit. Perfectly fine to have an independent mind, and make decisions best for you.

Re: Zig is hard but worth it

#245

Post by beefcafe »

workethics wrote: post #51
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.

Not only that, but zig makes linking against old glibc versions easy. For example, to make an x86_64 linux build linked against glibc 2.9 when using zig build all you have to do is pass: -Dtarget=x86_64-linux-gnu.2.9

This is a killer feature for CTFs/OSCP/etc and why I started using it.

Re: Zig is hard but worth it

#246

Post by bitshiffed »

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.

I love this part about zig too. It definitely makes interop with, or gradual migration from, C, much easier.

It's also the source of my major problem with zig. It doesn't have its own ABI [1].

So, if for example, you want to write a library in zig, to be used by others from zig, they must build your library with their project. That may not be an issue for smaller things; but for a large library I'd really like consumers to be able to pull in a binary with just a definition (header) file. Since zig uses the C ABI, that would currently mean translating everything to and from C at the binary interface, and losing all ziggyness in the process.

[1] https://github.com/ziglang/zig/issues/3786

Re: Zig is hard but worth it

#247

Post by xormapmap »

chrsig wrote: post #94
zoogeny wrote: 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

> 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. Agreed. Especially on a formatter. The number of code review comments it cuts out is incredibly time and energy saving. > 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…

> Agreed. Especially on a formatter. The number of code review comments it cuts out is incredibly time and energy saving.

Are people realistically reviewing code formatting? As long as people aren't making egregious violations I generally don't care if someone leaves a brace on the same line or writes a one-line if statement. I tend to review the overall design and look for bugs and edge cases that might've been missed. If somebody told me they didn't like the way I formatted the code then they've got their own editor and are welcome to change it if they want to be petty.

Re: Zig is hard but worth it

#248

Post by markisus »

erichocean wrote: post #238
KerrAvon wrote: post #236

Earlier quoted context omitted.

Why do you think this is true of Lisps? Emmy would not seem to be a good example because it actually does overload arithmetic operators to support extended data structures. Look at, for example: https://cljdoc.org/d/org.mentat/emmy/0.30.0/doc/data-types/m...

> forcing yourself to use user defined plus(a,b), minus(a,b), assign(a,b) This is the complaint I was responding to. Here is that code in Clojure (a Lisp): // What the GP claims is bad for doing math: plus(a,b) minus(a,b) assign(a,b) // Lisp doesn't have "operators", so it doesn't have "operator overloading." What it does have is multi-dispatch, so yeah, the implementation of `+` can depend on the (dynamic) types of…

By assign(a,b) I meant to denote the copying of the matrix b into the matrix a. The ability to use arithmetic symbols `+` and `-` as function identifiers definitely aids in readability but I don't think this is possible in Zig.

I am not familiar with Emmy but I'm guessing that the usual work flow will involve an interactive shell with many calls to `render` to display expressions in infix notation so that you can better check if the expression you typed is actually what you meant to type.

The infix notation, although arbitrary and not as logically simple as other notations, is almost universal in the math-speaking world. Most mathematicians and engineers have have years of experience staring at infix expressions on blackboards, and disseminate new knowledge using this notation, and do new calculations in this notation.

In reading your reply, I think that maybe some tooling that could auto-insert corresponding infix-like comments above an AST-like syntax could be a solution for writing such code in Zig.

Re: Zig is hard but worth it

#249

Post by xxpor »

xormapmap wrote: post #247
chrsig wrote: post #94

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. Agreed. Especially on a formatter. The number of code review comments it cuts out is incredibly time and energy saving. > 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…

> Agreed. Especially on a formatter. The number of code review comments it cuts out is incredibly time and energy saving. Are people realistically reviewing code formatting? As long as people aren't making egregious violations I generally don't care if someone leaves a brace on the same line or writes a one-line if statement. I tend to review the overall design and look for bugs and edge cases that might've been miss…

Absolutely. Inconsistency is sloppy, increases cognitive burden while reading code, and can hide bugs.

Everyone should take the time to setup their editor to format their code consistent with the project style, it doesn't take long at all.

Re: Zig is hard but worth it

#250

Post by i_am_a_peasant »

mr_00ff00 wrote: post #50
bodge5000 wrote: post #11

Earlier quoted context omitted.

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

Would love to see zig in game dev. I’ve tried some rust and while I love rust in general, I find game dev in it a bit of a mess.

I gave it a go with openGL and Rust, was great until I needed some external C++ libraries.. Then I lost motivation and rewrote the whole thing in C++
Post reply on HN