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

251–260 of 307 posts

Re: Zig is hard but worth it

#251

Post by throwawaymaths »

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…

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

Re: Zig is hard but worth it

#252

Post by hyperhopper »

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…

You're looking at it the wrong way

People review code. As soon as that happens, formatting is part of the conversation. Either consciously or subconsciously

Re: Zig is hard but worth it

#253

Post by AndyKelley »

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.

let me clarify some facts.

1. we never distributed debs for debian distributions. I have, however, been patiently collaborating with Debian maintainers with regards to the zig ITP: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=995670

2. we don't tell you to "just use a snap.". Please see https://github.com/ziglang/zig/#installation

3. we tag releases soon after llvm tags releases for the convenience of package maintainers. Distributions with LLVM 14 can package Zig 0.9.1; distributions with LLVM 15 can package Zig 0.10.1, etc.

Re: Zig is hard but worth it

#254

Post by shrimp_emoji »

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

I gave it a go with openGL and Rust, was great until I needed some external C++ libraries.. Then I lost motivation and rewrote the whole thing in C++

Name checks out

<33

Re: Zig is hard but worth it

#255

Post by throwawaymaths »

pornel wrote: post #243
JohnFen wrote: post #212

Earlier quoted context omitted.

I suppose that I just never had a problem maintaining any dependencies in code I write. Package managers have long been a bit of a pain for me as a developer, and with some languages (like Python), they are a huge PITA for me as a normal user of applications. So overall I don't view them in a very positive light. They're something I have to put up with. No matter, it is what it is. Carry on. :)

When Python was originally designed disk space was precious, and access to the Internet was rare, and its dependency management was designed for that world. Its multiple retrofitted package managers never fully fixed it. However, better integrated package managers can work well. In case of Node.js and Cargo, the main argument against them is that it's too easy to add dependencies.

Fundamentally the problem with python is that it's packages are global and every workaround except ~docker can't fix it except in a hacky way since the package resolution is specified in the language

Re: Zig is hard but worth it

#257

Post by 2h »

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…

here is this persons GitHub. posting because its missing from their blog for some reason:

https://github.com/karlseguin

Re: Zig is hard but worth it

#258

Post by haberman »

Conscat wrote: post #184
haberman wrote: post #119

Earlier quoted context omitted.

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…

Zig does not have anything analogous to constinit, because Zig does not have object lifetimes or constructors. Comptime is also a massive pain to use for generating new data types (you have to return a type from a comptime function), and it cannot express anything analogous to CRTP.

I personally find returning a type from a comptime function to be quite elegant. Template parameters and regular parameters are unified into a single concept.

Zig's comptime is analogous to constinit, because it lets you compute a value at compile time and ensure that it is linker-initialized into the final binary image.

The point about CTRP is interesting, I'd have to think about that some more.

Re: Zig is hard but worth it

#259

Post by thayne »

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

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 get support from existing IDEs and editors.

Re: Zig is hard but worth it

#260

Post by patmorgan23 »

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…

The point of the auto formatter is to get those slight differences out of the way so your Brian can focus on parsing and understanding the important parts
Post reply on HN