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

301–307 of 307 posts

Re: Zig is hard but worth it

#301

Post by Tiberium »

girvo wrote: post #86
TwentyPosts wrote: post #19

Earlier quoted context omitted.

Afaik Zig has the issue that basically everything happens on the Discord server, where it can't be indexed via search engines, or found by anyone who wants to have a quick question answered. This would be "fine" if the standard library and language were much better documented, but it isn't, and it's still ripe with bugs. In other words, you're forced to use the Zig Discord server if you want to find answers to any si…

This is true for Nim as well, in that most of the discussion is on the Discord/Matrix server. I’m not a fan personally, at least IRC was easily archived and searchable in practice. I really dislike how Discord has become “forums in the 2020s”

This is not actually true for Nim - almost all Nim Discord channels are bridged to different IRC channels, see https://github.com/nim-lang/Nim/wiki#bridged-real-time-chats

Re: Zig is hard but worth it

#302

Post by TDiblik »

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

Hi, why is this feature interesting/important? (Coming from [uneducated] webdeveloper with interest for systems/embedded programming)

Re: Zig is hard but worth it

#303

Post by throwawaymaths »

zaphirplane wrote: post #296
throwawaymaths wrote: post #293

Earlier quoted context omitted.

Try installing two pieces of software that depend on two different versions of tensorflow, then come back here.

I can install multiple python interpreters side by side each with independent packages and I can install different versions of the same python package for the same interpreter. I haven’t tried or had a need, by induction sounds possible :shrug:

Tensorflow wheels are bound to cuda installation which is driver/sudo level. It's a nightmare.

Re: Zig is hard but worth it

#304

Post by girvo »

Tiberium wrote: post #301
girvo wrote: post #86

Earlier quoted context omitted.

This is true for Nim as well, in that most of the discussion is on the Discord/Matrix server. I’m not a fan personally, at least IRC was easily archived and searchable in practice. I really dislike how Discord has become “forums in the 2020s”

This is not actually true for Nim - almost all Nim Discord channels are bridged to different IRC channels, see https://github.com/nim-lang/Nim/wiki#bridged-real-time-chats

Oh that's nice, I thought the IRC bridge had been left to languish. Good to know I was wrong!

Re: Zig is hard but worth it

#305

Post by nyberg »

notfed wrote: post #225
logicchains wrote: post #67

Earlier quoted context omitted.

When you need to be very careful about memory allocation and use various custom allocators for stuff, and you don't care too much about memory safety. Rust makes working with custom allocators somewhat painful, in exchange for safety, so if you don't need the safety, no point going through that pain.

What kinds of programs don't care about memory safety?

Compiler enforced memory safety*. Games in particular tend to have their own allocators and memory management schemes which don't play well with global allocators. Using memory pools, frame (arena) allocators, system specific memory management, and so on. Handling memory in a very systematic way (avoiding the "malloc everywhere" anti-pattern) where ownership is clearly tied to systems and handles (integers (maybe with metadata)) passed instead of pointers helps keep this all sane. That and you can still throw a GC/Ref counting at things which have non-linear lifetimes if needed but there's no need to do so globally.

One-shot programs also don't always need it as they're often fine with a less sophisticated scheme of arena allocation or reusing memory by resetting temporary buffers.

You also have the option to classify pointers if you absolutely must pass them with similar techniques as https://dinfuehr.github.io/blog/a-first-look-into-zgc.

Re: Zig is hard but worth it

#306

Post by kmz42 »

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

Earlier quoted context omitted.

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.

I was curious as well so I made a simple example to see how easy it is[0]

The documentation, especially for the build system, was lacking. But the interop itself is pretty smooth. Only rough point is that I can't define a struct type in Zig and use it in C; you HAVE to define your structs in C if you plan to pass them between the languages (as far as I know anyways).

Zig has documentation on making your Zig structs match the layout of C structs[1] so I assume the intended use case is not as I have done (use the C type in Zig) but instead of define a matching Zig type and cast your C structs into Zig structs, or vice versa, at the boundary between languages.

Structs aside, for functions you just stick "export" on the Zig functions to make them available at link time (presumably) and use "callconv(.C)" so C can call them cleanly. Very easy.

[0] https://github.com/kmz42/zig_c_interop_test

[1] https://ziglearn.org/chapter-4/#extern-structs

Re: Zig is hard but worth it

#307

Post by Tozen »

59nadir wrote: post #280
QQ00 wrote: post #273

Earlier quoted context omitted.

how your experience with Odin so far? How Odin differ from Zig in your opinion? What you likes/dislikes compared to Zig or other languages?

I think Odin is terrifically designed overall. There are design choices that I was initially very skeptical about but when I decided to use the language they actually made a lot of sense. Some overall differences between Odin and Zig and how I relate to them are: ## Exhaustive field setting Zig requires you to set every field in a struct. Everything everywhere has to be initialized to something, even if it's `undefin…

> Odin instead takes the position that everything is zero-initialized by default...

> Exhaustive field setting does remove uncertainty and I was very skeptical about just leaving things to zero-initialization, but overall I would say I prefer it. It really does work out most of the time...

Vlang does this as well (also influenced by Wirth/Pascal/Oberon/Go). Overall, this is an advantage and greater convenience for users.

Post reply on HN