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

Why is Zig so cool?

nilostolte.github.io

Post reply on HN
Print view View original

71–80 of 527 posts

Re: Why is Zig so cool?

#71

Post by qouteall »

qouteall wrote: post #70

In my opinion the biggest issue of Zig is that it doesn't allow attaching data to error. The error can only be passed via side channel, which is inconvenient and ENOURAGES TOOL DEVELOPERS TO NOT PASS ERROR DATA, which greatly increase debugging difficulty. Somethings there are 100 things that possibly go wrong. With error data you can easily know which exact thing is wrong. But with error code you just know "somethin…

I know that Zig doesn't allow attaching data to error for valid reasons. If error data contains interior pointer then it can easily cause memory safety problem. Zig doesn't have a borrow cheker or ownership system to prevent that.

https://github.com/ziglang/zig/issues/2647#issuecomment-2670...

Re: Why is Zig so cool?

#72

Post by chrisco255 »

fleventynine wrote: post #44
chrisco255 wrote: post #26

Earlier quoted context omitted.

I feel like the article didn't really hit on the big ones: comptime functions, no hidden control flow, elegant defaults, safe buffers, etc. What Zig really does is make systems programming more accessible. Rust is great, but its guarantees of memory safety come with a learning curve that demands mastering lifetimes and generics and macros and a complex trait system. Zig is in that class of programming languages like…

> This means there's no target too small for the language, including embedded systems. It also means it's a good choice if you want to create a system that maximizes performance by, for example, preventing heap allocations altogether. I don't think there's is any significant different here between zig, C and Rust for bare-metal code size. I can get the compiler to generate the same tiny machine code in any of these l…

That's not been my experience with Rust. On average produces binaries at least 4x bigger than the Zig I've compiled (and yes, I've set all the build optimization flags for binary size). I know it's probably theoretically possible to achieve similar results with Rust, it's just you have to be much more careful about things like monomorphization of generics, inlining, macro expansion, implicit memory allocation, etc that happen under the hood. Even Rust's standard library is quite hefty.

C, yes, you can compile C quite small very easily. Zig is like a simpler C, in my mind.

Re: Why is Zig so cool?

#73

Post by jayd16 »

Is the inline testing good in practice? I do like the clear proximity and scope of the code being tested but I can also imagine trying to cram in all the unit tests and mocking and logging and such.

Does the feature end up feeling unused, dominating app code with test code, or do people end up finding a happy medium?

Re: Why is Zig so cool?

#74

Post by metaltyphoon »

qouteall wrote: post #71
qouteall wrote: post #70

In my opinion the biggest issue of Zig is that it doesn't allow attaching data to error. The error can only be passed via side channel, which is inconvenient and ENOURAGES TOOL DEVELOPERS TO NOT PASS ERROR DATA, which greatly increase debugging difficulty. Somethings there are 100 things that possibly go wrong. With error data you can easily know which exact thing is wrong. But with error code you just know "somethin…

I know that Zig doesn't allow attaching data to error for valid reasons. If error data contains interior pointer then it can easily cause memory safety problem. Zig doesn't have a borrow cheker or ownership system to prevent that. https://github.com/ziglang/zig/issues/2647#issuecomment-2670...

> I know that Zig doesn't allow attaching data to error for good reasons. If error data contains interior pointer then it causes memory safety problem

IMO this is not a good reason at all.

Re: Why is Zig so cool?

#75

Post by archargelod »

hamandcheese wrote: post #3

Zig being able to (cross)compile C and C++ feels very similar to how UV functions as a drop in replacement for pip/pip-tools. Seems like a fantastic way to gain traction in already established projects.

I love Zig. Never tried to write it though =).

I just use a it as cross-compiler for my Nim[0] programs.

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

Re: Why is Zig so cool?

#76

Post by newpavlov »

mlavergn wrote: post #58
didip wrote: post #20

Is it cool? It seems to be in nether land between Rust and Go. Not sure what is the unique use case for Zig.

Well, it's insanely simple, insanely fast, often more performant than Rust with lower resource usage, with first class C-interop and cross-compiling out of the box. It's easily my favorite language now, with Go being a close second. Both are opinionated and have a standard formatter that makes Zig code instantly readable when you see it, similar to Go. Rust was once interesting, but it's firmly in macro hell territor…

>often more performant than Rust with lower resource usage

[citation needed]

If we are to trust this page [0] Rust beats Zig on most benchmarks. In the Techempower benchmarks [1] Rust submissions dominate the TOP, while Zig is... quite far.

Several posts which I've seen in the past about Zig beating Rust by 3x or such all turned to be based on low quality Rust code with some performance pitfalls like measuring performance of writing into stdout (which Rust locks by default and Zig does not) or iterating over ..= ranges which are known to be problematic from the performance perspective.

[0]: https://programming-language-benchmarks.vercel.app/rust-vs-z...

[1]: https://www.techempower.com/benchmarks/

Re: Why is Zig so cool?

#77

Post by qouteall »

metaltyphoon wrote: post #74
qouteall wrote: post #71

Earlier quoted context omitted.

I know that Zig doesn't allow attaching data to error for valid reasons. If error data contains interior pointer then it can easily cause memory safety problem. Zig doesn't have a borrow cheker or ownership system to prevent that. https://github.com/ziglang/zig/issues/2647#issuecomment-2670...

> I know that Zig doesn't allow attaching data to error for good reasons. If error data contains interior pointer then it causes memory safety problem IMO this is not a good reason at all.

Changed to "valid reasons"

Re: Why is Zig so cool?

#78

Post by newpavlov »

pron wrote: post #6

> I can’t think of any other language in my 45 years long career that surprised more than Zig. I can say the same (although my career spans only 30 years), or, more accurately, that it's one of the few languages that surprised me most. Coming to it from a language design perspective, what surprised me is just how far partial evaluation can be taken. While strictly weaker than AST macros in expressive power (macros ar…

Great comment! I agree about comptime, as a Rust programmer I consider it one of the areas where Zig is clearly better than Rust with its two macro systems and the declarative generics language. It's probably the biggest "killer feature" of the language.

Re: Why is Zig so cool?

#79

Post by zevets »

brucehoult wrote: post #43
rvrb wrote: post #24

Earlier quoted context omitted.

out of curiosity, what feature do you want?

The feature I want is multimethods -- function overloading based on the runtime (not compile time) type of all the arguments. Programming with it is magical, and its a huge drag to go back to languages without it. Just so much better than common OOP that depends only on the type of one special argument (self, this etc). Common Lisp has had it forever, and Dylan transferred that to a language with more conventional sy…

I think this is a major mistake for Zig's target adoption market - low level programmers trying to use a better C.

Julia is phenomenally great for solo/small projects, but as soon as you have complex dependencies that _you_ can't update - all the overloading makes it an absolute nightmare to debug.

Re: Why is Zig so cool?

#80

Post by fleventynine »

chrisco255 wrote: post #72
fleventynine wrote: post #44

Earlier quoted context omitted.

> This means there's no target too small for the language, including embedded systems. It also means it's a good choice if you want to create a system that maximizes performance by, for example, preventing heap allocations altogether. I don't think there's is any significant different here between zig, C and Rust for bare-metal code size. I can get the compiler to generate the same tiny machine code in any of these l…

That's not been my experience with Rust. On average produces binaries at least 4x bigger than the Zig I've compiled (and yes, I've set all the build optimization flags for binary size). I know it's probably theoretically possible to achieve similar results with Rust, it's just you have to be much more careful about things like monomorphization of generics, inlining, macro expansion, implicit memory allocation, etc th…

The Rust standard library in its default config should not be used if you care about code size (std is compiled with panic/fmt and backtrace machinery on by default). no_std has no visible deps besides memcpy/memset, and is comparable to bare metal C.
Post reply on HN