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

Faster Sorting with Go Generics

eli.thegreenplace.net

Post reply on HN
Print view View original

41–50 of 62 posts

Re: Faster Sorting with Go Generics

#41

Post by jhgb »

mjburgess wrote: post #32
mjburgess wrote: post #20

Earlier quoted context omitted.

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.

Why not elaborate some more? I'm bored, so... 2 + 2 == 4 "Hello" + "World" == "Hello World" [2, 2] + [3, 4] == [2, 2, 3, 4] Should we bother reusing `+` for this? Why not, 2 intPlus 2 == 4 "Hello" strPlus "World" == "Hello World" [2, 2] arrayPlus [3, 4] == [2, 2, 3, 4] 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…

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.

Re: Faster Sorting with Go Generics

#42

Post by tehnub »

rventure wrote: post #17
dilap wrote: post #14

Earlier quoted context omitted.

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).

Zig

Re: Faster Sorting with Go Generics

#43

Post by maleldil »

esprehn wrote: post #35
mirceal wrote: post #23

Earlier quoted context omitted.

if err != nil { return nil, err } code poetry right there. it's so good that you have to repeat this over and over again!

To be fair in rust you get to write .into() or Ok a lot. I do find Go's error handling annoying but rust seems similar for line noise. It's more compact noise, but it's all there.

Those are for the cases where you're creating or transforming an error. In those scenarios, Go's handling isn't that bad.

The issue is having to write `if err != nil { return nil, err }` versus `func()?`. The former gets old really fast.

Not to mention the other benefits of monadic error handling when compared to glorified error codes.

Re: Faster Sorting with Go Generics

#45

Post by doctor_eval »

socialdemocrat wrote: post #37
mirceal wrote: post #23

Earlier quoted context omitted.

if err != nil { return nil, err } code poetry right there. it's so good that you have to repeat this over and over again!

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 an…

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.

Re: Faster Sorting with Go Generics

#46

Post by doctor_eval »

mustache_kimono wrote: post #39
esprehn wrote: post #36

Earlier quoted context omitted.

Spin showed up on HN recently as an interesting example of Go vs Rust hello world: (Rust) https://spin.fermyon.dev/ Vs (Go) https://spin.fermyon.dev/go-components/ 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)…

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.

Re: Faster Sorting with Go Generics

#47

Post by burnished »

mirceal wrote: post #23
rventure wrote: post #17

Earlier quoted context omitted.

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).

if err != nil { return nil, err } code poetry right there. it's so good that you have to repeat this over and over again!

yeah errors appear to be a wart

Re: Faster Sorting with Go Generics

#48

Post by esprehn »

tialaramex wrote: post #40
esprehn wrote: post #36

Earlier quoted context omitted.

Spin showed up on HN recently as an interesting example of Go vs Rust hello world: (Rust) https://spin.fermyon.dev/ Vs (Go) https://spin.fermyon.dev/go-components/ 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)…

Hmm. I think you intended to link: https://spin.fermyon.dev/rust-components/ 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 th…

The link was the correct one, scroll down and you'll see a simple hello world example that matches what the golang one does.

Re: Faster Sorting with Go Generics

#49

Post by mustache_kimono »

doctor_eval wrote: post #46
mustache_kimono wrote: post #39

Earlier quoted context omitted.

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.

Re: Faster Sorting with Go Generics

#50

Post by doctor_eval »

mustache_kimono wrote: post #49
doctor_eval wrote: post #46

Earlier quoted context omitted.

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 b…

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.

Post reply on HN