Live data from Hacker News

Zig; what I think after months of using it

strongly-typed-thoughts.net

61–70 of 181 posts

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

#61
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 adoption, but obviously if you enjoy writing it and can make a popular project, more power to you.

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

#62

Earlier quoted context omitted.

I honestly don't see how anyone who has used a language with both unions and interfaces could come up with anything else that makes dynamic types better. Either way you need to fulfill the contract, but I'd much prefer to find out I failed to do that at compile time.

Don't confuse "presence of dynamic types" with "absence of static types." Think about the web, which is full of dynamicism: install this polyfill if needed, call this function if it exists, all sorts of progressive enhancement. Dynamic types are what make those possible.

Sure, I'm primarily a C# programmer which does have a dynamic type object, and occasionally use VB which uses late binding and can use dynamic typing as well.

You want to know how often I find dynamic typing the correct tool for the job? It's literally never.

Dynamic typing does allow you to do things faster as long as you can keep the whole type system in your head, which is why JavaScript was designed the way it was. That doesn't mean it is necessary to do any of those things, or is even the best way to do it.

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

#63
post #17

It seems like he wants zig to be more like rust. personally, i like that zig is so simple

This is absolutely not what the article is about. A good majority of it is spent on the myth that Zig is safer than Rust, which has nothing to do with wishing Zig was more like Rust.

i haven’t seen anyone pronounce it anywhere once.

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

#64

Earlier quoted context omitted.

If you must write unsafe code, what's wrong with just dropping down to unsafe in Rust when you need to? You have all the power unsafe provides, and you have a smaller surface area to audit than if your entire codebase resides in one big unsafe block.

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.

Yes, unsafe code is problematic in Rust, C, C++, etc. Is Zig different?

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

#65

Earlier quoted context omitted.

Is there a myth that makes that claim? Virtually every take I've heard is that Zig is "safe enough" while giving developers more control over memory and actually, it's specifically better for cases where you must write unsafe code, as it's not possible to express all programs in safe Rust.

If you must write unsafe code, what's wrong with just dropping down to unsafe in Rust when you need to? You have all the power unsafe provides, and you have a smaller surface area to audit than if your entire codebase resides in one big unsafe block.

the barrier between unsafe and safe has additional rules. it’s not “just dropping to unsafe” – you need to make sure you leave it safely.

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

#66

Earlier quoted context omitted.

If you must write unsafe code, what's wrong with just dropping down to unsafe in Rust when you need to? You have all the power unsafe provides, and you have a smaller surface area to audit than if your entire codebase resides in one big unsafe block.

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 code, but this myth is dishonest, and I take great issue with using a language where the founder is the primary source of the dishonesty - because what else is being swept under the rug?

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

#67

Earlier quoted context omitted.

They're enums. See: https://zig.guide/language-basics/errors

There it says "errors are values" so now that contradicts what OP said.

I said I wasn't speaking for Zig specifically, just on general principle that errors are not really values. Many languages reify errors as values to avoid having different semantics for errors, but errors probably should have their own semantics. Zig seems to take a middle ground here, where errors are a special type of value but that still sort of has its own semantics.

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

#68
post #24

Earlier quoted context omitted.

The example given isn't that great. Here's a significantly more common one: var age = get_string_from_somewhere(); var age = parse_to_int(age); Without same-scope shadowing you end up with the obnoxious: var age_string = get_string_from_somewhere(); var age = parse_to_int(age_string); Note that your current language probably does allow shadowing: in nested scopes (closures).

Changing the type on a value is an anti-pattern, in my opinion. It's not obnoxious to be explicit in your variable names.

That implies that Hungarian notation is not obnoxious? Sure, that's a fine opinion to have, but I guarantee it is an exceedingly rare one.

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

#69
post #12

No idea how much the author is experienced at Zig, but my thoughts: > No typeclasses / traits This is purposeful. Zig is not trying to be some OOP/Haskell replacement. C doesn't have traits/typeclasses either. Zig prefers explicitness over implicit hacks, and typeclasses/traits are, internally, virtual classes with a vtable pointer. Zig just exposes this to you. > No encapsulation This appears to be more a documentat…

> typeclasses/traits are, internally, virtual classes with a vtable pointer No, they're not. Rust "boxed traits" are, but those aren't what the author means. > Primarily because if Zig did have a full Unicode string and some "character" type, now it'd be on the standard library devs to not only define what a "character" is, and then we risk having something like the C++ Unicode situation where you have a char32_t typ…

https://github.com/ziglang/zig/blob/master/lib/std/unicode.z... wdym?

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

#70
post #66

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…

yes but by the time you're using miri, why not just run zig with a separate static checker that does all the memory safety parts?

https://github.com/ityonemo/clr

Post reply on HN