81–90 of 131 posts
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."
Which modern languages do const properly?
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."
I don’t think you can fairly call go’s generics an “ad-hoc” implementation. They added syntax for it.
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…
It's just a tautology. If you understand something, of course by definition you aren't confuse about them. By using the same logic, all languages have "very little magic."
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…
I wonder how many off-by-one bugs have happened undetected because a slice is unintentionally resliced beyond its length. Instead of crashing, so that the issue is known early, the program will still run with inconsistent data.
Earlier quoted context omitted.
I think in this context "ad hoc" refers to the context in which that syntax was added. IIRC the original creators were against generics ever being added to Golang, so they wouldn't have thought about their eventual introduction when choosing Go's initial syntax. The result is that the generics that eventually were added feel awkward and "bolted on" to many people. (I don't have any strong opinions on it personally, b…
Maybe you shouldn't play game of telephone like that. Go generics are exceptionally well designed. The reason it took so long for Go to get generics is because Go designers took their time to arrive at a design that fits with the rest of Go. It's not rushed, it's not "bolted on". They did several designs that they rejected before they accepted the design that got implemented.
Earlier quoted context omitted.
Maybe you shouldn't play game of telephone like that. Go generics are exceptionally well designed. The reason it took so long for Go to get generics is because Go designers took their time to arrive at a design that fits with the rest of Go. It's not rushed, it's not "bolted on". They did several designs that they rejected before they accepted the design that got implemented.
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…
This to me is a glaring case of a poorly named variable. a[low:high:capacity] would be much easier to understand at first sight.
Question: what is the reason for the silent copy when append exceeds the original slice cap? It's a footgun avoided by reading the spec and (maybe) remembering it in practice, but it feels like it would be safer to throw a comp error and force the user to deal with it when a user is trying to exceed the cap of the underlying array? Alternative is defensively using len() and cap() for slice ops in which case error-ing…
Because Go slices play double duty as vectors. And that is the usual behaviour of a vector.
And the issue is the opposite situation, when appending does not exceed the original slice cap. The entire point of the slice trick is to force a resize (and thus a copy) on append.
> it feels like it would be safer to throw a comp error and force the user to deal with it when a user is trying to exceed the cap of the underlying array?
It would be safer to have not confused slices and vectors, but half-adding that confusion sounds even worse, your suggestion would only keep the worst parts, and would require hand-rolling the rest every time.
Earlier quoted context omitted.
> Slices (largely) behave like this in most languages Only on assignment, not in appending. > Go's contribution is mostly that slices and append are ubiquitous Go's contribution is the conflation of slices and vectors, which in most languages are separate (or really most languages only have the latter and don't provide access to backing arrays, thus precluding this specific confusion).
In C++, until C++20’s std::span, you would just use std::vector for stuff you can modify and const std::vector for stuff you can’t. I think the real problem is that Go’s type system doesn’t catch the common error of keeping a reference to something you don’t own, or similar errors. C# catches some of these errors by letting you return a IReadOnlyList or some other restricted type. Golang has ways to narrow certain ty…
That doesn't align with my experience. I've worker for small (4 programmers) and large (100s of programmers) C# shops, and I don't recall people "fretting" about T[] and List. People see T[] as a non-growable, less useful version of List. HashSet vs List seems to cause much more trouble for novice (and sometimes experienced) C# programmers.
Earlier quoted context omitted.
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…
> 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. It's just a tautology. If you understand something, of course by definition you aren't confuse about them. By using the same logic, all languages have "very little magic."