Headers are missing IDs for URL fragments to jump to e.g. https://strongly-typed-thoughts.net/blog/zig-2025#error-hand... doesn't work
Zig; what I think after months of using it
51–60 of 181 posts
Re: Zig; what I think after months of using it
#52The debate between static and dynamic typing continues unceasingly. Even when the runtime values are statically typed, it's merely reprised at the type level.
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.
If I'm told to still use === in typescript, it's not actually a statically typed language.
Re: Zig; what I think after months of using it
#53I 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}
const TheirError = error{Foo}
The reason for this, and the reason that errors are not regular records, is to allow type inference to union and subtract error types like in https://news.ycombinator.com/item?id=42943942. (They behave like ocamls polymorphic variants - https://ocaml.org/manual/5.3/polyvariant.html) This largely avoids the problems described in https://sled.rs/errors.html#why-does-this-matter.
On the other hand zig errors can't have any associated value (https://github.com/ziglang/zig/issues/2647). I often find this requires me to store those values in some other big sum type somewhere which leads to all the same problems/boilerplate that the special error type should have saved me from.
Re: Zig; what I think after months of using it
#54Earlier 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.
The whole anytype/trait question is just dynamic typing, but at the type level instead of the value level.
[deleted]
Re: Zig; what I think after months of using it
#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" provide that functionality, and more:
Re: Zig; what I think after months of using it
#56Earlier 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 was generally responding to the whole thread and pointing to how Zig sees errors. Enums are a type of value, yes, but they're typically dealt with differently than other data types.
Re: Zig; what I think after months of using it
#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 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.
> I don’t think that simplicity is a good vector of reliable software.
No, but simplicity is often a property of readable, team-scalable, popular, and productive programming languages. C, Python, Go, JavaScript...
Solving for reliability is ultimately up to your top engineers. Rust certainly keeps the barbarians from making a mess in your ivory tower. Because you're paralyzing anyone less technical by choosing it.
> I think my adventure with Zig stops here.
This article is a great critique. I share some concerns about the BDFL's attitudes about input. I remain optimistic that Zig is a long way from 1.0 and am hoping that when Andrew accomplishes his shorter-term goals, maybe he'll have more brain space for addressing some feedback constructively.
Re: Zig; what I think after months of using it
#58No 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
Zig: I want to be a safer C
C: I don't have string type
Zig: No… not like that!
Re: Zig; what I think after months of using it
#59When did shadowing become a feature? I was under the impression it's an anti-pattern. As per the example in the article > const foo = Foo.init(); > const foo2 = try foo.addFeatureA(); > const foo3 = try foo.addFeatureB(); It's a non issue to name vars in a descriptive way referring to the features initial_foo for example and then foo_feature_a. Or name them based on what they don't have and then name it foo. In the e…
Don't see how it could introduce bugs. The point of replacing a variable is precisely to make a value that is no longer needed inaccessible. If anything introducing new variables with new names has the potential to introduce subtle bugs since someone could mistakenly use one of the variables that is no longer valid or no longer needed.
When you are modifying a long closure and don’t notice that you are shadowing a variable that is used later.
I know “use shorter functions” but tell that to my coworkers.
Re: Zig; what I think after months of using it
#60Earlier 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.
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.