Go by Example
gobyexample.com
gobyexample.com
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)
func (a ByAge) Len() int { return len(a) }
func (a ByAge) Swap(i, j int) { a[i], a[j] = a[j], a[i] }
func (a ByAge) Less(i, j int) bool { return a[i].Age < a[j].Age }
And not having generics means that (as far as I can tell) people end up using a lot of `interface{}`. How does that increase safety?
More importantly, why would I want to use a language whose solution to the problem of "dealing with generic data" essentially boils down to "use a void*"?
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 will use each one of them.
Unfortuntately I'm not as smart. Even after more than 20 years of using C++ I sometimes fail to anticipate which function the compiler decides to use. And that is not safe.
In fact it is less safe than casting interface{}, because that will at least fail fast at runtime instead of silently doing something unexpected.
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.
> Go is that _slim_, and that's good! Guaranteed you'll find use for Go in one system or the other...
I'm all for learning new programming languages, but if you're going to learn a new programming language, why not use one that has new ideas?
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 the features of those, and probably should not.
But it seems impossible to have a HN discussion on Golang without part of the thread getting hijacked with "But generics!!!" This make no more sense to me than considering other languages incomplete because they don't generate static binaries.
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?
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"?
Go hits some sweet spot, apparently, since some people are happier using it than anything else they had tried. If no "new ideas" are going to help them, why should they chose more "innovative" languages instead of Go?
Also, speaking only for myself, I really like the language and its ideas, but that one thing it's missing makes it too annoying to write code in it. I'd like to see more people aware of this deficiency and putting pressure on the language's owners to fix that problem, so that I can start using it.
Bringing that into a thread regarding a very cool set of examples regarding the core features of the language, isn't very constructive (at least IMO).
If there's another thread which talks about good and bad points of the Golang design then, by all means, bash the language as much as you like. But if there's something you don't like it doesn't mean you get a free pass to repeat yourself whenever something with Go in the title appears in HN, whatever it is. Context matters, you aren't helping anybody, just trolling.
Of course, you can do whatever you want, but that doesn't mean that the rest of us won't probably look at your comments thinking "Here come the generics whiners again" and look in the other direction. You are alienating your audience with your indiscriminate repetition.
And, if the disclaimer helps you, I'd like generics in Go, they are useful sometimes. I just don't see the point in such zealotry over something which is merely convenient.
But seriously, they may not implement generics out of spite or just to troll generics zealots.
Edit: remove ambiguity
now my code looks like "func map(x []T, f func(T) T)" and everybody's happy :)
type T1 generic type T2 generic
func Map(f func(T1) T2, s []T1) []T2
I can see that I am putting some people off with my commentary, but other people apparently got new information. Hard to say whether this is a win or loss on net. Time will tell, sooner or later.
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 many complainers are going to rival his résumé?
Generics actually have very little to do with sorting a list in Go. The example that the parent gave could be expressed in one line as "sort.Sort(sort.Reverse(sort.StringSlice(vs)));" No generics needed-- only composition. sort.Reverse is a wrapper interface which can be composed with any other sort.Interface to reverse it. It is typesafe, too-- there are no typecasts.
There are cases where generics would allow us to avoid typecasts, but this is simply not one of them. In many cases, what you want can be expressed via composition of types, and often (in my opinion) in a clearer way than by using lambdas, continuations, and callbacks. I suggest learning a bit more about the language and keeping an open mind.
I also don't really have a lot of excitement about the prospect of solving problems by composing types in Go. For instance, to the best of my knowledge, Go does not have language support for sum types. It's not that I'd rather use continuations or callbacks -- I like powerful, expressive type systems to do, e.g., static enforcement of contracts -- it's just that I think that Go's type system isn't very expressive.
You're right, perhaps I'm totally misinformed about the language, and that lurking below there really is a way to do clear and clean things with types in Go. But everything I've seen points in the opposite direction, so at this point, though I have an open mind, I'd need more evidence to change my view.
Mark's point was that you can create an arbitrary wrapper type around another interface, so that the behaviors are composed. This is the most flexible way to do things. If there's already a wrapper type that does what you want, however, then you can simply use that. They are both examples of composition, and both "the Go-ic way to do it."
Composition is often overlooked by people who are fixated on other ways of doing things, like inheritance or generics. But in many ways, it's cleaner, since composition allows you to link together many modules without peeking inside.
It's funny that people have accepted the reality of dynamic languages, but can't seem to "get" the idea of statically typed language without generics. There isn't a troll comment in every Python article that it would be better with static typing. Type systems are a little bit like body armor-- development can be slower, but in exchanged you get a little more confidence in the program. People have accepted the idea of going naked, and the idea of medieval-style full plate armor, but the idea that you might want some type safety, but not go overboard often seems to fall on deaf ears.
Composition is great. It does not solve the same problem as generics. The reason people can't seem to "get" the idea of statically typed languages without generics is because static typing without parametric polymorphism is a painful experience.
I'm not opposed to the idea of finding some balance between static and dynamic typing -- Clojure type annotations seem interesting -- it's just that I don't like the way Go does it.
In a few other languages:
// C++
sort(vs.begin(), vs.end(),
[](const string& l, const string& r) -> bool {
return l.size() < r.size();
});
# Python
vs.sort(key=lambda s: len(s))
sort(begin(vs), end(vs),
[](auto const& l, auto const& r) {
return l.size() < r.size();
});
dfrey already asked about why begin/end are functions now.
I see auto being used inside the lambda. Was that not allowed in C++11? I got sucked into the "use auto everywhere" mantra, so I just imagined it was possible, but could easily see if it were not. That is probably the biggest decrease in size to the original code posted.
I see return type inference. That is one thing I have heard about being new in C++14. To be honest, I would rather see the explicit return type there. Inference is always nice, though.
It wasn't:
There's plenty of other ways in which Go is shorter than the equivalent C++ (e.g. with type inference, or channel operations), but no-one's trying to claim that the shortest code wins.
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 code wins.
No one is indeed, so that's an irrelevant strawman.
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, but is it really sufficiently horrible to warrant that?
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.
My suspicion is that what's more likely is that lots of people don't want to consider writing their programs a little differently, and see that writing code with parametric polymorphism is the only acceptable solution to their problem. 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
I don't think generics are an imperative/functional thing so much as an important feature of any statically typed system.
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<char, std::char_traits<char>, std::allocator<char> >. 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.
There are a few of optional type checkers for Lisp to choose from.
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.
Actually, that's not a band-aid. It allows strings to be generic over allocators without suffering the performance penalty of a virtual call on every malloc and free. Go's solution would be to just take the penalty of a virtual call (as interfaces require virtual calls everywhere) and try to make it up with devirtualization optimizations and/or inlining.
> After all, nobody comes into every Lisp thread demanding that Lisp grow a type-checker.
That's because making a workable type system for Lisp is a very hard problem. By contrast, generics are well known at this point.
However, compile-time polymorphism is a mixed bag because of how it tends to blow out the icache by generating many copies of similar code. Java does away with it completely, and nobody seems to be protesting. The Linux kernel is written in C, and nobody seems to be protesting that the lack of compile-time polymorphism makes his/her job impossible. Clearly, the decision as to whether to include compile-time polymorphism in a language is something reasonable people can disagree about.
With regard to a type system for Lisp: it's been done before. Check out Qi.
The most common simple example is reasoning about the following pair of functions
f :: a -> a g :: Int -> Int
g a = 3
f a = a g a = a * 2
g a = if (a == 0) then 1 else a * g (a - 1)
---
So we can take it up a notch. Consider Functors in Haskell. In order to avoid the full generality, let's just say Functor is the container interface and types like [], Set, and Map instantiate it. This gives them the function
fmap :: (a -> b) -> f a -> f b
fmap :: (a -> b) -> [a] -> [b]
fmap :: (a -> b) -> Set a -> Set b
fmap :: (a -> b) -> Map k a -> Map k b -- for some key type k
Furthermore, since every mention of `a` vanishes in the result of the function we know that each value in the input container must either be transformed by the input function or dropped.
-- a specific example, not a general function
fmap f [a, b, c] = [f a, f b, f b]
notFmap :: (Int -> Char) -> [Int] -> [Char]
notFmap f [n1, n2, n3] = [f (n1 + 2), head (show n2), chr n3] ++ "hello world!"
fmap g (fmap f x) == fmap (g . f) x
fmap id x == id x
fmap f [] = []
fmap f (x:xs) = f x : fmap f xs
The take away is that while you can definitely write something that "maps over containers" without using parametric polymorphism, you have a harder time taking advantage of parametricity to have the types provide guarantees about the safe behavior of functions. Types (and in particular type inference) can sometimes make things more expressive, but their primary power lies in making things easier to understand and reason about.
func<T> id(t T) T {
switch t := T.(type) {
case int: return t + 1;
default: return t;
}
}
[1]: http://how-bazaar.blogspot.co.nz/2013/07/stunned-by-go.html
what :: Typeable a => a -> a
what :: (a -> TypeRep) -> a -> a
Suffice to say that the degree of guarantee breaking that this kind of code invites makes Typeable a very specialized library that's almost never recommended without a "unless you really know what you're doing" kind of warning.
I'm not sure why you bring this up - nearly every language that enables reflection lets you do this, including Haskell[0].
No decidable static type system can ensure correct semantics for all use cases, including even badly written code[1].
[0] And you don't even need reflection to do this, per se; it just makes it more convenient.
[1] One could design a static type system that did, but it would be undecidable.
You can always get around things, but languages that make a strong commitment to keeping reasoning as a priority are qualitatively different from those that do not.
fmap _ _ = []
In fact, it is one of the fundamental cornerstones of internal DSLs
perhaps odd, because i come from a crappily-typed PHP background. but if PHP teaches you anything, it's that you can accomplish just about anything with arrays (maps/slices).
Can any "idiomatic" Go programmers here give a better example of how you would do this?
Instead of methods, you could of course write normal functions taking []string, but only methods can fulfil interfaces.
Sure.
sort.Sort(sort.Reverse(sort.StringSlice(vs)));
type StringSliceByLength struct {
sort.StringSlice;
}
func (s StringSliceByLength) LessThan(i, j int) bool {
return len(s.StringSlice[i]) < len(s.StringSlice[j]);
}
Sort.sort(StringSliceByLength(vs))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?
// 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 < b.Year },
sorted := QuickSort(less, albums).([]Album)
vs.sort(key=len) L.sort(key=len)Turbo Pascal 5.5 was compiling 34,000 lines/minute in 1989 in MS-DOS systems!
http://edn.embarcadero.com/article/20803
Compared with module based languages, C and C++ toolchains have been always slower.
Making go-routines map to OS-level threads is a pain. And as much as I hate to trot out this old chestnut, the lack of generics is also a real pain.
I've gotten too used to having generic containers to go back, and the various hacks available just aren't worth it.
I still can't believe Go doesn't have some of the "basic" data types that older languages do such as Python's set() objects and the various operators.
That said, if was writing a small command-line utility for text manipulation or something else similar in scale that doesn't involve dealing with POSIX threading, I'd probably use it instead of Python, C, or C++.
> Library situation is a little iffy. Libraries are hardly iffy. Any C code be called, and most c++ code can be called very, very easily and with little boilerplate. The standard library has a huge pure section, and for almost everything else it has dozens of bindings to C libs. And there are plenty of existing libraries in the babel library manager, such as SFML.
It helped me build this: https://github.com/joewalnes/websocketd/
Here is a search for Go repositories with > 100 stars.[1] Every project will look different (the really big ones might be more complex then you need) but as you get deeper into the results you can find some great stuff.
[1]: https://github.com/search?l=go&q=stars%3A%3E100&s=stars&type...
- Eggs should not be washed.
Since your folder structure is also your package structure, with rmux[1] I tried to separate the project into dependencies, and use a package for each one. I like to also limit files to one class--but if you read through the default package files, the creators seems to go both ways.
One interesting thing that isn't mentioned often is how to handle the equivalent of #ifdef, through +build flags. This isn't the best solution, since all functions and their arguments are evaluated (even empty functions), but it does allow for the use of constants to wrap around cpu-wasteful debug-only areas/
[1]: http://fitzgen.github.io/pocco/ [2]: http://jashkenas.github.io/docco/
What about freenode/#go-nuts? Seems like a very nice channel to me.
- Eggs should not be washed.