5 ms·

Great list! Reminds me to check out more of the new stuff in 1.25. The one thing I wish Go had more than anything is read-only slices (like C#). The one thing

Great list! Reminds me to check out more of the new stuff in 1.25. The one thing I wish Go had more than anything is read-only slices (like C#). The one thing I wish more other languages had that Go has is structural typing (anything with Foo() method can be used as an interface { Foo() }.

mwsherman 1y ago
In Go, string effectively serves as a read-only slice, if we are talking about bytes. ReadOnlySpan<T> in C# is great! In my opinion, Go essentially designed in “span” from the start.
- jasonthorsness 1y ago
  Yeah I think the C# team was definitely influenced by Go with their addition of Spans.. Interesting approach regarding using strings as containers for raw bytes, but when you create one over a []byte I believe it makes a copy almost always (always?) so you can’t get a zero-cost read-only view of the data to pass to other functions.
  - mwsherman 1y ago
    That’s true, converting in either direction will typically allocate. Which it must, semantically. One can use unsafe for a zero-copy conversion, but now you are breaking the semantics: a string becomes mutable, because its underlying bytes are mutable. Or! One can often handle strings and bytes interchangeably with generics: https://github.com/clipperhouse/stringish https://github.com/clipperhouse/stringish
  - pjmlp 1y ago
    Like everything else in Go, spans predate it for a few decades.
- pjmlp 1y ago
  System languages from 1980's already had the span concept. One way that you will find it is that they used to be called open arrays in some of them.
gethly 1y ago
Yeah, having mutability optional would be great. It would also allow a lot of data to pass through the stack instead of heap due to pointers, which Go is riddled with for absolutely no reason(imo). On the other hand, now that we have iterators in Go, you can create a wrapper for []byte that only allows reading, yet is iterable. But then we're abstracting away, which is a no-go in Go and also creates problems later on when you get custom types with custom logic.
- eikenberry 1y ago
  > Yeah, having mutability optional would be great. It would also allow a lot of data to pass through the stack instead of heap due to pointers, which Go is riddled with for absolutely no reason(imo). My guess is that it is due to many developers bringing reference semantics with them from other languages to Go. It leads to thinking about data in terms of pointers instead of values.

mwsherman 1y ago

In Go, string effectively serves as a read-only slice, if we are talking about bytes. ReadOnlySpan<T> in C# is great! In my opinion, Go essentially designed in “span” from the start.

jasonthorsness 1y ago
Yeah I think the C# team was definitely influenced by Go with their addition of Spans.. Interesting approach regarding using strings as containers for raw bytes, but when you create one over a []byte I believe it makes a copy almost always (always?) so you can’t get a zero-cost read-only view of the data to pass to other functions.
- mwsherman 1y ago
  That’s true, converting in either direction will typically allocate. Which it must, semantically. One can use unsafe for a zero-copy conversion, but now you are breaking the semantics: a string becomes mutable, because its underlying bytes are mutable. Or! One can often handle strings and bytes interchangeably with generics: https://github.com/clipperhouse/stringish https://github.com/clipperhouse/stringish
- pjmlp 1y ago
  Like everything else in Go, spans predate it for a few decades.
pjmlp 1y ago
System languages from 1980's already had the span concept. One way that you will find it is that they used to be called open arrays in some of them.

gethly 1y ago

Yeah, having mutability optional would be great. It would also allow a lot of data to pass through the stack instead of heap due to pointers, which Go is riddled with for absolutely no reason(imo). On the other hand, now that we have iterators in Go, you can create a wrapper for []byte that only allows reading, yet is iterable. But then we're abstracting away, which is a no-go in Go and also creates problems later on when you get custom types with custom logic.

eikenberry 1y ago
> Yeah, having mutability optional would be great. It would also allow a lot of data to pass through the stack instead of heap due to pointers, which Go is riddled with for absolutely no reason(imo). My guess is that it is due to many developers bringing reference semantics with them from other languages to Go. It leads to thinking about data in terms of pointers instead of values.