←back to thread

Zig is hard but worth it

(ratfactor.com)
401 points signa11 | 7 comments | | HN request time: 0.448s | source | bottom
Show context
latch ◴[] No.36150665[source]
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 of package manager, etc. For an insider living and breathing Zig, not only aren't these huge challenges, they aren't really "Zig" - they are just transient growing pains. For someone getting started though, the current state of Zig is Zig.

I wish Zig had a polished package manager (there's one in the current development branch, but you don't as much use it as fight it). They could then move some of the less polished code into official experimental packages, helping to set expectations and maybe focus the development efforts.

replies(7): >>36151206 #>>36152145 #>>36153037 #>>36153777 #>>36159350 #>>36159799 #>>36178599 #
zoogeny ◴[] No.36151206[source]
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

replies(8): >>36151679 #>>36152038 #>>36152323 #>>36152773 #>>36153966 #>>36154058 #>>36155307 #>>36159420 #
chrsig ◴[] No.36152323[source]
> 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 to boil the ocean by the time they reach 1.0

In order to get into production? yes. there are minimum requirements that must be met. those are higher now than in the past, because of lessons learned the hard way. those problems have been solved (for some value of solved) in existing ecosystems -- a new language wont change the need for them to be solved.

it shatters the dream of hacking up something on a weekend and having it turn into a hit success, but it also removes the case of hacking up something in 10 days and suffering the consequences for the next 30 years.

Until they have what you mentioned, the languages aren't ready for large scale use -- they need to grow into it. They can be useful prior to that -- enthusiasts and early adopters can reap what benefits are provided. That adoption is what fuels the development of things like a standard code formatter.

edit: fixed omission of a unit of time after '30'

replies(4): >>36154051 #>>36156226 #>>36158675 #>>36162098 #
1. xormapmap ◴[] No.36158675[source]
> 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.

replies(5): >>36158750 #>>36158795 #>>36158810 #>>36159451 #>>36159851 #
2. xxpor ◴[] No.36158750[source]
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.

3. throwawaymaths ◴[] No.36158795[source]
Nobody is reviewing it. They are rejecting malformatted code in CI step.
replies(1): >>36160435 #
4. hyperhopper ◴[] No.36158810[source]
You're looking at it the wrong way

People review code. As soon as that happens, formatting is part of the conversation. Either consciously or subconsciously

5. patmorgan23 ◴[] No.36159451[source]
The point of the auto formatter is to get those slight differences out of the way so your Brian can focus on parsing and understanding the important parts
6. brundolf ◴[] No.36159851[source]
In addition to reviews, I've started to really enjoy format-on-save as a way to save keystrokes. Instead of manually formatting my code (even for myself), I can take the shortest editor path to the AST that I want and then have everything else snap into place
7. nickcox ◴[] No.36160435[source]
That's not the workflow your GP is describing.