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

231–240 of 250 posts

Re: Zig 0.9.0

#231

Post by chrismorgan »

Akira1364 wrote: post #216
rini17 wrote: post #187

Earlier quoted context omitted.

Well let's try :grinningface:,:grinningface: which is d83d de00 002c d83d de00 in UTF16BE. If you extract first column by naively cutting the blob bytewise before the comma you end up with d83d de00 00 with extra NUL byte, which is a problem. With UTF16LE you'd prepend NUL which is even worse.

I think you somewhat misunderstood the manner I was suggesting you'd be approaching things there, though nothing you've said is incorrect.

Then I’m not sure what you were suggesting. The crux is that CSV operates upon strings, not bytes.

Re: Zig 0.9.0

#232

Post by uranusjr »

duped wrote: post #207
saagarjha wrote: post #163

Earlier quoted context omitted.

> Things like `.reversed()`, `.sorted(), and `.shuffled()` all work trivially correctly too (since you're not operating on a bag of bytes), and it's exceedingly rare that user input will confound the operations you might need to perform. One thing to note: aside from programming interviews, these operations are fairly rare. And that's a good thing, because none of these produce results that are very intuitive, becaus…

I use these operations on a daily basis, not in interviews. If you're ingesting third party data somehow (even if it's structured like JSON or XML) there are going to be cases where you need to hand roll a simple parser.

I’m genuinely very interested in the kind of data you’re dealing with. It’s common to need to reorder a list of strings, but I’ve personally never had any use case that requires me to reverse or sort _characters in a string_ to consume any kind of data (some kind of decoding, perhaps, but those tend to work better implemented at the byte array level, not string).

Re: Zig 0.9.0

#233

Post by anonymoushn »

svnpenn wrote: post #227
anonymoushn wrote: post #223

Earlier quoted context omitted.

ArrayList(u8) exposes a writer. You can write things to writers in various ways. Probably more than four ways! "appends to an existing byte slice" is not a completely coherent thing to ask for. If I give you a byte slice, the byte after the end it might belong to something else. If you want to deallocate my byte slice and make a new, replacement byte slice, you'll need an allocator to do that. An ArrayList(u8) has a…

> Can you share a Go program that uses the Go stdlib functions and cannot be trivially ported to use the Zig stdlib functions Heres an easy one: https://go.dev/play/p/JFIvQYTF3R8

Alright, I guess your objection is 100% about the function that accepts a 32-bit integer and encodes it as UTF-8 then.

Re: Zig 0.9.0

#234

Post by anonymoushn »

svnpenn wrote: post #227
anonymoushn wrote: post #223

Earlier quoted context omitted.

ArrayList(u8) exposes a writer. You can write things to writers in various ways. Probably more than four ways! "appends to an existing byte slice" is not a completely coherent thing to ask for. If I give you a byte slice, the byte after the end it might belong to something else. If you want to deallocate my byte slice and make a new, replacement byte slice, you'll need an allocator to do that. An ArrayList(u8) has a…

> Can you share a Go program that uses the Go stdlib functions and cannot be trivially ported to use the Zig stdlib functions Heres an easy one: https://go.dev/play/p/JFIvQYTF3R8

Please let me know the ways this does not do the right thing. Thanks.

https://www.godbolt.org/z/Y3z8rhzrq

Re: Zig 0.9.0

#235

Post by anonymoushn »

svnpenn wrote: post #209
feffe wrote: post #197

Earlier quoted context omitted.

Maybe Andrew is referring to this? I'm just guessing but that is the only thing I can think of which could be considered broken. Go mostly just treat strings as bag of bytes and you have to use one of the unicode packages to actually do any significant work with them. https://play.golang.com/p/Dla3sXciYXC I also think string handling in Go is pretty sane. But range vs indexing on strings is something you need to be a…

I don't see anything wrong in that example. As you said, golang has unicode/utf8, as well as the utf8string package. Is anyone really suggesting that the default slice should be on graphemes?

That's one of relatively few things that language-level utf-8 support could get you over utf-8 support in the standard library.

Re: Zig 0.9.0

#236

Post by [deleted] »

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.

[deleted]

Re: Zig 0.9.0

#237

Post by anonymoushn »

formerly_proven wrote: post #79
flohofwoe wrote: post #12

Earlier quoted context omitted.

IMHO Zig's builtin string handling (or rather, lack of) is exactly right for a systems programming language. Zig avoids the biggest problem of C strings and treats strings as ptr/length slices, not as zero-terminated. UTF-8 for string literals is also fine. That's all that's needed (and should be implemented) on the language level, everything else should go into the standard library, and additional specialized string…

u8 slices strike me as exactly the correct thing on the language level as well. In particular, it allows very straightforward zero-copy parsing/tokenization of strings. Most parsing of strings doesn't really need to know about UTF-8 and works correctly in the presence of non-ASCII codepoints. String literally are not really UTF-8. Rather, zig source files are UTF-8 (by definition), and string literals are u8 literals…

Zig already ships a bunch of libcs so I don't think there's much concern about bloating the standard library.

Re: Zig 0.9.0

#238

Post by anonymoushn »

rightbyte wrote: post #188
jstimpfle wrote: post #177

Earlier quoted context omitted.

For systems programmers the answer to "which third-party strings lib" is probably "None, write your own that fits with the rest of the system". A ready-made lib will be a lot of work to fit in - consider choice of internal encoding, allocation, hashing, buffering, mutable operations, etc.... Assuming that you really want to use UTF-8 internally, which is probably a sensible choice, the reusable part of a string libra…

> Many programs, in particular non-graphical programs don't need any UTF-8 code at all - UTF-8 handling is basically memcpy(). argv to main is utf8 on my system.

> argv to main is utf8 on my system.

That sounds totally compatible with programs that don't know anything about utf8. Do programs need to normalize the utf8 you pass in before using it as an argument to open(2) or something?

Re: Zig 0.9.0

#239

Post by anonymoushn »

chaz6 wrote: post #208
coldtea wrote: post #167

Earlier quoted context omitted.

When adopting a new niche language, with hardly any following, and frequent changes, and not even an 1.0, like Zig, "which version of UTF8" (as if that's an issue) is the least of your worries... "Which third-party strings lib of several half-complete incompatible libs" will be a much realer concern...

How feasible would it be to defer string processing to the operating system so that the behavior of all software running on it is the same? Perhaps a new OS interface could be defined for this purpose using syscalls on Linux. At the very least, there should be one canonical set of algorithms per operating system, rather than everyone downstream reinventing the wheel. Please forgive me if this sounds absurd, I am not…

I certainly don't want to pay for a syscall to do string encoding.

Also, a lot of the time the problem isn't that people are using fundamentally incompatible string libraries, but that there isn't one correct answer to the question they're asking and they chose different ways to convert the question into code. A reasonable question to ask is "How many extended grapheme clusters are in this string?" The answer is "It depends on what font you plan to use to render it." Not great!

Some programmers would still like to e.g. write a reverse() function that returns ":regional_indicator_f::regional_indicator_r:" unmodified (because it is the French flag emoji) and returns ":regional_indicator_i::regional_indicator_h:" when given ":regional_indicator_h::regional_indicator_i:". If such people want to avoid having nonsensical behavior in their programs, the only solution available is to decide what domain the program should work on and actually deal with the complexity of the domain chosen.

Re: Zig 0.9.0

#240

Post by svnpenn »

anonymoushn wrote: post #234
svnpenn wrote: post #227

Earlier quoted context omitted.

> Can you share a Go program that uses the Go stdlib functions and cannot be trivially ported to use the Zig stdlib functions Heres an easy one: https://go.dev/play/p/JFIvQYTF3R8

Please let me know the ways this does not do the right thing. Thanks. https://www.godbolt.org/z/Y3z8rhzrq

Im not sure how a 50 line program is better than a 5 line program, but OK. Also it seems you had to write functions to get the same result.

My original comment, was that Andrew has a habit of shitting on other languages without proper references or examples. Nothing you can really say is going to change Andrews behavior, so maybe you should stop, unless you can justify Andrews comments.

Post reply on HN