Live data from Hacker News

Zig; what I think after months of using it

strongly-typed-thoughts.net

71–80 of 181 posts

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

#71
post #53

I loved this deep-dive of zig. > There’s a catch, though. Unlike Rust, ErrorType is global to your whole program, and is nominally typed. What does "global to your whole program" mean? I'd expect types to be available to the whole compilation unit. I'm also weirded out by the fact that zig has a distinct error type. Why? Why not represent errors as normal records?

What they're trying to convey is that errors are structurally typed. If you declare: const MyError = error{Foo} in one library and: const TheirError = error{Foo} in another library, these types are considered equal. Unlike structs/unions/enums which are nominal in zig, like most languages. The reason for this, and the reason that errors are not regular records, is to allow type inference to union and subtract error t…

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

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

#72
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…

Not being able to easily write a program without Unicode being pulled in for Rust code was a reason I'd chosen C over Rust before. When targeting binary sizes measured in kilobytes, pulling in full unicode handling is not an option. Especially since programs that don't have direct human interaction rarely actually need unicode.

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

#73
lol, I knew exactly who wrote this once I saw the complaint about shadowing being forbidden. The author and I were just arguing about it the other day on irc. While the author considers it an annoying language bug because it requires creating additional variable names (given refactoring was an unpalatable option). I consider it a feature.

Said arguments have become a recurring and frustrating refrain; when rust imposes some limit or restriction on how code is written, it's a good thing. But if Zig does, it's a problem?

The remainder of the points are quite hollow, far be it from me to complain when someone starts with a conclusion and works their way backwards into an argument... but here I'd have hoped for more content. The duck typing argument is based on minimal, or missing documentation, or the doc generator losing parts of the docs. And "comptime is probably not as interesting as it looks" the fact he calls it probably uninteresting highlights the lack of critical examination put here. comptime is an amazing feature, and enables a lot of impressive idioms that I enjoy writing.

> I’m also fed up of the skill issue culture. If Zig requires programmers to be flawless, well, I’m probably not a good fit for the role.

But hey, my joke was featured as the closing thought! Zig doesn't require one to be flawless. But it' also doesn't try to limit you, or box you into a narrow set of allowed operations. There is the risk that you write code that will crash. But having seen more code with unwrap() or expect() than without, I don't think that's the bar. The difference being I personally enjoy writing Zig code because zig tries to help you write code instead of preventing you from writing code. With that does come the need to learn and understand how the code works. Everything is a learnable skill; and I disagree with the author it's too hard to learn. I don't even think it's too hard for him, he's just appears unwilling.... and well he already made up his mind about which language is his favorite.

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

#74

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.

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

It’s harder to write correct unsafe Rust than correct Zig because (1) Rust uses references all over the place, but when writing unsafe code you must scrupulously avoid “producing” an invalid reference (even if you never deference it), and (2) there’s lots of syntax noise which obscures what the code is doing (though &raw is a step in the right direction).

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

#75
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…

> The standard library not being equipped to handle Unicode is the entire problem.

what? unicode is in the standard library.

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

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

#76
post #57

> Zig does enhance on C, there is no doubt. I would rather write Zig than C. The design is better, more modern, and the language is safer. But why stop half way? Why fix some problems and ignore the most damaging ones? I was disappointed when Rust went 1.0. It appeared to be on a good track to dethroning C++ in the domain I work in (video games)... but they locked it a while before figuring out the ergonomics to make…

> It appeared to be on a good track to dethroning C++ in the domain I work in (video games)... but they locked it a while before figuring out the ergonomics to make it workable for larger teams.

There are million-line Rust projects now. Rust is obviously workable for larger teams.

> Any language that imbues the entire set of special characters (!#*&[]{}(); ...etc) with mystical semantic context is, imo, more interested in making its arcane practitioners feel smart rather than getting good work done.

C uses every one of those symbols.

I think you're talking about @ and ~ boxes. As I recall, those were removed the same year the iPad and Instagram debuted.

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

#78
post #20

Earlier quoted context omitted.

The debate seems to have mostly ended in a victory for static types. The largest languages other than Python have them (if you include the transition from JS to TS). Python is slowly moving toward having them too.

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.

the place where imo static languages come up short is first class functions.

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

#79
post #55

> The first one that comes to mind is its arbitrary-sized integers. That sounds weird at first, but yes, you can have the regular u8, u16, u32 etc., but also u3. At first it might sound like dark magic, but it makes sense with a good example that is actually a defect in Rust to me. You don't need Rust to support that because it can be implemented externally. For example, crates like "bitbybit" and "arbitrary-int" pro…

I'm normally not sympathetic to the "you don't need that" argument, but there is a much stronger argument for not having arbitrarily-sized integers in Rust: the fact that values of such types can't have an address. The reason why our types all have bit sizes measured in octets is that a byte is the minimum granularity for a pointer.

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

#80

I loved this deep-dive of zig. > There’s a catch, though. Unlike Rust, ErrorType is global to your whole program, and is nominally typed. What does "global to your whole program" mean? I'd expect types to be available to the whole compilation unit. I'm also weirded out by the fact that zig has a distinct error type. Why? Why not represent errors as normal records?

> global to your whole program

Zig automatically does what most languages call LTO, so "whole program" and "compilation unit" are effectively the same thing (these error indices don't propagate across, e.g., dynamically linked libraries). If you have a bunch of ZIg code calling other Zig code and using error types, they'll all resolve to the same global error type (and calling different code would likely result in a different global error type).

> distinct error type, why?

The langage is very against various kinds of hidden "magic." If you take for granted that (1) error paths should have language support for being easily written correctly, and (2) userspace shouldn't be able to do too many shenanigans with control flow, then a design that makes errors special is a reasonable result.

It also adds some homogeneity to the code you read. I don't have to go read how _your_ `Result` type works just to use it correctly in an async context.

The obvious downside is that your use case might not map well to the language's blessed error type. In that case, you just make a normal record type to carry the information you want.

Post reply on HN