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

91–100 of 130 posts

Re: Go by Example

#91

Post by colin_mccabe »

hdevalence wrote: post #9
sergiotapia wrote: post #3

It'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)

Are there any plans to add generics yet, or do I still have to write a bunch of extra boilerplate functions in order to sort a list?

Hi hdevlance,

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.

Re: Go by Example

#92

Post by hdevalence »

colin_mccabe wrote: post #91
hdevalence wrote: post #9

Earlier quoted context omitted.

Are there any plans to add generics yet, or do I still have to write a bunch of extra boilerplate functions in order to sort a list?

Hi hdevlance, 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 wou…

If you say so -- I'm just going off of the examples given in the Go documentation on how to sort lists. If that's not the "Go-ic" way to do it, perhaps the documentation should be updated. If it is the "Go-ic" way to do it, then I think that my point still holds.

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.

Re: Go by Example

#93

Post by colin_mccabe »

hdevalence wrote: post #92
colin_mccabe wrote: post #91

Earlier quoted context omitted.

Hi hdevlance, 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 wou…

If you say so -- I'm just going off of the examples given in the Go documentation on how to sort lists. If that's not the "Go-ic" way to do it, perhaps the documentation should be updated. If it is the "Go-ic" way to do it, then I think that my point still holds. 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…

The example we were discussing was written by Mark McGranaghan, and is not part of the go documentation per se. I think it's a nice little tutorial, but please don't confuse it with "the Go documentation."

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.

Re: Go by Example

#94

Post by binarycrusader »

sergiotapia wrote: post #3

It'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)

I've learned enough 'Go' to write a small 3D framework in OpenGL, and after doing so, I have no desire to go back for most of my projects.

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

Re: Go by Example

#95

Post by TylerE »

binarycrusader wrote: post #94
sergiotapia wrote: post #3

It'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)

I've learned enough 'Go' to write a small 3D framework in OpenGL, and after doing so, I have no desire to go back for most of my projects. 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 be…

You might like nimrod. Similar performance characteristics (or better) than Go, with Generics and meta-programming. Library situation is a little iffy, but there are full SDL and OpenGL bindings.

Re: Go by Example

#96

Post by joewalnes »

sergiotapia wrote: post #3

It'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)

Agreed. I've been programming Go for a while, and yet I still find this site invaluable. Because I context switch between many languages, I forget syntax a lot. Hmmmm... maybe I'm just getting old. Anyway, I find it much quicker to get the answer I need by looking at GoByExample, than by browsing the Go docs. Kudos to this site.

It helped me build this: https://github.com/joewalnes/websocketd/

Re: Go by Example

#97

Post by pcwalton »

fauigerzigerk wrote: post #59
pcwalton wrote: post #37

Earlier quoted context omitted.

Not having generics reduces explicitness (because you don't specify the types of your containers) and reduces safety (because of all the casts and manual implementations of things like swap functions).

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.

Re: Go by Example

#98

Post by earthboundkid »

dvirsky wrote: post #78
0xdeadbeefbabe wrote: post #54

Earlier quoted context omitted.

If only there were a workaround for not having generics, sigh. But seriously, they may not implement generics out of spite or just to troll generics zealots. Edit: remove ambiguity

I recently added the statement "type T interface{}" to a piece of code, as a private joke about the generics-in-go talk. now my code looks like "func map(x []T, f func(T) T)" and everybody's happy :)

I firmly believe that when Go introduces generics, the syntax should look like:

type T1 generic type T2 generic

func Map(f func(T1) T2, s []T1) []T2

Re: Go by Example

#99

Post by hdevalence »

colin_mccabe wrote: post #93
hdevalence wrote: post #92

Earlier quoted context omitted.

If you say so -- I'm just going off of the examples given in the Go documentation on how to sort lists. If that's not the "Go-ic" way to do it, perhaps the documentation should be updated. If it is the "Go-ic" way to do it, then I think that my point still holds. 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…

The example we were discussing was written by Mark McGranaghan, and is not part of the go documentation per se. I think it's a nice little tutorial, but please don't confuse it with "the Go documentation." 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 w…

Actually, the example I was referring to (see my comment elsewhere in the thread) is copied directly from the Go documentation here: http://golang.org/pkg/sort/

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.

Re: Go by Example

#100

Post by dsymonds »

masklinn wrote: post #86
dsymonds wrote: post #68

Earlier quoted context omitted.

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.

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

Post reply on HN