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

91–100 of 307 posts

Re: Zig is hard but worth it

#91

Post by riceart »

TwentyPosts wrote: post #64
distcs wrote: post #44

Earlier quoted context omitted.

> If any kind of automatic memory isn't possible/allowed, I would be reaching out for Rust I have come to the same conclusion but then I also fear that Rust will continue to expand in scope and become a monster language like C++. Do you or anyone fear that? Is that a possibility?

Will Rust keep growing? Yes, I think so. Will it turn into a C++-like monster? I don't know. Maybe, but when it comes to C++ it always feels like its "monster" status is largely a result of previous mistakes or early design decisions piling up, and causing trouble (eg. C-style arrays, exceptions, implicit conversions, fiddly sum types rather than first class support, no pattern matching etc.). Rust will grow large, a…

> Time will tell if we'll eventually look back some of Rust's design decisions as bad or unwieldy (probably).

I think time has already told for things like async and lifetimes.

Re: Zig is hard but worth it

#92

Post by pacaro »

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.

I understand this, but haven't found this to be an issue personally. I just download the pre built tarball, expand it, make sure that /opt/zig-latest symlinks to the right folder, and setup path

That's more work than apt-get install for sure, but not so much more

Re: Zig is hard but worth it

#93

Post by flohofwoe »

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.

Zig has a builtin @Vector type that might come in handy for most cases where in C++ a math library with operator overloading would be used:

https://www.godbolt.org/z/7zbxnncv6

...maybe one day there will also be a @Matrix builtin.

Re: Zig is hard but worth it

#94

Post by chrsig »

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

> 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'

Re: Zig is hard but worth it

#95

Post by truckerbill »

59nadir wrote: post #79
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…

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?

Re: Zig is hard but worth it

#96

Post by mr_00ff00 »

TaupeRanger wrote: post #52

Maybe a few years ago it would've been "worth it". But with LLMs coming to swallow up all coding tasks and turning programmers into prompt engineers within a few years time, I can't see it being "worth it" any more.

I don’t want to make assumptions, but have you tried systems programming with LLMs?

A few years and everyone will be prompt engineers is laughable. I hope I can actually use it productively for more than unit tests in a few years.

Re: Zig is hard but worth it

#97

Post by GordonS »

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

Damn, that's a magnificent feature! Maybe I should have another look at Zig...

Re: Zig is hard but worth it

#98

Post by helen___keller »

loeg wrote: post #75
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(...)…

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

Re: Zig is hard but worth it

#99

Post by TylerE »

arp242 wrote: post #88
ReleaseCandidat wrote: post #82

Earlier quoted context omitted.

> I'm not so sure a package manager is really all that essential; For open source software (libraries or programs, that depend on other libraries or programs), it is essential (if you're not distributing single functions like with Unison). For closed source it doesn't matter that much.

"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]

Re: Zig is hard but worth it

#100

Post by pron »

ImprobableTruth wrote: post #57
pron wrote: post #43

Earlier quoted context omitted.

C++ templates. Also the rich type-level language in languages like Idris (these are qualitatively different, but I'd say they're another example of a second-language-within-a-language that operates at a different level of objects).

If type level functions are a "second language", then so is Zig's comptime.

It's not. comptime reifies types as regular objects (pretty much like maps), so you're not working at the type level; it's no more of a second language than reflection in Java. Of course, you cannot express things like the famous vector concatenation that's expressible with dependent types (https://gist.github.com/cbiffle/82d15e015ab1191b73c3) (unless the vector sizes are known at compile time, obviously).
Post reply on HN