Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Zig: Build System Reworked

ziglang.org

Post reply on HN
Print view View original

51–60 of 263 posts

Re: Zig: Build System Reworked

#51

Post by bluecalm »

p-e-w wrote: post #29
ACCount37 wrote: post #20

Earlier quoted context omitted.

Rarely. Most tinkering tasks just don't have enough heavy duty computation in them to as much as strain a modern CPU. And most of the rest are covered by packages like numpy or pytorch. For the rare exceptions, I make a C lib and call into it to get my numbers crunched. I get that Zig is a viable replacement for C there. But I don't see it replacing Python.

Not to mention that where heavy computation is required, Python often has libraries that are much, much faster than anything you can quickly hack together in C or Zig.

Only if you doing something thousands of people has done before. Anything new, even very simple and you are on your own and Python is 100x slower than naive C implementation on many tasks.

Last little project I remember is writing a solver for a puzzle game my friend published. Python just doesn't work at all for such tasks.

I think you are wrong about speed of those libraries as well. In my experience naive code designed for a specific task beats highly sophisticated general code and it doesn't take a rocket scientist to get huge speed-ups over some well established fast library.

Re: Zig: Build System Reworked

#52

Post by uecker »

jcul wrote: post #44
andyferris wrote: post #26

Earlier quoted context omitted.

Low-level programming gets a bad name because C has many footguns and the spec leaves much behavior undefined - a fact that implementers use almost adversarially (which I'd support, if the goal was to refine the spec...). C++ adds more high-level conveniences without actually removing the footguns and undefined behavior (much C code compiles in a C++ compiler). Zig tries to keep the low-level C philosophy but have th…

It made me laugh to think of C implementers being adversarial! It can feel that way. I haven't really used modern C, not sure if it's evolved as much as modern C++, which I feel is a joy to use, and a lot safer. But then I've been writing C++ for decades. I feel like C evolved from basically syntax sugar for assembly, so that's where all the footguns come from, rather than being actually adversarial.

Both C and C++ compilers (in fact, they share this part) very aggressively exploited undefined behavior for performance. But I this was certainly not adversarial. Programmers also regularity picked optimizations over safety. I think nowadays the unsafety of C with modern tooling vs the safety of - say - Rust is very much exaggerated.

Re: Zig: Build System Reworked

#53

Post by pylotlight »

androiddrew wrote: post #41
xtreak29 wrote: post #36

Bun is moving towards rust but does this also help bun's compilation times? https://ziggit.dev/t/bun-s-zig-fork-got-4x-faster-compilatio...

I think bun is moving to rust because Anthropic owns it and the devs there like rust. So why would they invest in another implementation? Sad to see a good zig example go, but as soon as Anthropic bought it I wrote the project off.

Just plain incorrect.. please stop spouting this nonsense, this is not the reason whatsoever.

Re: Zig: Build System Reworked

#54

Post by robinsonb5 »

jcul wrote: post #44
andyferris wrote: post #26

Earlier quoted context omitted.

Low-level programming gets a bad name because C has many footguns and the spec leaves much behavior undefined - a fact that implementers use almost adversarially (which I'd support, if the goal was to refine the spec...). C++ adds more high-level conveniences without actually removing the footguns and undefined behavior (much C code compiles in a C++ compiler). Zig tries to keep the low-level C philosophy but have th…

It made me laugh to think of C implementers being adversarial! It can feel that way. I haven't really used modern C, not sure if it's evolved as much as modern C++, which I feel is a joy to use, and a lot safer. But then I've been writing C++ for decades. I feel like C evolved from basically syntax sugar for assembly, so that's where all the footguns come from, rather than being actually adversarial.

If some of the things that the C standard left undefined had instead been made implementation defined then the compiler would at least be obligated to do something that makes sense on the target architecture, rather than having license to take the lawful-evil route. (Plenty of architectures have addressable RAM at location zero, for instance.)

For some reason this always brings to mind that moment in Red Dwarf where Kryten, devoid of his behavioural chip, deems it appropriate to serve roast human to his crewmates. "If you eat chicken, obviously you'd eat your own species as well, otherwise you'd just be picking on the chickens!"

Re: Zig: Build System Reworked

#55

Post by bluecalm »

nromiun wrote: post #49

Is there any proposed timeline for a stable release? Big features like the recent async IO shows the language is very unstable right now.

Andrew's take is "it's ready when it's ready but we hope it's good enough before it's fully ready that you want to use it anyway".

It's different and I like it. You get one shot at it and may just as well get it right in as many areas as possible.

Re: Zig: Build System Reworked

#56

Post by kristoff_it »

xtreak29 wrote: post #36

Bun is moving towards rust but does this also help bun's compilation times? https://ziggit.dev/t/bun-s-zig-fork-got-4x-faster-compilatio...

Bun has de-facto refused to use incremental compilation in Zig for ages. It got to the point where Jarred somehow seems to have forgotten that the feature exists.

In any case Bun has already committed to the Rust slop switch, so it doesn't matter anymore.

Re: Zig: Build System Reworked

#57

Post by amazingamazing »

pylotlight wrote: post #53
androiddrew wrote: post #41

Earlier quoted context omitted.

I think bun is moving to rust because Anthropic owns it and the devs there like rust. So why would they invest in another implementation? Sad to see a good zig example go, but as soon as Anthropic bought it I wrote the project off.

Just plain incorrect.. please stop spouting this nonsense, this is not the reason whatsoever.

What is the reason?

Re: Zig: Build System Reworked

#58

Post by xydone »

nromiun wrote: post #49

Is there any proposed timeline for a stable release? Big features like the recent async IO shows the language is very unstable right now.

There is no ETA on 1.0, but breakage has followed the pattern of it not really being hard to upgrade to a newer version, as it is very well documented on the version release notes.

Re: Zig: Build System Reworked

#59

Post by flossly »

ACCount37 wrote: post #13
portly wrote: post #8

After having used Zig for a couple of months now I am convinced it is a fantastic tool language. You just pick it up to hack some idea together freely. Every time I hit a wall, I find the creators have thought of it already and offers comfort. But nothing gets in your face how to use the programming language "correctly". For me it is now the go-to "tinker in my garage" language.

Is it really that good? My go-to "tinker in my garage" language is Python - lightweight syntax that stays out of your face, batteries included, packages for everything that's not included. What's Zig's edge?

You both like different types of tinkering.

Some people put a generator on a tesla cybertruck and call that garage tinkering.

Some people make a go-cart out of a lawnmower and call that garage tinkering.

The first is the "batteries included Python" tinkering, the second is the "low level Zig" tinkering.

Re: Zig: Build System Reworked

#60

Post by archargelod »

dmit wrote: post #18
ACCount37 wrote: post #13

Earlier quoted context omitted.

Is it really that good? My go-to "tinker in my garage" language is Python - lightweight syntax that stays out of your face, batteries included, packages for everything that's not included. What's Zig's edge?

Have you ever thought "Ugh, this bit of Python code is running much slower than I expected on my computer. Wonder if anyone has written a native library for this"? That's probably the closest use case for someone who matches your description -- a language that is much more ergonomic, much more 'modern' feeling (in all the good ways), while still extremely compatible with C. As for the language itself, it's going to b…

That's actually a great argument for Nim[0]. Easy interop with C, native-speed performance, and a syntax very close to Python in both readability and how quickly you can get something working.

Batteries included, automatic memory management without a conventional GC and metaprogramming - is a really cool combination.

[0] - https://nim-lang.org/

Post reply on HN