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

101–110 of 307 posts

Re: Zig is hard but worth it

#101

Post by hoosieree »

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.

Binary executables are a nice feature, especially for distributing to users.

It's much easier for most people to download a standalone "mac" or "windows" binary than to know if they already have the right version of Python or Perl or Clang (and all the transitive dependencies your project adds).

Re: Zig is hard but worth it

#102

Post by TylerE »

helen___keller wrote: post #98
loeg wrote: post #75

Earlier quoted context omitted.

> 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(...)…

Yes you can easily make a one liner allocation function in zig that takes an allocator as input with a comptime type and panics if allocation fails and returns the unwrapped allocation I just say nuisance because zig code often looks like Go code in that almost every return type becomes an error union as allocation error handling (and maybe other errors) trickle up

From my experience with Zig (limited but not zero) it seems like an ok solution to a problem I don't have, and don't forsee having.

Re: Zig is hard but worth it

#103

Post by hiccuphippo »

JC770 wrote: post #90
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 just start to learn Zig,any suggest to beginners?Bro

Other than the main documentation, check ziglearn.org and ziglings.org. Also read the std code, specially the tests when you want to know how to use something.

Re: Zig is hard but worth it

#104

Post by pron »

auggierose wrote: post #80
pron wrote: post #66

Earlier quoted context omitted.

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 differen…

> Referentially transparent means that you can replace an expression with its value without changing the meaning of the program.

Not quite. A referentially transparent expression (E) is one where you can replace any of its subexpressions (A) with another (B) that has the same meaning (not value!!!!) as (A) without changing the meaning (not value!!!) of E. However, in purely functional languages, the meaning of any expression is a value, but that's the important thing about them, not the fact that they're referentially transparent as imperative languages equally are. We often use the word "semantics" or "denotation" instead of "meaning" in the above, and we say that a pure functional one is one that has "value semantics", i.e. one where the meaning of an expression is a value.

Most programming languages are referentially transparent when not using macros (that was the whole point of talking about referential transparency in programming in the first place), and that's important because it demonstrates both the expressive power and the complexity of macros.

Re: Zig is hard but worth it

#105

Post by eatonphil »

hoosieree wrote: post #101
eatonphil wrote: post #49

Earlier quoted context omitted.

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.

Binary executables are a nice feature, especially for distributing to users. It's much easier for most people to download a standalone "mac" or "windows" binary than to know if they already have the right version of Python or Perl or Clang (and all the transitive dependencies your project adds).

We don't host the built binaries of these scripts (we could!), but we bootstrap the local environment through a single bash script or batch script (Windows) that pulls down the Zig compiler. Then everything else in the repo depends only on that until we get until client-language specific bits which of course depend on other languages.

But yeah it is quite simple still.

Re: Zig is hard but worth it

#107

Post by netule »

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

Zig's in the process of getting added to the mainline Debian repositories: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=995670

Hopefully, this process will continue soon as the bug seems to be getting a bit stale.

Re: Zig is hard but worth it

#108

Post by scns »

TwentyPosts wrote: post #19
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 si…

The new Zulip version can make chats accessible from the outside. In the thread about it someone wrote OSS Projects should switch to it.

Re: Zig is hard but worth it

#109

Post by anta40 »

jasfi wrote: post #69

Nim isn't hard, it just has a small community.

I haven't done any production-level stuff with Nim (still learning it), I think overall it's a nice language (I also like Python & Pascal).

If your goal is applying for job, Go is obviously a better pick.

Re: Zig is hard but worth it

#110

Post by tuckerpo »

TylerE wrote: post #99
arp242 wrote: post #88

Earlier quoted context omitted.

"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 No…

[flagged]

Why? A submodule can be frozen at a given commit. They're trivially updated or rolled-back, too.
Post reply on HN