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

Zig; what I think after months of using it

strongly-typed-thoughts.net

Post reply on HN
Print view View original

101–110 of 181 posts

Re: Zig; what I think after months of using it

#101

Post by anacrolix »

toprerules wrote: post #61
scubbo wrote: post #10

Great write-up, thank you! I used Zig for (most of) Advent Of Code last year, and while I did get up-to-speed on it faster than I did with Rust the previous year, I think that was just Second (low-level) Language syndrome. Having experienced it, I'm glad that I did (learning how cumbersome memory management is makes me glad that every other language I've used abstracts it away!), but if I had to pick a single low-lev…

As a systems programmer, Rust has won. It will take decades before there is substantial Rust replacing the absurd amounts of C that runs on any modern Unix system, but I do believe that our of all the replacements for C/C++, Rust has finally gained the traction most of them have lacked at the large companies that put resources behind these types of rewrites and exploratory projects. I do not think Zig will see wide a…

I agree. It's not ideal but Rust is a genuine improvement across the board on C and C++. It has the inertia and will slowly infiltrate and replace those 2. It also has the rare capacity to add some new areas without detracting from the mainstay: It's actually good as an embedded language for the web and as a DSL. C/C++ definitely didn't have that.

Re: Zig; what I think after months of using it

#102

Post by hitekker »

toprerules wrote: post #61
scubbo wrote: post #10

Great write-up, thank you! I used Zig for (most of) Advent Of Code last year, and while I did get up-to-speed on it faster than I did with Rust the previous year, I think that was just Second (low-level) Language syndrome. Having experienced it, I'm glad that I did (learning how cumbersome memory management is makes me glad that every other language I've used abstracts it away!), but if I had to pick a single low-lev…

As a systems programmer, Rust has won. It will take decades before there is substantial Rust replacing the absurd amounts of C that runs on any modern Unix system, but I do believe that our of all the replacements for C/C++, Rust has finally gained the traction most of them have lacked at the large companies that put resources behind these types of rewrites and exploratory projects. I do not think Zig will see wide a…

A big company I worked at actually deprecated the last of its Rust code last year. Maintaining Rust was much more expensive than predicted, and hiring and/or mentoring Rust Engineers proved even more expensive.

A simpler performant language like Zig, or a boring language + a different architecture would have been the better choice.

Re: Zig; what I think after months of using it

#103

Post by Narew »

pkulak wrote: post #89
chrisco255 wrote: post #81

Earlier quoted context omitted.

Rust has very real limitations and trade-offs. It compiles slow and the binaries are large. The compiler also makes performance sacrifices that makes it generally slower than C. I'm sure the language will continue to be successful, but it hasn't "won".

Why do you say slower than C? I’ve never seen a reason to believe they’re anything but roughly equivalent.

From my experience on C++ vs Rust on test algorithm. For a naive algorithm implementation rust is usually slightly faster than C++. But when you try to optimise stuff, it's the opposite. It's really hard to optimise Rust code, you need to put lots of unsafe and unsafe is not user-friendly. Rust also force you on some design that are not always good for performance.

Re: Zig; what I think after months of using it

#104

Post by asa400 »

Defletter wrote: post #99
pkulak wrote: post #89

Earlier quoted context omitted.

Why do you say slower than C? I’ve never seen a reason to believe they’re anything but roughly equivalent.

The last I heard, Rust had issues with freeing memory when it wouldn't need to, particularly with short-lived processes (like terminal programs) where the the Rust program would be freeing everything while the C version would just exit out and let the operating system do cleanup.

Rust has ManuallyDrop, which is exactly the functionality you’re describing. It works just fine for those types of programs. The speed of the two is going to be largely dependent on the amount of effort that has gone into optimizing either one, not on some theoretical performance bound. They’re both basically the same there. There are tons of examples of this in the wild at this point.

Re: Zig; what I think after months of using it

#105

Post by chrisco255 »

zamalek wrote: post #66
chrisco255 wrote: post #48

Earlier quoted context omitted.

Unsafe Rust is problematic: https://zackoverflow.dev/writing/unsafe-rust-vs-zig See also: https://github.com/roc-lang/roc/blob/main/www/content/faq.md... Zig is not entirely unsafe. It provides quite a few compile time checks and primitives to catch memory leaks or prevent them altogether.

This is precisely the myth that the article talks about. Miri finds significantly more UB in unsafe Rust than Zig's checks do. Even if it weren't, this exaggeration is a complete theater. You aren't supposed to use unsafe Rust unless you really have to. I have been using Rust since 2020 and I've used it once, for 3 lines of code. The entirety of all Zig codebases is unsafe. That's fine if you are fine with unsafe cod…

> Miri finds significantly more UB in unsafe Rust than Zig's checks do.

That's not a substantiated claim. Miri also runs very slowly.

> You aren't supposed to use unsafe Rust unless you really have to. I have been using Rust since 2020 and I've used it once, for 3 lines of code.

Cool, glad you haven't needed it. If you're ever writing interpreters or interfacing with external code, you'll need it.

> The entirety of all Zig codebases is unsafe

Zig is not 100% memory safe but it has compile-time safety features for vast majority of problems developers get themselves into with C/C++. Meanwhile, Rust's safety overhead has real trade-offs in terms of developer productivity, computational performance, compiler performance and binary size.

Re: Zig; what I think after months of using it

#106

Post by Gibbon1 »

pcwalton wrote: post #91
chrisco255 wrote: post #88

Earlier quoted context omitted.

A byte isn't the minimum granularity for a pointer. The minimum is based on whatever target you're compiling for. If it's a 32-bit target platform, then the minimum granularity is 4 bytes. Why should pointer size determine value size though? It's super fast to shift bits around, too, when needed.

> If it's a 32-bit target platform, then the minimum granularity is 4 bytes. Huh? How do you think `const char *s = "Hello"; const char *t = &s[1];` works? > Why should pointer size determine value size though? Because you should be able to take the address of any value, and addresses have byte granularity.

With a 64 bit pointer you could make it bit addressable.

Re: Zig; what I think after months of using it

#107

Post by throwawaymaths »

jamii wrote: post #94
throwawaymaths wrote: post #71

Earlier quoted context omitted.

if you need values associated with your error you can stash them in an in-out parameter

If I have multiple errors then that in-out parameter has to be a union(enum). And then I'm back to creating dozens of slightly different unions for functions which return slightly different sets of errors. Which is the same problem I have in rust. All of the nice inference that zig does doesn't apply to my in-out parameter either. And the compiler won't check that every path that returns error.Foo always initializes…

i dont think you can make a union that has an error enum tag. I dont see why the in-out has to be dependent on the error.

Re: Zig; what I think after months of using it

#108

Post by lnenad »

pkulak wrote: post #92
mk12 wrote: post #86

Earlier quoted context omitted.

It’s a trade-off. If you allow shadowing, then you rule out the possibility of the value being used later. This prevents accidental use (later on, in a location you didn't intend to use it) and helps readability by reducing the number of variables you must keep track of at once. If you ban shadowing, then you rule out the possibility of the same name referring to different things in the same scope. This prevents acci…

And on the whole, I prefer shadowing. I’ve never had a bug in either direction, but keeping everything immutable without shadowing means you spend all your brain power Naming Things.

I mean that's a really fake problem. How many times per line of code do you actually need to name variables and how many of those times you're shadowing a previously defined var. I'm guessing a very small amount.

Re: Zig; what I think after months of using it

#109

Post by brabel »

pcwalton wrote: post #87
chrisco255 wrote: post #48

Earlier quoted context omitted.

Unsafe Rust is problematic: https://zackoverflow.dev/writing/unsafe-rust-vs-zig See also: https://github.com/roc-lang/roc/blob/main/www/content/faq.md... Zig is not entirely unsafe. It provides quite a few compile time checks and primitives to catch memory leaks or prevent them altogether.

> It provides quite a few compile time checks and primitives to catch memory leaks or prevent them altogether. From what I've seen, clang has all of these and more for C++. If your metric is "tooling to help you catch UB", C++ is significantly superior to Zig.

WTH they were talking about Rust and Zig, they did not even mention C++ and you come with "if your metrics is blah then C++ is superior, checkmate!", completely ignoring C++ is a monster of complexity while Zig is basically simple as C.

Re: Zig; what I think after months of using it

#110

Post by Defletter »

tapirl wrote: post #96
toprerules wrote: post #61

Earlier quoted context omitted.

As a systems programmer, Rust has won. It will take decades before there is substantial Rust replacing the absurd amounts of C that runs on any modern Unix system, but I do believe that our of all the replacements for C/C++, Rust has finally gained the traction most of them have lacked at the large companies that put resources behind these types of rewrites and exploratory projects. I do not think Zig will see wide a…

Zig might not become very popular, but IMO, it will become more popular than Rust. Zig is good at all the areas Rust is good at. Zig is also good at game development which Rust is not good at. And Zig is better when integrating with C/C++ libraries.

> but IMO, it will become more popular than Rust

While I wish this were true, I very much doubt it, at least not until Zig has proper interfaces and gives up its weird hangup on anonymous functions. It's also extremely easy to effectively lose access to Zig features without cluttering your code. For example, say you want to use libevent in Zig: your event callbacks must use C calling conventions, meaning you lose access to try and errdefer, which are two of the most defining features of Zig. And while you can remedy this by having the callback invoke a Zig function, doing that just doubles every interaction between your Zig code and libevent, which is already cluttered because of the lack of anonymous functions.

These things aren't as important as compile times, but they are annoyances that will drive a non-zero amount of people away.

Post reply on HN