←back to thread

Go subtleties

(harrisoncramer.me)
235 points darccio | 3 comments | | HN request time: 0.411s | source
Show context
jasonthorsness ◴[] No.45669948[source]
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() }.

replies(2): >>45670075 #>>45672522 #
mwsherman ◴[] No.45670075[source]
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.

replies(2): >>45670185 #>>45679279 #
1. jasonthorsness ◴[] No.45670185[source]
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.

replies(2): >>45670870 #>>45679274 #
2. mwsherman ◴[] No.45670870[source]
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

3. pjmlp ◴[] No.45679274[source]
Like everything else in Go, spans predate it for a few decades.