←back to thread

Go is still not good

(blog.habets.se)
644 points ustad | 2 comments | | HN request time: 0s | source
Show context
813ac4312b25c ◴[] No.44983544[source]
> Probably [hello NIGHTMARE !]. Who wants that? Nobody wants that.

I don't really care if you want that. Everyone should know that that's just the way slices work. Nothing more nothing less.

I really don't give a damn about that, i just know how slices behave, because I learned the language. That's what you should do when you are programming with it (professionally)

replies(4): >>44983610 #>>44983714 #>>44983885 #>>44985349 #
terminalbraid ◴[] No.44983610[source]
If you're fine with that then you should be upset by the subsequent example, because by your own definition "that's just not the way slices work".
replies(1): >>44983646 #
813ac4312b25c ◴[] No.44983646[source]
I am fine with the subsequent example, too. If you read up about slices, then that's how they are defined and how they work. I am not judging, I am just using the language as it is presented to me.

For anyone interested, this article explains the fundamentals very well, imo: https://go.dev/blog/slices-intro

replies(1): >>44983686 #
terminalbraid ◴[] No.44983686[source]
Then you seem to be fine with inconsistent ownership and a behavioral dependence on the underlying data rather than the structure.

You really don't see why people would point a definition that changes underneath you out as a bad definition? They're not arguing the documentation is wrong.

replies(3): >>44983824 #>>45008203 #>>45008256 #
1. assbuttbuttass ◴[] No.44983824{3}[source]
The definition is perfectly consistent. append is in-place if there's enough capacity (and the programmer can check this directly with cap() if they want), and otherwise it allocates a new backing array.
replies(1): >>44983869 #
2. terminalbraid ◴[] No.44983869[source]
Yes, it's consistent and complicated and non-intuitive.

"Consistent" is necessary but not sufficient for "good".