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

111–120 of 307 posts

Re: Zig is hard but worth it

#111

Post by afdbcreid »

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

C interop is not as much a "killer feature" as it used to be. When you deal with data science, web and other similar domains, reading and writing JSON ergonomically is much more important than being able to call a C function directly. It's just a nice-to-have.

Yeah, but when you're doing systems programming (which Zig aims at if I understand correctly), easy interop with C is much more important than easy JSON marshalling.

Re: Zig is hard but worth it

#112

Post by helen___keller »

rayiner wrote: post #81
helen___keller wrote: post #68

Earlier quoted context omitted.

If we’re comparing C to Zig I’m not sure what memory safety even needs to be mentioned for. For C to Zig there’s plenty of reasons one might prefer Zig. For memory safety obviously you might opt to choose neither.

In a vacuum, one might prefer Zig. But given that everyone already knows C and the ecosystem is so highly developed, it takes a gamechanging feature like Rust's memory safety to make an alternative language attractive (beyond a "this is cool" project--which I totally support).

That is probably why Zig has such a focus on seamless C interop. There’s a good thread in these comments talking about this.

Regardless, point taken. You’re more or less describing the internal fear I have (mentioned in another thread) that if I dedicate time to a nontrivial Zig project I will regret it if/when there’s no Zig community in N years

Re: Zig is hard but worth it

#113

Post by pjmlp »

riceart wrote: post #91
TwentyPosts wrote: post #64

Earlier quoted context omitted.

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.

async, yeah it could be better, given the pains. However note that adding async to .NET and C++ hasn't been a panacea either, to the point that there is a prototype of adding Go/Java green threading to .NET, done by the .NET team. While with the C++ standard library there isn't an executor runtime in the box.

Lifetimes are painful, and a other languages are exploring better ergonomics or combining automatic memory management with affine/linear types, yet it was Rust's adoption that pushed other language designers to actually look into this. So from that point of view, quite a success, even if Rust vanishes tomorrow.

Re: Zig is hard but worth it

#114

Post by adastra22 »

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.

Have you tried bevy? I’m starting with bevy for a non-game project, but I’m blown away by how simple it is to use once you get used to the magic.

Re: Zig is hard but worth it

#115

Post by johnnyjeans »

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 disagree. I actively avoid languages that rely on package managers simply because they only give the illusion of being beneficial. It ends up being more boilerplate I have to learn to use an ecosystem, because they don't actually solve dependency hell and now there's a whole additional complicated tool with its own DSL I have to contend with in order to fix what's broken (or even diagnose issues.)

The more peripheral crap I have to deal with to use your language, the less I'm likely to use it in the first place. I don't need, want or care to learn yet another idiosyncratic fragile system. Finding source tarballs is a complete non-issue, and inevitably I'm going to have to manually build things anyways to figure out what erroneous assumption a library is making about the underlying system which is causing the build to fail or the runtime to crash, so the package manager just ends up being extra steps. Without fail, that has always been my experience with language package managers.

In the pursuit of making things simpler, we're really just making them harder.

Re: Zig is hard but worth it

#116

Post by flohofwoe »

Taywee wrote: post #60
felixgallo wrote: post #25

Earlier quoted context omitted.

as a long time game dev, I actively don't want operator overloading. That's some spooky action at a distance nonsense. I'm not sure I have seen a codebase that involved operator overloading, either, and I've worked in or near a good quantity of well-known titles.

You'd rather use explicit function calls for all linear algebra and geometry operations? I don't think adding two vectors using an overloaded + is that spooky or distant.

FWIW Zig can do that without operator overloading: https://www.godbolt.org/z/7zbxnncv6

Re: Zig is hard but worth it

#117

Post by [deleted] »

Symmetry wrote: post #83
pron wrote: post #24

Earlier quoted context omitted.

The objects that are manipulatable by comptime are ordinary program objects and types -- not ASTs. That means that while it's true you can get compile-time errors in similar situations to macros, the errors themselves are like ordinary runtime errors in an untyped language -- while occurring at compile-time, they look like runtime error in Python or JS -- rather than errors due to some "second-order" manipulation of…

I haven't had a chance to play with comptime in Zig yet but I'm sort of curious how it compares to Nim's compile time facilities. You can declare variables with 'var' for true variables, 'let' for things that are runtime constant within a scope, or 'const' for compile time constants whose values can come from functions or whatever as long as it can be resolved by the compiler. And then you've got 'when' as a compile…

[deleted]

Re: Zig is hard but worth it

#118

Post by LispSporks22 »

> Only time will tell if comptime is the "greatest thing since sliced bread" or not.

Common Lisp user here. Am I missing anything that Zig has in the compile time department?

edit: Also, does the code in the comptime block have to be valid Zig?

Re: Zig is hard but worth it

#119

Post by haberman »

rayiner wrote: post #37

Alternative languages are cool, but I struggle to see the point of a systems programming language that doesn't offer static memory safety in 2023. Rust isn't necessarily the best and final answer--it seems like there is a broad design space to explore for memory-safe systems programming languages. But Zig seems to occupy the same local maximum as C--a relatively simple, non-safe systems language--and doesn't have a k…

The killer feature of Zig IMO is comptime. C++ has spent over a decade now marching towards making more and more of the language available at compile time, but in an awkward and complicated way (constexpr, consteval, constinit). Zig comes out of the gate with a unified and coherent compile-time evaluation feature that effectively obsoletes not only constexpr/consteval/constinit, but C++ templates too. This is "doing more with less" in a way that I find really compelling.

Re: Zig is hard but worth it

#120

Post by jsheard »

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

That still breaks if you layer any abstractions on top, for example if you wanted to build an AoSoA packet of Vec3s you'd have to define an addition of those in terms of a function.

https://www.godbolt.org/z/v8Ta8hEbv

Zig is exactly the kind of language where you'd want to build a performance-oriented primitive like that, but AFAICT the language doesn't let you do it ergonomically.

Post reply on HN