Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Stages of learning Go, with code examples

sourcegraph.com

Post reply on HN
Print view View original

51–60 of 118 posts

Re: Stages of learning Go, with code examples

#51

Post by coldtea »

Where does this idiotic idea cames from that being "idiomatic" is some kind of virtue?

Idiomatic Java was the FactoryProxySingleton EE-wank fest from Apache, SUN, Spring and co.

It was by changing those idioms around (e.g. how the Play framework wrote Java), that saner alternatives emerged.

The de-facto idiom of PHP before 2010 was messy code.

It started getting more coherent after that, but the preffered idiom now (e.g. for Zend, Synmphony, Laravel) is still a tedious, verbose, copy of the Java circa 2006 style (large class hierarchies, singletons, "Facades", DI, etc).

Idiomatic JS pre-Cockford was ad-hoc BS. After Cockford it got a lot better, but then it changed again (can't say for the worse) with all sort of functional tricks and patterns that weren't in vogue before.

In all of those cases, if they have stuck to the same "idiomatic" way from the start, it would have been worse.

Within a single project, sure, enforce some idiomatic way of doing things.

But within a whole language people should be able to experiment and not be called upon for being "unidiomatic" all the time. This is exceptially disturbing and often in Go, where there's some cargo cult in many advocates that they have found the be-all end-all way to code.

It seems to me this push for "idiomatic" is also related to the Blub paradox. Blub programmers know a couple of ways of doing things (the "idioms" of their language) and cannot understand why someone might want to program with higher (or just different but convenient) concepts he learned in another language.

Re: Stages of learning Go, with code examples

#52

Post by erikb »

bonn1 wrote: post #5

Just wondering, does Go finally has a package manager with proper versioning of modules? Edit: Somebody is heavily downvoting me on every reply, I would love to know why. I like Go and want to get into it since a few months but the missing package manager held me off. So what is wrong about my question?

As far as I know the system is different. You pull your requirements from repos recursively. It's maybe slower but in exchange it's more lightweight. For most cases it shouldn't be a kill reason. So what's the problem with that?

PS: I'm no go developer either. But the way it pulls in requirements was a nice idea in my eyes.

Re: Stages of learning Go, with code examples

#53

Post by cicero »

Animats wrote: post #2

It's a tool, not a religion. Don't try to turn it into a cult.

It's natural to get excited when you find a tool that fits you well and solves problems you had encountered with other tools. People are different, as are their needs, and so one person's excitement over a tool might not make sense to others. If you don't get someone else's enthusiasm, that is nothing to be afraid of.

Re: Stages of learning Go, with code examples

#54

Post by kingmanaz »

runeb wrote: post #24

Can someone recommend some good books on Go?

Summerfield's "Programming in Go" is several years old but still the best I've come across. Below is a review regurgitated from Barnes and Noble if you're interested:

...The author spends his time away from the libraries, covering the core of the language. By the nature of this approach the matter is dense, but it also gives the author ample time to discuss best practices, for instance:

"...[i]ncidentally it is a Go convention that functions that have channel parameters have the destination channels first, followed by the source channels [in the function definition]..."

Many of these best practices stem from conventions found in Go's own source code, which happily, the author is well acquainted with. Learning a language by isolating its syntax and analysing idioms and conventions is effective for those willing to persevere, and "Programming in Go" abounds in such detail.

Ideally, "Programming in Go" should be paired with a textbook which focuses on use-cases. Balbaert's "The Way to Go" is such a book, but sadly, is not nearly so well written as Summerfield's. In any case, "Programming in Go" is the book for those searching for a solid understanding of Go's fundamentals.

Re: Stages of learning Go, with code examples

#55

Post by cjslep »

copsarebastards wrote: post #43
cjslep wrote: post #26

Earlier quoted context omitted.

> presumably copy/pasted for every option To be fair, there is "go generate" now that can generate functions that would otherwise require tedious copy/pasting. If you are familiar with the preprocessor in C++ expanding template definitions, this tool can provide similar functionality but is more generalized. I think embedding [0] is the real big composability win in Go. [0] https://golang.org/doc/effective_go.html#em…

> To be fair, there is "go generate" now that can generate functions that would otherwise require tedious copy/pasting. If you are familiar with the preprocessor in C++ expanding template definitions, this tool can provide similar functionality but is more generalized. Comparing to C++ templates is a rather generous comparison. C++ templates provide a rich type system that allows type checking and prevents errors, an…

I agree, it is a generous comparison, which is why I only compared "go generate" to expanding template definitions (albeit, in hindsight, even that is generous). Macro expansion is definitely a better comparison. In no way did I mean to insinuate "go generate" is on par or better than C++ templating language features.

Edited for clarity.

Re: Stages of learning Go, with code examples

#56

Post by SEJeff »

bonn1 wrote: post #5

Just wondering, does Go finally has a package manager with proper versioning of modules? Edit: Somebody is heavily downvoting me on every reply, I would love to know why. I like Go and want to get into it since a few months but the missing package manager held me off. So what is wrong about my question?

Your questions was serious and not a troll, so I upvoted it. It seems like vendoring really is the "accepted upstream method" for solving this problem.

Even the Fedora packagers for golang apps are asking to relax the requirement on unbundling vendored things for golang as there is no sane way to handle versions other than git commit hashes.

Re: Stages of learning Go, with code examples

#57

Post by rdtsc »

cjslep wrote: post #26
moe wrote: post #25

Earlier quoted context omitted.

There is countless proof about Go's composability through functions and interface I can't tell if you're serious or sarcastic yourself. The article proposes this snippet, presumably copy/pasted for every option: // Verbosity sets Foo's verbosity level to v. func Verbosity(v int) option { return func(f *Foo) option { previous := f.verbosity f.verbosity = v return Verbosity(previous) } } If that's what Go composability…

> presumably copy/pasted for every option To be fair, there is "go generate" now that can generate functions that would otherwise require tedious copy/pasting. If you are familiar with the preprocessor in C++ expanding template definitions, this tool can provide similar functionality but is more generalized. I think embedding [0] is the real big composability win in Go. [0] https://golang.org/doc/effective_go.html#em…

> "go generate"

AKA macros.

I wish they were at least intellectually honest and just call them "macros" and start nice supporting hygienic macros in the language.

Re: Stages of learning Go, with code examples

#58

Post by orkoden »

NateDad wrote: post #21
bonn1 wrote: post #5

Just wondering, does Go finally has a package manager with proper versioning of modules? Edit: Somebody is heavily downvoting me on every reply, I would love to know why. I like Go and want to get into it since a few months but the missing package manager held me off. So what is wrong about my question?

You really don't need a package manager for Go. Honestly, the main reason you need them for node, python, etc is because you're deploying source code to your production environment. You don't do that with Go. You deploy a binary, which has everything wrapped up in itself. Think of it as a self-contained virtualenv that requires zero effort on your part :) In Go, code is packaged via source control repos. If you want…

An example for a dependency management package manager for a compiled language is [cocoa pods](http://cocoapods.org) for Objective-C. It's really popular with iOS and OS X developers.

Or look at [cabal](https://www.haskell.org/cabal/) for Haskell. It's a package manager that doubles as build system.

It helps when you use external open source projects and want to update it to a new version. With go you have to keep track of you external dependencies and their versions on your own.

Re: Stages of learning Go, with code examples

#59

Post by tveita »

jerf wrote: post #44
eddieroger wrote: post #28

Earlier quoted context omitted.

I'm on board with this answer, and it makes sense to me, but it's competing in my head with the idea of always being able to do a clean build from master that could deploy whenever. Let's say you have a catastrophic failure and lose your binary repo and need to rebuild (and your backups, etc - it's an example) - if your dependencies have changed in the meanwhile, you can't redeploy to where you were. Obviously that s…

"but that doesn't feel like a legitimate excuse to not have some safeguard in place to make sure your build environment doesn't change on you." If your build process downloads anything from the Internet, your build environment can change on you. Networks can always fail. At best you can detect this occurring and have your build process scream and die, but it can't be fixed. Note the complete lack of the word "Go" in…

Since I can fairly reliably type "mvn compile" to build five year old Java projects, I think it's fair to say that the Go community is in a dependency hell of their own making.

Should every library author vendor their dependencies separately too?

Re: Stages of learning Go, with code examples

#60

Post by jerf »

tveita wrote: post #59
jerf wrote: post #44

Earlier quoted context omitted.

"but that doesn't feel like a legitimate excuse to not have some safeguard in place to make sure your build environment doesn't change on you." If your build process downloads anything from the Internet, your build environment can change on you. Networks can always fail. At best you can detect this occurring and have your build process scream and die, but it can't be fixed. Note the complete lack of the word "Go" in…

Since I can fairly reliably type "mvn compile" to build five year old Java projects, I think it's fair to say that the Go community is in a dependency hell of their own making. Should every library author vendor their dependencies separately too?

I'm not in a dependency hell. I won't be if I add libraries, either, because there are tools for that.

"Should every library author vendor their dependencies separately too?"

Whatever it takes to produce your end-artifact should be under the control of the relevant organization. Again, let me emphasize, this has nothing to do with Go, and you violate it at your sole and singular peril. When the $PACKAGE site goes down due to DOS, security penetration, or sheer time-based neglect, being angry at me won't help you any.

Post reply on HN