Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

a[low:high:max] in Golang – A Rare Slice Trick

build-your-own.org

Post reply on HN
Print view View original

91–100 of 131 posts

Re: a[low:high:max] in Golang – A Rare Slice Trick

#91

Post by saagarjha »

avgcorrection wrote: post #38
wyager wrote: post #11

Earlier quoted context omitted.

This is a pretty good vignette of how Go is designed. "Users don't need this feature (immutability, polymorphism, etc.), let's not include it. Ah crap, turns out we actually need it for a core language feature. Is there a lesson we can take away here? Nah, just make an ad-hoc implementation of the functionality in this one place."

For what it’s worth it sounds no worse than Java: you have immutable strings but you have no way to enforce that you can’t modify something that you have recieved, which is why the underlying char array for a string has to be defensively copied if the user asks for `asArray()` or whatever it is. Strings being immutable doesn’t seem like a special case, though. The underlying mutable array is just encapsulated, which…

Java gets a pass because it was early. Go had time to learn from its mistakes and…just refused to do so.

Re: a[low:high:max] in Golang – A Rare Slice Trick

#92

Post by masklinn »

Izkata wrote: post #18
gleenn wrote: post #3

Earlier quoted context omitted.

I don't know much Go but what does it mean to "accidentally" append to an immutable array? Are there just no particular guards for arrays and they are saying something which should be treated as immutable?

Sounds like they're just badly describing copy-on-write. The original slice uses no extra memory because as long as you treat it as immutable it won't actually make a copy. As soon as you try to modify it, then the copy is made and the extra memory used.

> Sounds like they're just badly describing copy-on-write.

It’s not quite copy-on-write, and what it’s really describing is a workaround / safeguard.

The problem is that by default Go slices will have as large a capacity as they can based on the parent, this is a problem if you return a slice to a still-in-use slice or array, and the caller decides to use that slice as a vector (either because the contract is not well documented or because they fucked up): appending to the “borrow” will happily go and stomp over the backing array, which may be holding in-use data of an other slice or the original array.

By forcing the slice to have no extra capacity, if a caller tries to append it’ll force a “fork” by realloc-ing and avoid the issue.

Re: a[low:high:max] in Golang – A Rare Slice Trick

#93

Post by konart »

andrewflnr wrote: post #47
ikiris wrote: post #22

Earlier quoted context omitted.

Part of it is that "large systems" are almost all combinations of small systems with proto boundaries, so it's not much of an actual risk unless you're making giant monolith code.

"Proto" meaning protobuffers?

I think it rather "communication via some protocol" in general.

In other words if we are not talking about giant monolith - we have N small systems to begin with.

Re: a[low:high:max] in Golang – A Rare Slice Trick

#94

Post by iKlsR »

jjice wrote: post #15

Tangential, but if OP is the owner of the site, could you talk a little bit about your book writing process? - How you write - How you render the PDF - How you develop your plans That kind of thing. I find it super interesting to self-publish software books and I've been slowly writing one for about a year now. Really curious about this stuff in general and it looks like you've got a solid process down.

From the author of Crafting Interpreters and Game Programming Patterns, some interesting stuff here about how he went about his two books which are excellent quality http://journal.stuffwithstuff.com/category/book/

Re: a[low:high:max] in Golang – A Rare Slice Trick

#95

Post by andromeduck »

kosherhurricane wrote: post #79
H4ZB7 wrote: post #64

why do people write articles about go features? when PHP was in its prime, almost nobody wrote blogs explaining how they found some philosophy in PHP. there's a reason for that. when you see someone open their article explaining a language feature by talking of the implementation details or specific use cases, that's a language smell (of course all industrial PLs stink). ironically go is the only post 80s language th…

TLDR: The best part of Go is that there is very little magic in Go. If you understand that slices are just fat pointers implemented as a built-in, there is nothing confusing about them. I can understand every part of a Go program, all the way down to the language syntax that generate assembly. I don't have to be afraid of or be mystified by any language feature, because 1) there are few, 2) they are just programs imp…

Why not just use c at that point?

Re: a[low:high:max] in Golang – A Rare Slice Trick

#96

Post by MrBuddyCasino »

morelisp wrote: post #40
Groxx wrote: post #32

Earlier quoted context omitted.

It means there is special protection for string-data that is not available to anything else, and that library-authors get panic reports about immutable byte slices. To that degree, it's something that the specialized type exposes you to but the type system does not adequately protect or signal. But yes, AFAIK this requires use of `unsafe`. Which does change things, and puts the blame for misuse squarely on the immuta…

> It means there is special protection for strings that is not available to anything else Lots of languages have no C/C++-style const objects yet immutable strings. It's weird to pick on Go specifically for this. (Since it's the JVM model, at this point it may even be a majority of mainstream languages.) If you mean specifically the panic when modifying a static string, is this not just the default `mprotect` on roda…

> Since it's the JVM model

Java model. Kotlin collections are immutable by default (not sure about Scala, but I suspect they behave the same).

Re: a[low:high:max] in Golang – A Rare Slice Trick

#97

Post by the_gipsy »

fooster wrote: post #86
wyager wrote: post #80

Earlier quoted context omitted.

This is a truly unreal level of blub paradox and/or brown nosing. It's almost a complete inversion of reality. Go's maintainers had to be beaten into bolting on a poorly-done implementation of polymorphism over like a decade. I can't imagine anyone who's used any language with polymorphism baked in to the design describing Go's implementation as "exceptionally well designed". If this is a Poe's law thing and you're j…

If you are going to make such a claim then please back it up rather than state opinions as facts.

https://go101.org/generics/888-the-status-quo-of-go-custom-g...

Re: a[low:high:max] in Golang – A Rare Slice Trick

#98

Post by the_gipsy »

kosherhurricane wrote: post #79
H4ZB7 wrote: post #64

why do people write articles about go features? when PHP was in its prime, almost nobody wrote blogs explaining how they found some philosophy in PHP. there's a reason for that. when you see someone open their article explaining a language feature by talking of the implementation details or specific use cases, that's a language smell (of course all industrial PLs stink). ironically go is the only post 80s language th…

TLDR: The best part of Go is that there is very little magic in Go. If you understand that slices are just fat pointers implemented as a built-in, there is nothing confusing about them. I can understand every part of a Go program, all the way down to the language syntax that generate assembly. I don't have to be afraid of or be mystified by any language feature, because 1) there are few, 2) they are just programs imp…

How can you call slices "little magic" when append may or may not modify the original slice?

So you pass something as a value, and something else as a pointer. But slices are passed as values but sometimes act like pointers.

Re: a[low:high:max] in Golang – A Rare Slice Trick

#99

Post by the_gipsy »

oefrha wrote: post #57
nutate wrote: post #26

My fave golang slice trick is the len of an empty slice is 0, but the slice itself is == to nil, but the len of nil won't compile. Can't understand that one. https://go.dev/play/p/MslCkBphl7q?v=gotip

> the len of an empty slice is 0, but the slice itself is == to nil That’s not true. An empty slice is initialized: []T{} or make(T[]); it’s not equal to nil.[1] The zero value nil slice is technically not an “empty slice”. Colloquially you may call a nil slice an empty slice, but the nil-ness is still an important distinction that manifests in e.g. encoding/json.Marshal; nil marshals to null, whereas an initialized…

How does it look with json.Unmarshal? Does a JSON null decode into nil or an empty slice? And a missing JSON field?

Re: a[low:high:max] in Golang – A Rare Slice Trick

#100

Post by TwentyPosts »

klodolph wrote: post #39
wyager wrote: post #11

Earlier quoted context omitted.

This is a pretty good vignette of how Go is designed. "Users don't need this feature (immutability, polymorphism, etc.), let's not include it. Ah crap, turns out we actually need it for a core language feature. Is there a lesson we can take away here? Nah, just make an ad-hoc implementation of the functionality in this one place."

Const is a hard language feature to design well. There are a lot of pitfalls in the way const is used in C++ and TypeScript (I’m including “readonly” in the discussion). Rust gets it right, but Rust is relatively complicated. The languages which are most similar to Go are Java and C#, both of which also lack const types, or have a very limited version of constness.

What are some of these pitfalls in C++'s const design? I assume the issue is that it's difficult to guarantee const correctness as long as you have the ability to fiddle with pointers?

Function signatures showing when a parameter gets modified and when not (such as in Rust, or even in properly const-speckled C++) would benefit Go, but I'm not sure how difficult it'd be to implement that. I could see it being difficult considering that one of Go's core features (slices) results in opaque and overlapping memory ownership.

Post reply on HN