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

61–70 of 118 posts

Re: Stages of learning Go, with code examples

#61

Post by disputin »

coldtea wrote: post #51

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

The lower the standard of your team, the more you will appreciate idiomatic code. I don't work in SV, blue chips, or anywhere that could use Scala. A couple of us at my last place had a hard time moving the team from Source Safe to SVN, Git was out of the question. "What's the point of commit messages if you only commit every three months?" - not kidding, not a junior. Lines thousands of characters long, literally. I saw a pattern once. Once. CIO was one of these copy/paste VB devs, common in London, an unfair generalisation, but necessary as a warning sign. Some people become developers without any interest in development, completely oblivious to *nix/open source world, simply as a job, 9 - 5, and might have flipped a coin between development and accountancy. Some places don't give a shit about software development, or the idea of engineering - "just get it done!". Resharper, fxcop? Yeah, right. Degrees don't all teach compiler design, some just Java OO and a bit of Glassfish. If Go replaced C# in all of these arbitrary SMEs there would be far fewer WTFs. But people would struggle without Visual Studio debugging and a big run button. I'm being harsh, and seriously, not suggesting anything about MS devs, who include the world's best as well as the world's worst, but I find people on this site are often, to their fortune, oblivious to what working in the 99% can be like (the figurative 99%). Long live idioms, gofmt, golint.

Re: Stages of learning Go, with code examples

#62

Post by masklinn »

skj wrote: post #34
zak_mc_kracken wrote: post #31

Earlier quoted context omitted.

The absence of generics makes it so that Go's composability is through copy/pasting your code while changing the types. There's even a tool to do the copy/pasting for you. Technically, it's composability, just not the best kind.

Generics and composability are orthogonal concepts, to me. I'm not really sure what sort of composability you're talking about. Can you provide an example for me to rip apart?

Anything to do with higher-order functions, least of all

    compose :: (b -> c) -> (a -> b) -> a -> c

?

Re: Stages of learning Go, with code examples

#63

Post by tptacek »

copsarebastards wrote: post #41
NateDad wrote: post #21

Earlier quoted context omitted.

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…

> You really don't need a package manager for Go. "You really don't need X for Go" is becoming the Go community catchphrase. And they're right: I won't need anything for Go because I wouldn't use a language whose community actively resists improvement. I could respect that Go doesn't have a package manager, generics, etc., if the Go community took more of a "if you want it, develop it" approach. But instead, the core…

"You really don't need X for Go" is becoming the Go community catchphrase. And they're right: I won't need anything for Go because I wouldn't use a language whose community actively resists improvement.

There's no language you couldn't construct a similar argument for, is there? Except maybe Perl. There's always going to be some capability favored by some loud person who's going to publicly disqualify some language for not having that feature.

Weird that in this case it's an equivalent of npm or Rubygems, which are nice tools for beginners but a complete pain in the ass for serious projects; essentially, you're disqualifying Golang for not reinventing DLL Hell like everyone else.

Generics, I get. Package management?

Re: Stages of learning Go, with code examples

#64

Post by StevePerkins »

ansible wrote: post #14
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?

We prefer to use version control, and vendor libraries in our project instead. This is language-agnostic, and allows us to have repeatable builds without extra tools. I've written up a tutorial about it using git-subtree: https://github.com/jamesgraves/example-go-app

Does this not wholly preclude the possibility of vendors shipping a library without source?

Re: Stages of learning Go, with code examples

#66

Post by omaranto »

DanWaterworth wrote: post #33
1_player wrote: post #17

Earlier quoted context omitted.

You probably were sarcastic, but in case you are not there's a brilliant article from Rob Pike about using and composing functions to create flexible APIs: http://commandcenter.blogspot.co.uk/2014/01/self-referential... There is countless proof about Go's composability through functions and interface, but I keep coming back to that one document.

> You probably were sarcastic I don't know that sarcastic is the correct word, but I certainly wasn't completely serious. Maybe "playfully antagonistic". I suppose the problem I have here is, if I was designing a language, and composability was a stated goal, then I wouldn't have come up with Go. > a brilliant article from Rob Pike about using and composing functions to create flexible APIs I'm sorry, but that API is…

> I'm sorry, but that API is not something to be proud of.

I agree: not only does using it require a lot of boilerplate, but Option takes several arguments and returns a value that only restores the previous value of the last option! That sounds very error prone, I'm sure someone will think the value return by Option undoes all of the option setting.

Re: Stages of learning Go, with code examples

#67

Post by aikah »

jerf wrote: post #60
tveita wrote: post #59

Earlier quoted context omitted.

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

What you may not get is that you're likely doing manually what a package manager does automatically. A program should do the work,not the programmer. Imagine there is a bug in the current package.Well a package manager can invite you to download a recent version of the lib that has no breaking changes automatically just with a few metadatas. Why would you not want to automate that kind of stuff?

Re: Stages of learning Go, with code examples

#68

Post by pashields »

coldtea wrote: post #51

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

Idiomatic means "using expressions that are natural to a native speaker." It's very possible, but not idiomatic, to write functional Java (pre-8). It's often more verbose and difficult to follow because there is no real notion of higher level functions or composition, let alone immutable data structures. The guava wiki has a good example of this: https://code.google.com/p/guava-libraries/wiki/FunctionalExp....

That doesn't mean that idiomatic practices are always virtuous, but non-idiomatic code is only virtuous because it overcomes an inherent mismatch between what the user wants and what the language provides. With many languages (certainly js, java, c++) we see non-idiomatic practices guide changes to the language and then be replaced. Java gained functions to avoid the abuse of anonymous inner classes. ES6 is stealing from transpiled javascript languages left and right.

Making idiomatic code virtuous is the goal of creators and maintainers. Writing idiomatic code means that you have chosen languages, frameworks, and libraries that are closely aligned with the code you need to write and the style you want to write it in.

Re: Stages of learning Go, with code examples

#69

Post by Skunkleton »

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?

I don't have a ton of experience with go, just some one off internal tools development, only a few dependencies. That said, I chose to manage my dependencies manually by making a fork of the relevant repositories. Yeah, it would have been nice if the higher order dependencies were automatically resolved, but the whole thing went smoothly, and felt familiar since it had nothing to do with Go at all. Maybe the take away is that a language agnostic dependency manager is what would best benefit Go?

Re: Stages of learning Go, with code examples

#70

Post by politician »

What do GOPATH, the project folder structure, package management, and package versioning all have in common? The go command. Not the linker, not the compiler -- the `make` replacement.

If you want to fix the most broken parts of Go -- its ecosystem management tooling -- just replace your `go` command.

I have, and I love working on a project with a proper top-level src folder, with vendor-able packages discoverable in a top-level lib folder pinned to known-good commits.

There are literally dozens of go replacements, but the winning combination for me is using Goop [1], Makefiles, and symlinks to subvert `go get` and the naive way it parses import declarations [2].

[1] https://github.com/nitrous-io/goop

[2] https://golang.org/ref/spec#Import_declarations

Post reply on HN