5 ms·

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 rep

by ethin 2y ago

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 documentation issue than anything else. Zig does have significant issues in that area, but this is to be expected in a language that hasn't even hit 1.0. > No destructors Uh... What? Zig does have destructors, in a way. It's called defer and errordefer. Again, it just makes you do it explicitly and doesn't hide it from you. > No (unicode) strings People seem to want features like this a lot -- some kind of string type. The problem is that there is no actual "string" type in a computer. It's just bytes. Furthermore, if you have a "Unicode string" type or just a "string" type, how do you define a character? Is it a single codepoint? Is it the number of codepoints that make up a character as per the Unicode standard (and if so, how would you even figure that out)? For example, take a multi-codepoint emoji. In pretty much every "Unicode string" library/language type I've seen, each individual codepoint is a "character". Which means that if you come across a multi-codepoint emoji, those "characters" will just be the individual codepoints that comprise the emoji, not the emoji as a whole. Zig avoids this problem by just... Not having a string type, because we don't live in the age of ASCII anymore, we live in a Unicode world. And Unicode is unsurprisingly extremely complicated. The author tries to argue that just iterating over byes leads to data corruption and such, but I would argue that having a Unicode string type, separate from all other types, designed to iterate over some nebulous "character" type, would just introduce all kinds of other problems that, I think, many would agree should NOT be the responsibility of the language. I've heard this criticism from many others who are new to zig, and although I understand the reasoning behind it, the reasoning behind just avoiding the problem entirely is also very sensible in my mind. 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 type, but the standard library isn't equipped to handle that type, and then you run into "Oh this encoding is broken" and on and on and on it goes.

llimllib 2y ago
> 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/ https://hsivonen.fi/string-length/ (I don't broadly disagree with you on unicode support, just linking an article relevant to that claim)
wtetzner 2y ago
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.?
nynx 2y ago
Typeclasses are conceptual interfaces. They don’t have anything to do with vtables.
mbb70 2y ago
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.
chrisco255 2y ago
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.
- deleted 2y ago
  [deleted]
caspper69 2y ago
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.

by ethin 2y ago

llimllib 2y ago

> 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/ https://hsivonen.fi/string-length/ (I don't broadly disagree with you on unicode support, just linking an article relevant to that claim)

wtetzner 2y ago

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

nynx 2y ago

Typeclasses are conceptual interfaces. They don’t have anything to do with vtables.

mbb70 2y ago

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.

chrisco255 2y ago

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.

deleted 2y ago
[deleted]

caspper69 2y ago

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.