4 ms·

> 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 stri

> 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 5y ago
[deleted]
coldtea 5y ago
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.
- bvrmn 5y ago
  > Python has the GIL. You are welcome to show fast single-core python interpreter without GIL. Coreteam will gladly accept your patches.
  - kzemek 5y ago
    That's how I understand "painted itself into a hole from the start" from the GP - removing GIL at this point is very hard because virtually all of Python language and code has been created in a world with the GIL.
    - bvrmn 5y ago
      It's nice to have atomic guarantees of GILed implementation. For me current CPython semantic is a golden middle: you have pretty fast interpreter without race conditions (for huge part of user code). Due to GIL. I always like to ask for what kind of task one needs GILless python? CPU bound? If you are using native python code for CPU bound tasks you are already in a bad place. C extensions can release GIL. For example numpy. What else?
      - kzemek 5y ago
        > I always like to ask for what kind of task one needs GILless python? > CPU bound? If you are using native python code for CPU bound tasks you are already in a bad place. While I think you may have misread my comment for a value judgement on Python's GIL, I don't see as particularly useful dismissing major potential (multithreaded) performance gains for a slow language just because there's faster languages. Languages that are better in some way - like speed - should stand as a benchmark and a goal, not a reason to give up improvements.
        bvrmn 5y ago
        I'm not against faster interpreter also. It's history now, but IMHO super slow GILless python with Java-esk data races in 199x would not gain such broad community and ecosystem.
      - duped 5y ago
        Anything with a hard or soft real-time constraint (audio, video, industrial automation, etc). You'd be shocked how many algorithmic prototypes are written in numpy then hand converted to C++ for realization.
        bvrmn 5y ago
        NumPy releases GIL. I love NumPy myself and created complex interactive realtime synths. It always was more convenient to slap Cython or C code to achieve desired 100x performance instead of getting potentially 10x (4x on my laptop) with multithreading.
anonymoushn 5y ago
Zig certainly has things like strings.Builder and strconv.AppendInt, which aren't really related to language-level encoding-aware string support.
- svnpenn 5y ago
  No it doesnt
  - anonymoushn 5y ago
    strings are called []u8, strings.Builder is called std.ArrayList(u8), strconv.AppendInt is called std.fmt.formatInt. Are you trolling?
    - svnpenn 5y ago
      those dont do the same thing at all. strings.Builder can append a byte, rune, string, or byte slice: https://godocs.io/strings#Builder 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.
      - anonymoushn 5y ago
        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?
feffe 5y ago
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 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 aware of.
- svnpenn 5y ago
  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?
  - anonymoushn 5y ago
    That's one of relatively few things that language-level utf-8 support could get you over utf-8 support in the standard library.

deleted 5y ago

[deleted]

coldtea 5y ago

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.

bvrmn 5y ago
> Python has the GIL. You are welcome to show fast single-core python interpreter without GIL. Coreteam will gladly accept your patches.
- kzemek 5y ago
  That's how I understand "painted itself into a hole from the start" from the GP - removing GIL at this point is very hard because virtually all of Python language and code has been created in a world with the GIL.
  - bvrmn 5y ago
    It's nice to have atomic guarantees of GILed implementation. For me current CPython semantic is a golden middle: you have pretty fast interpreter without race conditions (for huge part of user code). Due to GIL. I always like to ask for what kind of task one needs GILless python? CPU bound? If you are using native python code for CPU bound tasks you are already in a bad place. C extensions can release GIL. For example numpy. What else?
    - kzemek 5y ago
      > I always like to ask for what kind of task one needs GILless python? > CPU bound? If you are using native python code for CPU bound tasks you are already in a bad place. While I think you may have misread my comment for a value judgement on Python's GIL, I don't see as particularly useful dismissing major potential (multithreaded) performance gains for a slow language just because there's faster languages. Languages that are better in some way - like speed - should stand as a benchmark and a goal, not a reason to give up improvements.
      - bvrmn 5y ago
        I'm not against faster interpreter also. It's history now, but IMHO super slow GILless python with Java-esk data races in 199x would not gain such broad community and ecosystem.
    - duped 5y ago
      Anything with a hard or soft real-time constraint (audio, video, industrial automation, etc). You'd be shocked how many algorithmic prototypes are written in numpy then hand converted to C++ for realization.
      - bvrmn 5y ago
        NumPy releases GIL. I love NumPy myself and created complex interactive realtime synths. It always was more convenient to slap Cython or C code to achieve desired 100x performance instead of getting potentially 10x (4x on my laptop) with multithreading.

anonymoushn 5y ago

Zig certainly has things like strings.Builder and strconv.AppendInt, which aren't really related to language-level encoding-aware string support.

svnpenn 5y ago
No it doesnt
- anonymoushn 5y ago
  strings are called []u8, strings.Builder is called std.ArrayList(u8), strconv.AppendInt is called std.fmt.formatInt. Are you trolling?
  - svnpenn 5y ago
    those dont do the same thing at all. strings.Builder can append a byte, rune, string, or byte slice: https://godocs.io/strings#Builder 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.
    - anonymoushn 5y ago
      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?

feffe 5y ago

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 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 aware of.

svnpenn 5y ago
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?
- anonymoushn 5y ago
  That's one of relatively few things that language-level utf-8 support could get you over utf-8 support in the standard library.