I think what people often overlook when discussing generics in Go and code performance that uses generics, is that... the most important thing here is that the code that uses generic sort implementation is: 1. much shorter and more straightforward 2. actually type safe. Even if performance of such code is the same or a bit lower, it does not matter, because the main benefit is that you finally don't have to rely on interfaces (especially an empty one in case of sort.Slice) and have fewer possibilities of runtime panics thanks to that.
Are there any good write ups on Go Generics vs other languages for those of us who are familiar with Go but do not write it on a day to day basis? I pick up Go every few months to try new things cause its infinitely easy to setup a web server in Go since it is built-in.
I encourage you to explore why generics exist in the first place by exploring topics such as Parametric Polymorphism, Higher Kinded Types, & Higher Kinded Polymorphism.
Better to start with the problem than the most abstract formulation of its solution-- which only makes sense after successive encounters with ever more complex problems.
Simply, of course, we can begin with why it should be that data structures have operations in common -- rather than, say, having each their own specific versions.
Well: the polymorphism `+` allows us to express a common idea, that of "appending". For each of these specific types: int, string, array we can speak in the application-domain of "appending" whilst in the programming domain of "+"ing if we introduce an interface for `+`, that of "appendable",
interface Appendable[A] {
A + A -> A
A + 0 -> A
}
This interface allows us to use `+` generically in a principled way, the technical name for Appendable is `Monoid`, but i prefer Appendable (incidentally, Monad is `Sequencable` or `Nestable`).
Polymorphism is just the ability to speak as generically in the programming-domain as we speak in the application domain, ie., to use the double-meanings of ordinary thinking in programming.
Yours is a beautiful example of how to shoot yourself in the foot with reckless generalization. Addition of integers is commutative; concatenation of strings is not. That's not "a common idea". Compilers can transform a+b into b+a for one, if it suits them, but not for the other.
While integers with addition are an additive monoid and thus commutable it's still also a valid multiplicative monoid (or semigroup as described in the parent) and handy to be able to be passed to code that just needs an associative closed operation, maybe with an identity value.
Integer addition is a magma, semigroup, monoid, and group. It's _also_ a commutative version of each of those structures, but we can still definitely use it with functions only expecting multiplicative structures just fine.
The issue I take with using + for a multiplicative monoid like string concatenation is that readers of code should expect it to be commutative. Using x or * is probably better, using ⓧ is mathematically nice but a pain to type, so something like ++, <>, .., or some other new operator just for concatenation is imo best.
I'm not sure I see the reckless generalisation. I said `+` meant append, not add. We can use addition in the case of integers to serve as `append`, but its a special case of appending where A+B == B+A.
In python, where I take the example, `+` performs that role,
[a() + a() for a in (str, bool, int, list, tuple)]
Just a nit, for floats it is not commutative either, not sure how much freedom do compilers have here. E.g. try summing many floats in decreasing value - chances are that adding a very small number in the end will not even change the value.
Addition of ints is associative, addition of floats is not, yet generalizing over these two numeric types is a core ability people expect from generics.
The change mentioned at the top of the post (https://go-review.googlesource.com/c/exp/+/378134) also has a benchmark to compare sorting structs using sort.Slice vs a new generic approach that uses a comparison function:
name old time/op new time/op delta
SortStructs-8 18.6ms ± 2% 15.9ms ± 3% -14.43% (p=0.000 n=10+10)
14.4% is the speedup of the generic version.
The article explains why this happens (towards the end).
Unsolicited commentary: I think my commitment to a thorough reading was limited by my interest in the performance of bubble sort. On the other hand, the code for sort.Search also fits in a blog post, and it's a function I have called inside a loop.
That's a good point, thank you for bringing it up. Finding the right examples is really tricky. sort.Search is binary search and hence a bit tricky to benchmark properly because of how ridiculously fast it is. Only a handful of comparison calls are made even for huge slices.
My understanding is that pointer types all use dynamic dispatch in practice, because they share the same "gcshape" under the hood, today. Obviously this is very coarse grained.
However, the article points out this will likely change in the future, since the compiler now has enough information to do so. The Go team made a good call imo resisting to optimize this. Now, they can observe how generics are used in the global Go community and then optimize using real world code.
In fact, optimize is an understatement, because dyn dispatch vs monomorphization is a trade-off between compilation time + binary size vs speed (as C++ and Rust programmers know too well). Optimizing early based on microbenchmarks would likely have given an advantage in favor of monomorphization, but may not be suitable for average-to-large binaries in the a generic-heavy future. I assume the team wants to find a good balance for the 99%, and avoid compiler flags, hint-syntax, profile guided optimizations and so on if they can..
You'll still have a dynamic Less() equivalent - unless the sorting function gets inlined, which sounds unlikely. But sort.Slice() relies on reflection to do the swapping, which performs even worse than a call to a virtual Swap(). That would now be an ordinary index swap within the sort function. So you'll probably still see major speedups with bubbleSortFunc or some equivalent.
> You'll still have a dynamic Less() equivalent - unless the sorting function gets inlined, which sounds unlikely.
Sorting or ordering?
Using a custom comparator is covered later on, and shows that the ordering function (the custom comparator) is not inlined because of how Go 1.18 groups GC shapes.
However an article from a few days ago (https://planetscale.com/blog/generics-can-make-your-go-code-...) showed that it can be made to work, in some cases, by parametrising the function on the callback. This leads to the sorting function being monomorphised on the callback, and thus the callback (likely) getting inlined.
Yeah Go is all about "simple, fast enough, compiles fast"
So I'd say knobs to control this, which, if you get them wrong, lead to slow compiles, would defnly be contra the spirit of Go.
And in cases where absolute max performance really matters, nothing is stopping you from monomorphizin by hand. (But if absolute max perf really matters, you probably picked the wrong language.)
There is no language that writes code as beautiful code as go, at a lower level. C comes close, but C++/Rust are plain ugly, while C is older than some HN users and requires a lot of third-party dependencies for basic operations (e.g http requests).
It sucks a bit, but I find the tradeoff quite good. The Go folks have managed to make a language which is quite low level and with a small fairly transparent feature set which still manages to produce code which is not too verbose.
Java and C# for instance despite being much higher level languages tend to require far more verbose code.
I have played with some crypto code and concurrency in all languages to compare and was pleasantly surprised by how much more compact Go code ended up being while also being easy to read and using fairly simple constructs.
You can often get smaller Java and C# code but at the expense of using far more complex and abstract concepts.
There is a sense of good balanced taste in how Go featured and libraries are made which often lacks in many other languages.
i think go (as any other language) shines in some use cases, is meh in some use cases and straight-up sucks in others. the problem i'm seeing is the cargo cult where basically go is the ultimate answer and everything has to be rewritten in it.
Yeah, the fact that I can write a production capable JSON API server in about 5 lines of code with no external dependencies is golden. Compile and start times are tiny. Native executables are brilliant. The ergonomics of Go go well beyond just LOC.
I'm also not really sure what the complaint is. Go doesn't do any more implicit type conversion than Rust does. There are numerous solid arguments for Go over Rust, but error handling and automatic type punning aren't on the list.
Beauty is of course necessarily in the eye of the beholder, but Rust doesn't look ugly to me. One of the first things that jumps out is how little boiler plate Rust's canonical Hello World program has, Go doesn't do badly here either (certainly compared to C, C++ or Java), but it does introduce a bunch of ancillary stuff like packages and importing that are peripheral to our purpose in writing Hello, World!
> Beauty is of course necessarily in the eye of the beholder
This is so true. Not is disparage other languages, but golang isn't beautiful to me at all, and neither is python. Yet Rust is nearly perfect. I'm strange. I get it!
The Go example seems a lot simpler without the Ok/Some/.into()/? That are unrelated to sending hello world. There's also no macro magic to understand.
In general my observation is the ancillary stuff (and in general number of things you need to understand) is greater in rust. That's paired of course with greater expressivity.
I've never really understood why the lack of Result/Option types are somehow spun as a good thing. Other things about Rust can be complex and can require some diligence to learn, but Result/Option types over golang's way of handling the same thing? Seriously? That's the argument for golang?
I don’t think that’s the argument for Go. It’s a decision that Go developers accept as a trade off for other things that are nice about Go.
I haven’t learned Rust yet, maybe one day I will, but it looks a lot more complex to me, and it’s hard to see how the extra complexity will help me write better web servers.
It’s OK for Rust and Go to solve different problems with different trade offs.
Totally agree with you. And I totally get why some people would prefer golang.
Don't like how some constantly feel the need to compare golang and Rust (two very different languages), and how some feel like the comparison is always favorable to golang. Like you said -- there are tradeoffs. golang folks seems to have a problem acknowledging that Rust made a few good decisions too, like Result and Option types, mostly because they haven't ever used them.
It's hard for me to imagine someone using them (golang has generics now, so get ready!) and not liking them. Especially golang. It's just so weird to hear that someone describe one of the warts of golang as actually beautiful, instead of, as you say, a tradeoff.
Rust has a certain amount of friction. It takes some work to learn well enough to feel productive. I don't know if it's all that bad. But, yes, it is a clear tradeoff for people who mostly work in domains in which golang works well enough to really pretty great, like writing web servers.
Ok. Ironically, your comment came across to me as a comparison, but I guess we were both reacting to the same sense, that it’s not a race.
In fact, I’d really love to learn Rust - GC always feels like a nasty hack to me - but my current use case and time constraints mean that I won’t get to use what I learn, and will quickly forget, so it’s just a waste of time for me at the moment.
What's nice about "Hello, World!" is that it's a canonical example where we know exactly what it's supposed to do, in contrast these pages are showing off features of writing Spin components in different languages so that makes it much harder to compare.
In each case they're using a popular existing HTTP library for its familiar APIs, but the chosen APIs are of course not the same in Go and Rust.
The Go API (from net/http) follows typical Go style, it assumes success, and doesn't worry too much about errors. If you write any data to the ResponseWriter (which this example does), you get a 200 OK response anyway. You don't need to set types, it'll guess, likewise you don't need to care about binary data, it'll guess. This is cheerful and will mostly work, if it doesn't work you can probably learn what you did wrong and try again.
The Rust API (from the http crate) follows more typical Rust style. You must say whether you succeeded with Ok, so that failures can be handled appropriately. You can choose whether your response has a body we do have a body here so hence we need to write Some. Finally HTTP bodies are binary data, and we'd like to return a string, so we use the Into trait to get the UTF-8 encoded text out of the string as bytes, this is how Rust stores strings anyway so it will be trivial.
The Rust code sets header "foo" to "bar" for some reason, and also prints (to console) all the information about the request, presumably because that's trivial to do in Rust, the Go code doesn't do either of these things.
I agree that there certainly is a lot more Rust, it's just that I'd say it's beautiful rather than ugly, a matter of opinion.
