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

221–230 of 250 posts

Re: Zig 0.9.0

#221

Post by noisem4ker »

skybrian wrote: post #69
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…

I’m not aware of any significant breakage due to Go’s handling of strings. Where would I read more about this?

Go presents strings as slices of bytes (chars). As long as it's ASCII, it's fine. However, when dealing with multi-byte UTF-8 characters (codepoints), the proper unit is the rune. So, before attempting to measure a string's length, or read its n-th character, one must remember and access the string as a slice of runes.

  s := "naïve"
  
  // bad
  fmt.Println(len(s)) // 6
  fmt.Println(string(s[2])) // Ã
  
  // good
  r := []rune(s)
  fmt.Println(len(r)) // 5
  fmt.Println(string(r[2])) // ï
https://go.dev/play/p/YbMo49wU7vu

Re: Zig 0.9.0

#222

Post by ksec »

rmanolis wrote: post #50

I love Zig. But unfortunately there are no use cases for web developers yet that Go and JavaScript does not do already … unless the webassembly replace JS for more cool and futuristic UI.

Wait until Bun is officially released. Which would be useful for vast majority of web developers.

https://bun.sh

Re: Zig 0.9.0

#223

Post by anonymoushn »

svnpenn wrote: post #215
anonymoushn wrote: post #214

Earlier quoted context omitted.

strings are called []u8, strings.Builder is called std.ArrayList(u8), strconv.AppendInt is called std.fmt.formatInt. Are you trolling?

those dont do the same thing at all. strings.Builder can append a byte, rune, string, or byte slice: https://godocs.io/strings#Builder ArrayList cant do that. And strconv.AppendInt can convert a number to byte slice, then it appends to an existing byte slice. formatInt cant do that.

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 byte slice, and knows how much of it is unused, and has an allocator so it can make a new larger byte slice if needed, and exposes a writer so that you can call std.format.formatInt to write into the byte slice (or allocate a new byte slice, copy the entire contents, and write into the new one, if appropriate).

> strconv.AppendInt can convert a number to byte slice, then it appends to an existing byte slice. formatInt cant do that.

As we have learned just now, we actually can use formatInt to append a formatted int to an existing byte slice (to the extent that that's a meaningful thing to ask for), by passing it the writer exposed by an ArrayList(u8)!

Is your complaint that you're not aware of any function in Zig that takes a u32 representing a Unicode codepoint and encodes it to UTF-8 and writes it to a writer (which is what "appending a rune" seems to mean)?

Is your complaint that people do not, by convention, allocate new, larger byte slices without an explicit reference to an allocator?

Is your complaint is that Zig does not have a garbage collector?

Can you share a Go program that uses the Go stdlib functions and cannot be trivially ported to use the Zig stdlib functions instead, for some reason other than that Zig programs must decide where the bytes will live, and Go programs need not do that?

Re: Zig 0.9.0

#224

Post by anonymoushn »

AndyKelley wrote: post #103
pcwalton wrote: post #29

Earlier quoted context omitted.

That warning has caught bugs for me when I was copy and pasting code, or writing code on "autopilot". Usually it's pretty obvious mistakes though. Unused variable warnings are a good idea, but making them hard errors is a language design mistake. Warnings are good because they allow programmers to quickly make changes and test things, while providing a reminder to clean things up in the end (which is why the "just us…

Pretty bold to call it a language design mistake so confidently, when you have Rust users committing warning-emitting code to their source control. Does Rust emit warnings for cached compilation units?

I think it's reasonable for users to want a workflow that includes some mode where they can temporarily compile code that has unused variable, then check in code that does not have unused variables. The trouble is that if there's such a mode, people will just leave it on permanently. I don't have solutions, but I think it's worth trying to save people's workflows.

Re: Zig 0.9.0

#225

Post by roca »

_vvhw wrote: post #156
roca wrote: post #155

Earlier quoted context omitted.

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

Which version of UTF8?

Regular UTF8, not WTF-8 or any of those other variants (which are for encoding data that is not necessarily Unicode).

Re: Zig 0.9.0

#226

Post by lmm »

lhorie wrote: post #220
lmm wrote: post #157

Earlier quoted context omitted.

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

ASCII is kinda special in that it's both a way of encoding strings and it has character-to-byte equivalence. You can specify an HTTP header as being any number of characters between `\n\r` characters or any number of bytes between `0x0A 0x0D`, and the parsing code is going to compile to pretty much the same thing regardless of whether you know what `0x0A` means or not.

Right, but to do case-insensitive comparisons of header names you need to decode them as strings, not just byte sequences.

Re: Zig 0.9.0

#227

Post by svnpenn »

anonymoushn wrote: post #223
svnpenn wrote: post #215

Earlier quoted context omitted.

those dont do the same thing at all. strings.Builder can append a byte, rune, string, or byte slice: https://godocs.io/strings#Builder ArrayList cant do that. And strconv.AppendInt can convert a number to byte slice, then it appends to an existing byte slice. formatInt cant do that.

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

Re: Zig 0.9.0

#228

Post by gautamcgoel »

AndyKelley wrote: post #34
diegocg wrote: post #25

Earlier quoted context omitted.

They can put it on the standard library or the core language or wherever they want, but they absolutely need to provide good string handling. And regardless of where they put the code, this is something that needs to be done by the core team. Otherwise you will end with too many string libraries, all of them trying to solve a particular problem and doing bad at everything else, with bad documentation and different AP…

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…

Can you elaborate on why you think Go's string handling is broken?

Re: Zig 0.9.0

#229

Post by skybrian »

noisem4ker wrote: post #221
skybrian wrote: post #69

Earlier quoted context omitted.

I’m not aware of any significant breakage due to Go’s handling of strings. Where would I read more about this?

Go presents strings as slices of bytes (chars). As long as it's ASCII, it's fine. However, when dealing with multi-byte UTF-8 characters (codepoints), the proper unit is the rune. So, before attempting to measure a string's length, or read its n-th character, one must remember and access the string as a slice of runes. s := "naïve" // bad fmt.Println(len(s)) // 6 fmt.Println(string(s[2])) // Ã // good r := []rune(s)…

Yes, but I think most Go developers are aware of Go's quirks, so I'm wondering what bugs happen despite that awareness.

Re: Zig 0.9.0

#230

Post by chrismorgan »

lhorie wrote: post #218
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.

> cutting the blob bytewise That doesn't make sense. If you're working with utf16, why would you slice bytewise? That's like slicing a zip file bytewise and wondering why it got corrupted. The whole point of the argument for string support at a library level (rather than assuming some sort of equivalence between stringness and its underlying byte buffer at the language level) is that fixed width bytes fundamentally c…

The entire matter in question is whether CSV is encoding-independent, operating on bytes (we’re addressing AndyKelley’s comment). The answer clearly demonstrated here is: no, CSV is operating upon characters, not bytes, so you need to decode the Unicode first and let the CSV operate on Unicode data, so that it’s splitting on U+002C, rather than 0x2C in the byte stream before Unicode decoding which destroys the data.
Post reply on HN