Love it, bookmarked. I've been hoping for something like this for a while. One of the most frustrating things for me about trying to pick up Go is a lack of 'guaranteed quality' examples of different basic operations, especially code that adheres to the latest spec.
Go by Example
101–110 of 130 posts
Re: Go by Example
#102Earlier quoted context omitted.
> 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.
I'm curious what programs people are writing where parametric polymorphism is so crucial. I've written hundreds of thousands of lines of Go code (servers, web apps, data processing, etc.), and there's probably been maybe O(hundreds) of lines of code that were annoying or tedious because of a lack of parametric polymorphism. My suspicion is that what's more likely is that lots of people don't want to consider writing…
"But maybe there's a whole class of problem (actual problem, not a sub-problem like "I want to implement a container") that I don't come in contact with."
i want to apply a transformation to every element in a collection
i want to select the elements from a collection for which some predicate holds true
Re: Go by Example
#103Earlier quoted context omitted.
On the other hand, C++ templates sometimes make it hard to understand which function ends up getting called, what size a particular type actually has or what is an alias for what. There are too many indirections to follow manually. All I know is that the compiler will select some function that has conforming types. The compiler is very very smart. It knows all the incredibly complicated name resolution rules and it w…
You're criticizing ADL, not generics.
It's true that I'm not criticising generics in general, but ADL is only part of what makes C++ templates so treacherous.
I think Go needs some form of generics. Every statically typed language does. But after C++ I do understand the hesitation on the part of Go's creators.
Re: Go by Example
#104Earlier quoted context omitted.
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)));
Oops, I looked at the Python code again, and it seems to be sorting the strings by their length, not reversing the sort order like I did. Sorry, I didn't look at it very carefully earlier. Anyway, the easiest thing to do is probably write a wrapper type around StringSlice using Go's anonymous struct syntax. You only need to implement LessThan, since StringSlice already implements the other two.
type StringSliceByLength struct {
sort.StringSlice;
}
func (s StringSliceByLength) LessThan(i, j int) bool {
return len(s.StringSlice[i]) Re: Go by Example
#105Earlier quoted context omitted.
> 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.
I'm curious what programs people are writing where parametric polymorphism is so crucial. I've written hundreds of thousands of lines of Go code (servers, web apps, data processing, etc.), and there's probably been maybe O(hundreds) of lines of code that were annoying or tedious because of a lack of parametric polymorphism. My suspicion is that what's more likely is that lots of people don't want to consider writing…
I think a big part of the issue is that in Java and C++, you really need generics a lot more than in Go. Without templates, you would not have any easy way of doing maps and lists in C++. There are no builtin types for those like in Go. The way the type system works in those languages also makes things very difficult if you don't have generics.
Think about the sorting example I wrote earlier: https://news.ycombinator.com/item?id=7080562 If you were writing it in Java, is sort.Sort an interface or an abstract base class? Well, you can only "extend" one class (single inheritance only), so you would probably want Sort to be a Java interface. That means that you would always have to implement all three functions, not just one as I did, since Java interfaces cannot have default implementations. The comments indicate that most posters didn't even consider the idea that you could reuse the StringSlice functions. That method of easy composition simply doesn't exist in Java.
In general, generics get used a lot as a band-aid to avoid multiple inheritance in C++ and Java. You can't (or shouldn't, in C++) have your Foo inherit from both a (non-abstract) Bar and Baz. But you can certainly template on them. In C++, this kind of thing is called "traits" and Alexandrescu wrote a whole book about it. It's also why std::string is actually std::basic_string, std::allocator >. In Go, you don't need all this... you just implement as many interfaces as you like and you're done.
So the Java and C++ programmers need time and an open mind to get up to speed. There's also another contingent of programmers that really just wants Go to be like their favorite strongly-typed functional programming language (Haskell, Scheme, SML, etc.) I like to think that these people will eventually give up. After all, nobody comes into every Lisp thread demanding that Lisp grow a type-checker. People have sort of accepted that that is not what Lisp is about and that there are other languages that will give you that if you want. Hopefully much the same will happen for Golang.
Re: Go by Example
#106It's Friday gents! No excuse to set aside Saturday and Sunday, you can easily go through these examples in two days and grok it. Go is that _slim_, and that's good! Guaranteed you'll find use for Go in one system or the other when you want easy deployment, fast development time and extreme speeds. :) (Disclaimer: I love Go and I hope it goes mainstream in a big way in 5 years)
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…
Hey, don't sell Python short!
vs.sort(key=len)Re: Go by Example
#107Earlier quoted context omitted.
I'm curious what programs people are writing where parametric polymorphism is so crucial. I've written hundreds of thousands of lines of Go code (servers, web apps, data processing, etc.), and there's probably been maybe O(hundreds) of lines of code that were annoying or tedious because of a lack of parametric polymorphism. My suspicion is that what's more likely is that lots of people don't want to consider writing…
"But maybe there's a whole class of problem (actual problem, not a sub-problem like "I want to implement a container") that I don't come in contact with." i want to apply a transformation to every element in a collection i want to select the elements from a collection for which some predicate holds true
Those are both sub-problems.
Re: Go by Example
#108It's about time! Go doesn't really have a good community or really practical examples. Glad to see someone took the time to put this together.
> Go doesn't really have a good community
What about freenode/#go-nuts? Seems like a very nice channel to me.
Re: Go by Example
#109Earlier quoted context omitted.
I'm curious what programs people are writing where parametric polymorphism is so crucial. I've written hundreds of thousands of lines of Go code (servers, web apps, data processing, etc.), and there's probably been maybe O(hundreds) of lines of code that were annoying or tedious because of a lack of parametric polymorphism. My suspicion is that what's more likely is that lots of people don't want to consider writing…
I think a big part of the issue is that in Java and C++, you really need generics a lot more than in Go. Without templates, you would not have any easy way of doing maps and lists in C++. There are no builtin types for those like in Go. The way the type system works in those languages also makes things very difficult if you don't have generics. Think about the sorting example I wrote earlier: https://news.ycombinator…
Java 8 will have interfaces with default implementations.
There are a few of optional type checkers for Lisp to choose from.
Re: Go by Example
#110Earlier quoted context omitted.
I'm curious what programs people are writing where parametric polymorphism is so crucial. I've written hundreds of thousands of lines of Go code (servers, web apps, data processing, etc.), and there's probably been maybe O(hundreds) of lines of code that were annoying or tedious because of a lack of parametric polymorphism. My suspicion is that what's more likely is that lots of people don't want to consider writing…
I think a big part of the issue is that in Java and C++, you really need generics a lot more than in Go. Without templates, you would not have any easy way of doing maps and lists in C++. There are no builtin types for those like in Go. The way the type system works in those languages also makes things very difficult if you don't have generics. Think about the sorting example I wrote earlier: https://news.ycombinator…
It is common in both C++ and Java for a class to implement several interfaces. So, one can accomplish the same kind of genericity in C++ and Java as one can in Go. Both languages still eventually saw enough of a need for a kind of generics to develop one.
There is a difference in Go, and that is you don't need to explicitly implement the interface. That is, you don't need to declare that you do. But I am unconvinced that is so different from implementing interfaces in C++ and Java that C++ and Java programmers "need time and an open mind" to understand Go idioms.
Don't get me wrong: I think Go is a neat language and culture. I like many aspects of it. And I know the stance the designers of Go have on generics: they would like to do them, but they can't think of a design that they like. And they don't consider it that important, so they've bunted on it. They may do them in the future. But I find it strange when people who are not the designers of the language argue against having them, in any form.