Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Zig 0.9.0

ziglang.org

Post reply on HN
Print view View original

151–160 of 250 posts

Re: Zig 0.9.0

#151

Post by anonymoushn »

coldtea wrote: post #146
vladharbuz wrote: post #3

I don't know if string handling has been improved, but it's one of the few things stopping me from using Zig. I look forward to 1.0, which will hopefully have proper strings. [0] [0]: https://github.com/ziglang/zig/issues/234

It seems they don't want unicode strings as part of the language, at best as a library. But unless there's a single sactioned one, this will not end well. And this is met with answers like "just avoid string handling" from the language designers... It's probably because they don't work in any related domain, and even less so have to do with international strings (except as byte buckets they don't care about and don't…

It seems way nicer to have a language that treats strings as byte arrays and use libraries to handle encodings than to have a language that treats strings as UCS-2 and use libraries to handle UTF-8 strings that live inside of UCS-2 strings.

Re: Zig 0.9.0

#152

Post by _vvhw »

coldtea wrote: post #146
vladharbuz wrote: post #3

I don't know if string handling has been improved, but it's one of the few things stopping me from using Zig. I look forward to 1.0, which will hopefully have proper strings. [0] [0]: https://github.com/ziglang/zig/issues/234

It seems they don't want unicode strings as part of the language, at best as a library. But unless there's a single sactioned one, this will not end well. And this is met with answers like "just avoid string handling" from the language designers... It's probably because they don't work in any related domain, and even less so have to do with international strings (except as byte buckets they don't care about and don't…

No, I believe it's the right decision and I respect it. Encoding charsets are continuously evolving and shouldn't be baked into a language specification.

Re: Zig 0.9.0

#153

Post by coldtea »

lmm wrote: post #100
AndyKelley wrote: post #51

Earlier quoted context omitted.

Protocols and formats absolutely should not require decoding strings. I think you are mistaken. Can you name any well-established protocol or format that does not treat strings as opaque encoded bytes? Edit: so far these examples have been given: * HTTP: wrong. the spec does not tell you to decode any strings * CSV: wrong. the spec does not tell you to decode any strings, nor is it necessary to have any unicode aware…

The HTTP specification does tell you to behave differently depending on the presence or absence of specific values for case-insensitive headers. That requires decoding the header name strings.

>That requires decoding the header name strings.

Which should be ascii though no?

Re: Zig 0.9.0

#154

Post by anonymoushn »

dnautics wrote: post #87
ruined wrote: post #40

Earlier quoted context omitted.

thread tl;dr: it doesn't look like there will be language support for things like codepoints or grapheme indexing or treatment of strings as anything but byte arrays, so ddevault is sad. there is intention from andrewrk and jecolon to provide such features in the standard library before 1.0 release. downside to library vs lang support that is you can expect a good chunk of programmers to ignore the less-ergonomic lib…

Does this boil to the semantic question of if the stdlib is part of the language?

One difference is that there won't be a built-in string type with operator[] defined as something other than returning the byte at the indexed position in the array of bytes. There could be most other things one would expect from language-level string support though.

Re: Zig 0.9.0

#155

Post by roca »

_vvhw wrote: post #152
coldtea wrote: post #146

Earlier quoted context omitted.

It seems they don't want unicode strings as part of the language, at best as a library. But unless there's a single sactioned one, this will not end well. And this is met with answers like "just avoid string handling" from the language designers... It's probably because they don't work in any related domain, and even less so have to do with international strings (except as byte buckets they don't care about and don't…

No, I believe it's the right decision and I respect it. Encoding charsets are continuously evolving and shouldn't be baked into a language specification.

Evolving how? I'm not aware of any reason to move beyond UTF8 for encoding Unicode.

Re: Zig 0.9.0

#156

Post by _vvhw »

roca wrote: post #155
_vvhw wrote: post #152

Earlier quoted context omitted.

No, I believe it's the right decision and I respect it. Encoding charsets are continuously evolving and shouldn't be baked into a language specification.

Evolving how? I'm not aware of any reason to move beyond UTF8 for encoding Unicode.

Which version of UTF8?

Re: Zig 0.9.0

#157

Post by lmm »

coldtea wrote: post #153
lmm wrote: post #100

Earlier quoted context omitted.

The HTTP specification does tell you to behave differently depending on the presence or absence of specific values for case-insensitive headers. That requires decoding the header name strings.

> That requires decoding the header name strings. Which should be ascii though no?

Maybe, but it's not "treating strings as opaque encoded bytes" which is what was asked.

Re: Zig 0.9.0

#158

Post by coldtea »

svnpenn wrote: post #135
AndyKelley wrote: post #34

Earlier quoted context omitted.

A lot of people reach for string handling when the actual correct thing to do is intentionally avoid string handling, and only handle strings as opaque encoded UTF-8 bytes, that cannot be reasoned about in terms of human language. I would even argue that having string handling in a standard library (or language) has the potential to cause a net increase in bugs, because of people thinking they are handling strings wh…

> Go's string handling is completely broken, for example. Classic Andy, shitting on other language with no references or examples. Go has some of the best string handling I've used. Seamless byte, rune, string conversion. Simple iterating and slicing. Plus helpful tools like strings.Builder and strconv.AppendInt. while Zig has nothing.

It seems like every language must have some dumb decisions made because the authors don't care/think they know better/are stubborn/etc or because it painted itself into a hole from the start, without which it would be close to perfect for its use cases.

Python has the GIL.

Go itself has a few such cases (usually revolving around "NIH" and misguided simplicity).

Zig has the prejudice about proper string handling.

Re: Zig 0.9.0

#159

Post by coldtea »

von_lohengramm wrote: post #61
turminal wrote: post #22

Earlier quoted context omitted.

The issue with treating strings as slices/arrays is that it exposes (writably!) the underlying representation, which is almost never what you want and leads to subtle bugs. The downside is of course the fact that you have to account for encodings in your language now, but picking the one and only sensible encoding really shouldn't be a problem in 2021.

It's not that simple. Obviously, you'd choose UTF-8, but that exposes another issue: a codepoint is not a character. There's no simple & elegant solution to this at the language level.

So let's have everybody write their own incompatible libs and partial solutions... It worked for C /s

Re: Zig 0.9.0

#160

Post by coldtea »

von_lohengramm wrote: post #78
turminal wrote: post #70

Earlier quoted context omitted.

> a codepoint is not a character Precisely. That's why I think representing strings as character slices and letting third party libraries handle them is not a good solution. Deciding what features to put in the language vs. the stdlib vs. third party libraries is one of the hardest parts of language design. Personally I believe strings are important and frequent enough they deserve special treatment at the language l…

> representing strings as character slices Zig does not do this. It represents strings as byte slices. A UTF-8 character could be multiple codepoints with each codepoint being multiple bytes. A big thing about Zig is not hiding complexity. If UTF-8 were implemented at a language level (whatever that means), then "language level" string operations would be non-linear, which would be very non-Ziggy. I could see value i…

>Zig does not do this. It represents strings as byte slices.

That's what the parent meant. Char(aracter) is a byte in C.

Post reply on HN