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

151–160 of 307 posts

Re: Zig is hard but worth it

#151

Post by pklausler »

parasense wrote: post #145

The main take away is: > Something that makes Zig harder to learn up front, but easier in the long run is lack of undefined behavior. Reminds me of the old discussions of Fortran Vs C, and specifically in the early times before C had a standard library. What we call "undefined behaviour" was just an idiom of the language where the "behaviour" was sometimes on purpose, but recognised might not be portable. And so the…

Ironically, C is now way more portable than modern Fortran is. The Venn diagram of feature portability across the 6 or 7 actively-maintained Fortran compilers is very messy.

Re: Zig is hard but worth it

#152

Post by savolai »

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

Would love to understand better what exactly is language specific about package managers? You would think a winner would emerge in this space like one has in version control to be used with all languages, just separate repos for different ecosystems?

Re: Zig is hard but worth it

#153

Post by galaxyLogic »

Love the picture. People often say how easy something was for them. They are saying they are a very capable, smart person. Would you rather hire someone for whom everything is easy, or someone for whom things seem difficult?

In other words saying they learned something fast or that something is easy for them, is at least partially self-promotion. So claims of how easy something was for them it have to be taken with a grain of salt.

The interesting thing for the rest of us is WHY something is easy, or difficult. That would be helpful for others to know. This article is just that, it tells us why Zig can be difficult. What to look out for.

Re: Zig is hard but worth it

#154

Post by gen220 »

johnnyjeans wrote: post #115
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 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 peripher…

Just curious, not snide: what language fits this criteria?

C/C++? Using Python 3.7+ in a way that completely ignores Pip, because the stdlib is now quite expansive?

Re: Zig is hard but worth it

#155

Post by hellcow »

markisus wrote: post #139
pron wrote: post #38

Earlier quoted context omitted.

As someone who works on another language that is relatively reluctant to add language features (Java) we regularly face such dilemmas. A user shows up with a problem that could be helped by the language. The problem is real and a language feature would work, but there are many such problems, and adding features to solve all of them will make the language much bigger, overall causing greater harm (even those who don't…

In robotics, numerical linear algebra expressions comprise a large part of the code base. If not by line count, then definitely by the amount of time spent writing, reading, and debugging such code. This makes Zig unusable for these applications, at least not without additional tooling. You can get a feel for how unergonomic this is by avoiding the use of all arithmetic operators in your code and instead forcing your…

Using plus(a,b) for complex types sounds fine to me… I have to imagine if I were working with a huge file of these for a while it would start to feel normal, just like every language has a different syntax but you eventually feel comfortable using.

Re: Zig is hard but worth it

#156

Post by clessg »

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…

> but it also removes the case of hacking up something in 10 days and suffering the consequences for the next 30 years

Ha, I thought this sounded distressingly familiar!

"In September 1995, a Netscape programmer named Brandan Eich developed a new scripting language in just 10 days. It was originally named Mocha, but quickly became known as LiveScript and, later, JavaScript."

Re: Zig is hard but worth it

#157

Post by paulddraper »

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

> new languages are expected to boil the ocean by the time they reach 1.0

The reason is that there are existing high-quality languages/ecosystems.

(Which is a good thing!)

Re: Zig is hard but worth it

#158

Post by mr_00ff00 »

adastra22 wrote: post #114
mr_00ff00 wrote: post #50

Earlier quoted context omitted.

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.

Maybe I need to give bevy a second go. My big issue is I felt I was learning to speak “bevy” instead of using rust. A lot of functions I wrote required queries of components, but the queries were built and called behind a magically wall.

I don’t have much game dev experience though outside of simple games using libraries like raylib to just move and draw stuff. Maybe once things get complicated enough they are all like bevy.

Re: Zig is hard but worth it

#159

Post by paulddraper »

gen220 wrote: post #154
johnnyjeans wrote: post #115

Earlier quoted context omitted.

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

Just curious, not snide: what language fits this criteria? C/C++? Using Python 3.7+ in a way that completely ignores Pip, because the stdlib is now quite expansive?

Must be C/C++.

Re: Zig is hard but worth it

#160

Post by kllrnohj »

LispSporks22 wrote: post #118

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

Personally I think comptime is a questionably design and is something both Rust & C++ did much better.

In C++ branches that don't have to "compile" are explicitly marked as such with `if constexpr`. In Rust you've got macros that are also explicit with required `!`. In Zig any branch can be a ticking code rot time bomb, just like it was with C #ifdefs. It's better in Zig in that it at least has to parse and so you've got fewer blatant problems, but the category of problems of "I flipped DEBUG from `false` to `true` and now I have dozens of build errors to go fix" is still there. And you really don't have any warning signs other than "this is branching on something that might be known at compile time"

But honestly that's also my general impression of Zig as a whole. It's very definitely a "better C", not something that's necessarily good/competitive with the broader state of the ecosystem. It's like a love letter to C, completely with many of the same general problems that C is known to have and that other languages have addressed.

Post reply on HN