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

51–60 of 130 posts

Re: Go by Example

#51

Post by jamra »

jamesaguilar wrote: post #21
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)

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…

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.

Re: Go by Example

#52

Post by sehr »

jamesaguilar wrote: post #35
sehr wrote: post #28

Earlier quoted context omitted.

Never underestimate the power of nitpicking in an HN thread.

It is amusing that you consider either generics or durability to be "nitpicks." One is a feature that is present in almost every static language of at least the last two decades, and another is a fundamental need of most database users, relational or not. Unless by nitpick you mean, "something I personally don't care about," I think your nitpick-classifier is a bit busted.

I don't consider the features (or lack thereof) to be nitpicks. They are valid criticisms, but they have had their own very extensive discussions, and we are all very aware of them.

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

Re: Go by Example

#53

Post by dmunoz »

ckarmann wrote: post #50
dmunoz wrote: post #48

Earlier quoted context omitted.

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

Thanks for the reply. A comment under the accepted answer points to the wikipedia article on C++14, which has information on the new language and new standard library features [0]. I should have thought to check there first.

[0] https://en.wikipedia.org/wiki/C%2B%2B14

Re: Go by Example

#54

Post by 0xdeadbeefbabe »

Shamanmuni wrote: post #49
jamesaguilar wrote: post #41

Earlier quoted context omitted.

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 generi…

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

Re: Go by Example

#55

Post by ckarmann »

hdevalence wrote: post #16
bsg75 wrote: post #14

Earlier quoted context omitted.

What does yet another gripe about generics in Go have to do with a tutorial written by an independent party, one that is about features in the language today ?

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?

Learning languages for their new ideas is fine, but there are other reasons you might want to learn a language. For example, because it is a good language for the specific kind of program that you want to write.

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?

Re: Go by Example

#56

Post by jamesaguilar »

sehr wrote: post #52
jamesaguilar wrote: post #35

Earlier quoted context omitted.

It is amusing that you consider either generics or durability to be "nitpicks." One is a feature that is present in almost every static language of at least the last two decades, and another is a fundamental need of most database users, relational or not. Unless by nitpick you mean, "something I personally don't care about," I think your nitpick-classifier is a bit busted.

I don't consider the features (or lack thereof) to be nitpicks. They are valid criticisms, but they have had their own very extensive discussions, and we are all very aware of them. 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).

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.

Re: Go by Example

#57

Post by bstamour »

fauigerzigerk wrote: post #47
dfrey wrote: post #42

Earlier quoted context omitted.

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.

More than that, actually. Because of argument dependent lookup, this will work for any container that has begin and end functions in the same namespace.

Re: Go by Example

#58

Post by bstamour »

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 omitted the return type (which is allowed for lambdas in C++11, and now arbitrary functions (with some conditions) in C++14) because it was a 1-liner. The bool return type can be deduced by the compiler automatically (or else it would fail to compile) and by the human by the operator < in use, the fact that it's being passed to sort, etc.

Re: Go by Example

#59

Post by fauigerzigerk »

pcwalton wrote: post #37
sergiotapia wrote: post #10

Earlier quoted context omitted.

That's something for the Go creators to decide, but personally I enjoy the feeling of safety that comes with lack of generics. I have very few Go bugs at runtime and I think that explicitness plays a huge part in it.

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

Re: Go by Example

#60

Post by stokes3452 »

tokenizerrr wrote: post #6

This documentation is great, but one thing I tend to miss with examples like these is how to structure a project, deal with packages, etc.

Agreed, the community does seem pretty loose on project structure--which is interesting since the language takes such strong stances on code structure.

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]: https://github.com/forcedotcom/rmux

Post reply on HN