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

21–30 of 181 posts

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

#21

Post by llimllib »

ethin wrote: 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…

> In pretty much every "Unicode string" library/language type I've seen, each individual codepoint is a "character"

languages are actually really inconsistent on what they count as a unicode character: https://hsivonen.fi/string-length/

(I don't broadly disagree with you on unicode support, just linking an article relevant to that claim)

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

#22

Post by wtetzner »

ethin wrote: 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…

I don't necessarily disagree with not having a string type in a low level language, but you seem very fixated on needing a character type. Why not just have string be an opaque type, and have functions to iterate over code points, grapheme clusters, etc.?

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

#23

Post by nynx »

ethin wrote: 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 are conceptual interfaces. They don’t have anything to do with vtables.

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

#24

Post by zamalek »

lnenad wrote: post #7

When 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…

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).

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

#25

Post by mbb70 »

ethin wrote: 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…

There is no nebulous 'character' type. There are bytes, codepoints and glyphs. All languages with Unicode support allow iterating over each for a given string.

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

#26

Post by antonvs »

lnenad wrote: post #7

When 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…

It’s been a feature in languages for at least half a century. Scheme’s lexical scoping supported it in 1975, and Lisp adopted that.

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

#27

Post by chrisco255 »

ethin wrote: 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…

For me not having strings in Zig and being forced to use the fairly verbose '[]const u8' syntax every time I need a string was a little annoying at first, but it has had the effect of making me comfortable with the idea of buffers in a general sense, which is critical in systems programming. Most of the things that irked me about Zig when first learning it (I'm only a few weeks into it) have grown on me.

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

#28

Post by lmm »

chrisco255 wrote: post #13
lmm wrote: post #6

Earlier quoted context omitted.

> What does "global to your whole program" mean? I'd expect types to be available to the whole compilation unit. I think they mean you only have one global/shared ErrorType . You can't write the type of function that may yeet one particular, specific type of error but not any other types of error.

They're really just enum variants. You can easily capture the error and conditionally handle it: fn failFn() error{Oops}!i32 { try failingFunction(); return 12; } test "try" { const v = failFn() catch |err| { try expect(err == error.Oops); return; }; try expect(v == 12); // is never reached }

> You can easily capture the error and conditionally handle it

Sure. But the compiler won't help you check that your function only throws the errors that you think it does, or that your try block is handling all the errors that can be thrown inside it.

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

#29

Post by physicles »

lnenad wrote: post #7

When 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…

Over the years, I’ve wasted 1-2 days of my life debugging bugs caused by unintentional variable shadowing in Go (yes, I’ve kept track). Often, the bug is caused by an accidental use of := instead of =. I don’t understand why code that relies on shadowing isn’t harder to follow. Wish I could disable it entirely.

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

#30

Post by caspper69 »

ethin wrote: 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…

Having just gone down this road in C#, the way Unicode is now handled is via "runes".

Each rune may be comprised of various Unicode characters, which may themselves be 1-4 bytes (in the case of utf-8 encoding).

The one problem I have with this approach is that all of the categorization features operate a level below the runes, so you still have to break them up. The biggest drawback is that, at least in my (admittedly limited) research, there is no such thing as a "base" character in certain runes (such as family emojis- parents with kids). You can mostly dance around it with the vast majority of runes, because one character will clearly be the base character and one (or more) will clearly be overalys, but it's not universal.

Post reply on HN