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

261–270 of 307 posts

Re: Zig is hard but worth it

#261

Post by anonymoushn »

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…

You can use = for structs at least :)

Re: Zig is hard but worth it

#262

Post by throwawaymaths »

flohofwoe wrote: post #133
throwawaymaths wrote: post #126

Earlier quoted context omitted.

Probably not. @Vector is not a mathematical vector, it's SIMD. it makes sense because there are times when those live in registers and a poly fill for stack memory isn't burdensome. @Matrix makes less sense because when it gets big, where are you getting memory from?

For 'game-ey' math code, a matrix is at most 4x4 floats (64 bytes), that's fine for a value type that might live on the stack. vec2..4 and matching matrix types up to 4x4 is basically also what's provided in GPU shading languages as primitive types, and personally I would prefer such a set of "SIMD-y" primitive types for Zig (maybe a bit more luxurious than @Vector, e.g. with things like component swizzling syntax -…

Sure, but people are going to want to use operator overloading for, e.g. dl/ml

Re: Zig is hard but worth it

#263

Post by throwaway2037 »

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 think Zig falls into an "easy to learn, average/hard to master"
Thank you for sharing an insider's account. I naively assume that Zig is not your first language. Regarding "average/hard to master", can you think of any of languages where this is not true? Zero trolling, I promise. My point: No language is any less than average to master. Even VBA has some weird stuff in it that used to catch me off guard when I wrote Excel apps years ago. To be clear, I would classify VBA as similar, but I would classify Python as "easy to learn, very hard to master", and Perl as "average to learn, impossible to master"(!).

Re: Zig is hard but worth it

#264

Post by throwaway2037 »

thayne wrote: post #259
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

A lot of what a package manager does isn't really language dependent. It seems like it would be possible to build a generalized package manager that has hooks for a language specific plugin to control how the package is extracted, how to resolve transitive dependencies, and how to do any additional build steps. It would be sort of analogous to how instead of building a full IDE, you can implement an LSP server and ge…

High level: I appreciate the point being made here. Challenge: If true, why does it not already exist? Idea: Apache Maven repositories use pom.xml to define dependency trees. Why don't these get used more for non-Java'ish languages? Mind you, I am not advocating to use Apache Maven as a build tool. I am noting that (remote) repos and their dependency metadata are a huge achievement in that ecosystem.

Re: Zig is hard but worth it

#265

Post by brundolf »

xormapmap wrote: post #247
chrsig wrote: post #94

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

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

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

Re: Zig is hard but worth it

#266

Post by j-james »

TUSF wrote: post #223
j-james wrote: post #216

Earlier quoted context omitted.

Yeah, I read through that: unless I'm missing something I think what I'm curious about is "calling C code from Zig and vice versa" in the to-be-written section. Nim also has support for `ctypes` and compiles to C as its main target: yet though its interop is powerful it lacks in ergonomics, formerly you had to manually wrap every function you wished to use and this was only recently fixed by a macro-heavy external li…

With Zig, you just write something like: const c = @cImport({ @cDefine("SOME_MACRO", "1"); @cInclude("raylib.h"); }); Which translates the header files directly into Zig and allows you to call into them under whatever namespace you assigned them under. You even get completions (assuming you're using the language server)

Right, but I'm curious about the calling-Zig-from-C interop, not the other way around.

Re: Zig is hard but worth it

#267

Post by Kamq »

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

I guess I don't see C as programming language for writing scripts in either. In my view any language that requires a separate complication step is not a scripting language, and therefore not a language in which one writes scripts. In C or Zig you write programs. Maybe I am just being too pedantic.

A number of languages that would have been traditionally compiled (statically typed, produce a native binary by default, etc), have started adding a "run" command.

If your language compiles fast enough, it's about the same experience as running a python script.

Re: Zig is hard but worth it

#268

Post by chlorion »

felixgallo wrote: post #25
jsheard wrote: post #16

Earlier quoted context omitted.

Zig looks like a fine C replacement, but C isn't what people are using to make games in the vast majority of cases. It's all C++, and operator overloading is part of the "sane subset" that everyone uses even if they hate the excesses of modern C++ as a whole.

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.

>That's some spooky action at a distance nonsense.

In pretty much all languages operators are just sugar for calling a method. There is no difference other than an easier to read syntax.

In rust for example, doing a + b is exactly the same as doing a.add(b).

In python it's exactly the same as doing a.__add__(b).

In C++, my understanding is that its sugar for a.operator+(b) or operator+(a, b).

I think there are some arguments against operator overloading but "spooky action at a distance" doesn't seem to be a very good one to me.

Re: Zig is hard but worth it

#269

Post by thayne »

throwaway2037 wrote: post #264
thayne wrote: post #259

Earlier quoted context omitted.

A lot of what a package manager does isn't really language dependent. It seems like it would be possible to build a generalized package manager that has hooks for a language specific plugin to control how the package is extracted, how to resolve transitive dependencies, and how to do any additional build steps. It would be sort of analogous to how instead of building a full IDE, you can implement an LSP server and ge…

High level: I appreciate the point being made here. Challenge: If true, why does it not already exist? Idea: Apache Maven repositories use pom.xml to define dependency trees. Why don't these get used more for non-Java'ish languages? Mind you, I am not advocating to use Apache Maven as a build tool. I am noting that (remote) repos and their dependency metadata are a huge achievement in that ecosystem.

> If true, why does it not already exist?

Because no has put in the effort to build it and get it adopted. You could also ask why we didn't have something like LSP earlier. In order for such a project to become widely adopted it would need to work well for at least a few popular languages, and work at least approximately as well as the native package management solutions for those languages. And it would need to be easy to use. You can kind of use some existing tools, such as maven, bazel, even npm, for other languages, but it usually isn't as nice of an experience.

Re: Zig is hard but worth it

#270

Post by nickcox »

throwawaymaths wrote: post #251
xormapmap wrote: post #247

Earlier quoted context omitted.

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

Nobody is reviewing it. They are rejecting malformatted code in CI step.

That's not the workflow your GP is describing.
Post reply on HN