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

Go by Example

gobyexample.com

Post reply on HN
Print view View original

81–90 of 130 posts

Re: Go by Example

#81

Post by jamesaguilar »

justin66 wrote: post #80
jamesaguilar wrote: post #56

Earlier quoted context omitted.

Ah. I see where our disagreement comes from. I do not believe that everyone is very aware of these issues. I believe go users are, but since this entire thread is evangelistic, there are people here who are not currently go users who are not aware. The exclamations of surprise at my provided example are proof enough of this for my satisfaction.

You do realize that people who look at the tutorial will discover the lack of generics on their own, right? And that if they share the "my God, lack of generics is a war crime!" attitude, they're bound to discover it literally right away?

This argument can equally be used to protest the saying of anything good about the language, since obviously people who try the language will discover this good thing quickly if it's useful. This is not a compelling argument to me.

Re: Go by Example

#82

Post by burntsushi »

a-nom-a-ly wrote: post #77
jamesaguilar wrote: post #21

Earlier quoted context omitted.

One nice thing these examples also do is make it really simple for detractors to point out what they don't like about it. My #1 gripe about go, for example, is this: https://gobyexample.com/sorting-by-functions In a few other languages: // C++ sort(vs.begin(), vs.end(), [](const string& l, const string& r) -> bool { return l.size() When they fix this, Go might be the perfect language for me. Until then, I'm not touch…

You can do this just as easily in Go as well, using reflection.

Yup! Here ya go:

    // Sort a slice of structs with first class functions.
    type Album struct {
    	Title string
    	Year int
    }
    albums := []Album{
    	{"Born to Run", 1975},
    	{"WIESS",       1973},
    	{"Darkness",    1978},
    	{"Greetings",   1973},
    }
    
    less := func(a, b Album) bool { return a.Year
For more fun things, see: http://godoc.org/github.com/BurntSushi/ty/fun

Re: Go by Example

#83

Post by jamra »

masklinn wrote: post #61
jamra wrote: post #51

Earlier quoted context omitted.

Why not make an interface called iCompare that has a single function: compare, which takes an object of type interface{}. You can then implement that single compare function, attached to your type of choice. Problem solved.

You're only solving the example (painfully and incompletely as well, because now you can't sort your collection twice using different criteria, and I believe you can't sort objects you don't fully control since you can't add methods to somebody else's types — let alone a builtin, woe is you if you're attempting to sort maps). How do you handle a non-inplace sort? How do you handle implementing a treeset or a b-tree?…

1. You can add methods to other people's types.

2. My solution is not incomplete. It solves the stated problem exactly. If you need to sort the objects with a different criteria, implement the interface with whichever criteria you want. It's not so difficult. Generics will not save you from having to implement some kind of comparison criteria in other languages.

3. You can add more methods to the interface for an out of place sort.

4. If you need to implement a b-tree, add the methods to whichever type you need to sort appropriately.

It's not that big of a problem. You will not have to up and down cast. You only have to cast a type of interface{} to your type once and only once while you are comparing.

Is your problem ideological or specific to this example?

Re: Go by Example

#84

Post by burntsushi »

masklinn wrote: post #46
bsg75 wrote: post #20

Earlier quoted context omitted.

Go does not have a lot of new features, but mostly a specific collection of convenient ones (static compilation, GC, etc.) Not sure how many new languages have truly new features, vs. how many are improvements in productivity (human and machine). My point is that generics are not a new idea either, and plenty of languages offer them. Go is not meant (anymore) to replace C/C++/Java or even Rust. It will never have all…

> But it seems impossible to have a HN discussion on Golang without part of the thread getting hijacked with "But generics!!!" Surely the exact same criticism could be leveraged at go proponents pointing out the exact same features they love every time, should discussions of Go simply stop until the next major release, and only new features (if any) be discussable?

> Surely the exact same criticism could be leveraged at go proponents pointing out the exact same features they love every time

This thread was started by someone complaining about lack of generics.

> should discussions of Go simply stop until the next major release, and only new features (if any) be discussable?

Why? Because there's no reasonable middle ground between "don't ever talk about Go until there's a release" and "hijack every thread about Go"?

Re: Go by Example

#85

Post by burntsushi »

Dewie wrote: post #34
scriptproof wrote: post #32

Earlier quoted context omitted.

http://commandcenter.blogspot.co.uk/2011/12/esmereldas-imagi...

"I resolve to recognize that a complaint reveals more about the complainer than the complained-about. Authority is won not by rants but by experience and insight, which require practice and imagination. And maybe some programming." Of course, being Rob Pike, decreeing that authority and experience is more valuable than any (well-reasoned) complaints from other people is a very convenient stance for him to take; how m…

That's pretty much the boiler plate ad hominem.

Re: Go by Example

#86

Post by masklinn »

dsymonds wrote: post #68
masklinn wrote: post #43

Earlier quoted context omitted.

> A few extra lines for sorting It's not just sorting, it's any parametric polymorphism: generic operations or non-built-in containers (not just in the sense of "array", an atomic ref is also a container) for instance. Go only lets do these in verbose, clunky ways, and losing much of the type safety Go is supposed to provide (what with being a statically typed language) > no-one's trying to claim that the shortest co…

The post I replied to didn't explicitly say what he disliked about sorting in Go, and what "this" means in "When they fix this". I guessed that it was because the Go code is a bit longer. What else could it be? I guess it's a little clunkier, and it's true that writing generic containers in Go isn't so great, but is that sufficient to elicit a reaction of "I'm not touching it with a pole"? Nobody claims it's perfect,…

> it's true that writing generic containers in Go isn't so great

That's one hell of an understatement.

> is it really sufficiently horrible to warrant that?

A number of people obviously and repeatedly say that yes, a statically typed language without parametric polymorphism is sufficiently painful to use something else instead.

Re: Go by Example

#90

Post by colin_mccabe »

natural219 wrote: post #39
jamesaguilar wrote: post #21

Earlier quoted context omitted.

One nice thing these examples also do is make it really simple for detractors to point out what they don't like about it. My #1 gripe about go, for example, is this: https://gobyexample.com/sorting-by-functions In a few other languages: // C++ sort(vs.begin(), vs.end(), [](const string& l, const string& r) -> bool { return l.size() When they fix this, Go might be the perfect language for me. Until then, I'm not touch…

Wow, yeah. This is pretty bad. The example doesn't even make logical sense. Why is ByLength a type? Shouldn't you just want to pass in an array? Can any "idiomatic" Go programmers here give a better example of how you would do this?

Can any "idiomatic" Go programmers here give a better example of how you would do this?

Sure.

sort.Sort(sort.Reverse(sort.StringSlice(vs)));

Post reply on HN