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

41–50 of 130 posts

Re: Go by Example

#41

Post by jamesaguilar »

Shamanmuni wrote: post #29
jamesaguilar wrote: post #22

Earlier quoted context omitted.

Same reason most posts about MongoDB for a long time had complaints about Mongo's uh . . . let's say "relaxed" . . . approach to durability. Because proponents of the language/system/idea tend to promote an unbalanced view of its quality, its detractors need to be there to give people on the fence the right dose of the bad medicine. Also, speaking only for myself, I really like the language and its ideas, but that on…

I tend to think that you and the rest of "Generics or death!" crowd make a disservice to your own cause when you lazily come and repeat the same arguments. The rest gets bored and frustrated. Yeah, we get it, you like generics, it makes sorting stuff easier, and you're repeating the same stuff over and over again for our own good because you are true altruists, etc. Can we get over that? If there's another thread whi…

I would surely never take these complaints to a go-specific discussion board. That would be disruptive and rude. But this site is not that. I will react to stories on here as pleases me, and it pleases me to constructively criticize certain go design choices sometimes when the subject comes up.

Re: Go by Example

#42

Post by dfrey »

bstamour wrote: post #31
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…

With C++14 this becomes sort(begin(vs), end(vs), [](auto const& l, auto const& r) { return l.size() Even simpler.

Why are "begin" and "end" functions now instead of methods on the iterator? Do they consider it better because now you can pass around functions, but not methods?

Re: Go by Example

#43

Post by masklinn »

dsymonds wrote: post #33
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…

A few extra lines for sorting means you won't touch Go with a pole? That's a bit extreme. Do you really do custom sorting so often that this is a major problem? 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.

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

No one is indeed, so that's an irrelevant strawman.

Re: Go by Example

#44

Post by frou_dh »

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?

You can't put methods on a type from a different package (or in this case a builtin type).

Instead of methods, you could of course write normal functions taking []string, but only methods can fulfil interfaces.

Re: Go by Example

#45

Post by jamesaguilar »

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?

This is the idiomatic way. It's actually the only way.

Re: Go by Example

#46

Post by masklinn »

bsg75 wrote: post #20
hdevalence wrote: post #16

Earlier quoted context omitted.

It was in response mainly to: > 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?

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?

Re: Go by Example

#47

Post by fauigerzigerk »

dfrey wrote: post #42
bstamour wrote: post #31

Earlier quoted context omitted.

With C++14 this becomes sort(begin(vs), end(vs), [](auto const& l, auto const& r) { return l.size() Even simpler.

Why are "begin" and "end" functions now instead of methods on the iterator? Do they consider it better because now you can pass around functions, but not methods?

Because it works with arrays.

Re: Go by Example

#48

Post by dmunoz »

bstamour wrote: post #31
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…

With C++14 this becomes sort(begin(vs), end(vs), [](auto const& l, auto const& r) { return l.size() Even simpler.

What are the C++14 parts here? I haven't been paying much attention to the C++14 standards shaking out.

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.

Re: Go by Example

#49

Post by Shamanmuni »

jamesaguilar wrote: post #41
Shamanmuni wrote: post #29

Earlier quoted context omitted.

I tend to think that you and the rest of "Generics or death!" crowd make a disservice to your own cause when you lazily come and repeat the same arguments. The rest gets bored and frustrated. Yeah, we get it, you like generics, it makes sorting stuff easier, and you're repeating the same stuff over and over again for our own good because you are true altruists, etc. Can we get over that? If there's another thread whi…

I would surely never take these complaints to a go-specific discussion board. That would be disruptive and rude. But this site is not that. I will react to stories on here as pleases me, and it pleases me to constructively criticize certain go design choices sometimes when the subject comes up.

You don't fool anybody, the subject didn't come up untill you brought it. The thread is about a site that shows examples of Go code and explains them, there's no discussion about the advantages or disadvantages of their design decisions, just matter of fact statements.

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.

Re: Go by Example

#50

Post by ckarmann »

dmunoz wrote: post #48
bstamour wrote: post #31

Earlier quoted context omitted.

With C++14 this becomes sort(begin(vs), end(vs), [](auto const& l, auto const& r) { return l.size() Even simpler.

What are the C++14 parts here? I haven't been paying much attention to the C++14 standards shaking out. 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 origina…

> I see auto being used inside the lambda. Was that not allowed in C++11?

It wasn't:

http://stackoverflow.com/a/7709970/39622

Post reply on HN