Live data from Hacker News

Stages of learning Go, with code examples

sourcegraph.com

91–100 of 118 posts

Re: Stages of learning Go, with code examples

#91
post #46

Earlier quoted context omitted.

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

The community does not resist improvement. The community asks that you acquire some experience, work with what is there, make sure that you understand it, then suggest improvements. The community definitely does resist people who aren't even users loudly declaring exactly what it is that Go needs. I fear the community may have instinctively built up certain callouses that I'm not a big fan of, such as the near inabil…

> The community asks that you acquire some experience, work with what is there, make sure that you understand it, then suggest improvements.

So what is it that you think people who want Go to have generics don't understand? You say that people should acquire some experience before criticizing Go, but you're only accepting a certain kind of experience. I've written tens of thousands of lines of code in similar languages without generics, and tens of thousands of lines of code in similar languages with generics, and there is no question which I would rather write. I have written a number of compilers and am well aware of the concerns and how to implement a performant compiler. Why is that experience not something you value?

You're basically creating a chicken and egg problem: people who like Go will use it, and people who don't like Go won't, and what you're saying is that the latter won't be allowed to criticize Go. But people who don't like Go are the only ones who are going to ever criticize Go. And criticism is what anything needs to not suck.

Don't talk to me about "acquiring experience" as an excuse to discard any experience that comes from outside your community. My core complaint about Go: the authors simply have ignored decades of compiler research. By deciding that only users of Go can criticize Go, you're deciding to only take feedback from people who would use Go, and the only people who would use Go are people who aren't aware of the last few decades of compiler research: people who think coroutines are a new idea and aren't sure whether generics are useful.

As an outsider to the community, I wouldn't care if Go is crappy, except that I work in this industry, and if Go becomes popular enough, a situation will arise where I have to use Go or a language that imitates Go, or turn down a job because of it. Go being terrible and popular means that it affects the whole software industry negatively.

Also, arguing that I need more Go experience to criticize Go is somewhat ridiculous in response to an article which says, "Being an advocate is not really a separate stage, but a role you can fill at any of the other stages." So you need Go experience to criticize Go, but you don't need Go experience to advocate for it? This is why I assert that Go's popularity is mostly hype.

Re: Stages of learning Go, with code examples

#92
post #63

Earlier quoted context omitted.

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

I honestly don't care that much about package management: that's only symptomatic of the deeper issues with Go.

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

npm and RubyGems have two basic problems:

1. Curation of package sources. 2. People installing packages they shouldn't have.

Curation of package sources: notice that people don't complain nearly as much about dpkg/apt packages: they're curated much more carefully than npm/RubyGems packages (which is to say, they are curated).

People installing packages they shouldn't have: often the problems people run into with package management are self-inflicted. The adage is old: "Libraries from CPAN should not be treated as if they were part of the core." "Everyone else", as you say, is not experiencing DLL hell. I have zero difficulty with package management, because I use mature libraries and specify versions in my package configurations. There's no excuse to be experiencing DLL hell these days. The people who experience DLL hell are the ones who don't check in package configurations and then are surprised when the 0.1 alpha package they installed makes a breaking change and they don't know which version their code works with.

This is a problem in the Ruby community in particular because part of the draw of Ruby is "there's a package for everything". Newbie devs get caught up in the ecstatic frenzy of solving all their problems with gems without researching or testing those gems at all. But that's not a problem solved by Go's lack of a package manager, it's a problem solved by looking more carefully at what dependencies you introduce before introducing them.

Re: Stages of learning Go, with code examples

#93
post #85

Earlier quoted context omitted.

> Seems like your problem is with bad idioms, you seem to be a fan of the Play style -- both are just idioms, a simple way to improve communication. No, my problem, is with the pre-supposed and agreed upon set of idioms ("idiomatic Go", "idiomatic Java", "idiomatic Python"). I'm not even against what those idioms contain per se, as individual items. > "different but convenient" can to be looked at in two different wa…

> No, my problem, is with the pre-supposed and agreed upon set of idioms ("idiomatic Go", "idiomatic Java", "idiomatic Python"). Idioms have to be agreed upon (by the community) else they have no value at all. Shorthand only works if both people in the conversation understand what it means. It seems like you are upset that the idioms came from the standard libraries (which is where I believe the initial idioms for Go…

"""Idioms are not static. Please stop using that as a strawman to tear down. Idioms rot. If they are not what the community currently uses, they are not idiomatic."""

I'm not annoyed by idioms because they don't ever change -- but because while they exist in a certain form, they inhibit experimenting with different approaches.

Or to be more presize, I'm not annoyed by idioms themselves (as I also wrote above), as individual practices. I'm annoyed by people insisting on them, and criticizing everything diverting (unidiomatic) as something that's bad.

Nothing is static, except change. But for a specific period of time (which can be like aeons in the software industry) idioms are for all intends and purposes static.

E.g Java EE land, from say, 2000-ish to 2007. The idioms were fixed and agreed upon, and most people and groups, from Apache Struts to Java engineers and IBM played by them, but they neither helped the community "communicate via code" nor helped "make programs understandable".

Instead, they hindered both communication and understanding. Almost everybody agrees now that the adopted idioms at the time were bad, and inhibited progress and even slowed down projects.

It's not even like "it was good for it's time, but we eventually came up with something better". We always had the option to do the better thing (it doesn't take unique new research to not use a 20-levels deep hierarchy or to not think GoF patterns should be applied everywhere). And since we moved on, everybody seems to agree it wasn't "good for the time" either.

Re: Stages of learning Go, with code examples

#94
post #88

Earlier quoted context omitted.

You don't have to replace the go command to do that. The only thing that needs the GOPATH and expects import paths to be URLs is "go get". You can very easily make a go project that uses all relative import paths and put it anywhere you like. Dependencies then just get copied into whatever path you like using whatever name you like. However, your code will be unusable by anyone who follows the normal Go way of coding…

> However, your code will be unusable by anyone who follows the normal Go way of coding. Well, that's not really true given the major projects using tools like Godeps [1], so while that argument certainly sounds good, it doesn't actually seem to be a problem in practice. [1] https://coreos.com/blog/godep-for-end-user-go-projects/

Actually, CoreOS is using the version of godep that rewrites import paths, so that most developers can use "go get". The only time you need to use godep is when you're updating one of the vendored dependencies. That's actually the awesome thing about godep - it keeps your repo go-getable.

> the simplicity it presents to regular contributors and users used to go get make it worth the additional effort

Re: Stages of learning Go, with code examples

#95
post #46

Earlier quoted context omitted.

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

The community does not resist improvement. The community asks that you acquire some experience, work with what is there, make sure that you understand it, then suggest improvements. The community definitely does resist people who aren't even users loudly declaring exactly what it is that Go needs. I fear the community may have instinctively built up certain callouses that I'm not a big fan of, such as the near inabil…

> The community asks that you acquire some experience, work with what is there, make sure that you understand it, then suggest improvements.

And then it proceeds to ignore these improvements anyway because it has a dogmatic view on certain features and the credentials of the person suggesting the improvements are absolutely irrelevant.

Re: Stages of learning Go, with code examples

#96
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…

Are you making the argument that Go is finally the magic language that can make bad devs write good code ?

Let me be the realist here : it isn't.

Go is just a very young language that, for the moment, only has developers that are curious and therefore either good or willing to learn. This has the additional consequence that for the moment the mailinglist is very helpful. History teaches us that both effects have nothing to do with the language and are temporary (unless the language never sees any "real" acceptance, like Haskell).

You can look messages from some years back showing the same sentiment for Delphi, Visual Basic, Java, Python (especially Python had lots of people making this argument), ... And when those messages were posted, they were true. It didn't last long for any of them.

> But people would struggle without Visual Studio debugging and a big run button.

Sadly this is being used as an excuse for making language with substandard (to put it mildly) debugging facilities and editors.

And of course, like for every other argument, the Go team itself is just being extremely arrogant about this. "Why do you want this ?" type responses, or just dead silence, or outright declaring the people asking the question to be substandard developers or some such.

Re: Stages of learning Go, with code examples

#97
post #93

Earlier quoted context omitted.

> No, my problem, is with the pre-supposed and agreed upon set of idioms ("idiomatic Go", "idiomatic Java", "idiomatic Python"). Idioms have to be agreed upon (by the community) else they have no value at all. Shorthand only works if both people in the conversation understand what it means. It seems like you are upset that the idioms came from the standard libraries (which is where I believe the initial idioms for Go…

"""Idioms are not static. Please stop using that as a strawman to tear down. Idioms rot. If they are not what the community currently uses, they are not idiomatic.""" I'm not annoyed by idioms because they don't ever change -- but because while they exist in a certain form, they inhibit experimenting with different approaches. Or to be more presize, I'm not annoyed by idioms themselves (as I also wrote above), as ind…

Dude, just be a rebel and go off and program go however you like. All of your railing is pointless. Things change over time at different rates for different reasons. Clearly you personally feel insulted because you like to think of yourself as being an outside-the-box type of thinker who comes up with new clever ways of doing things. Good for you. Keep it up and don't forget to teach us along the way, but remember that simply railing against a communities standard approach is rather pointless. With your better way, lead on :)

I see you all the time in these go threads, by the way. You would better spend your time forgetting about go and doing something else since you so clearly detest it for not having generics (obviously less convenient than a functional language, but clearly not required to do programming).

Re: Stages of learning Go, with code examples

#98
post #46

Earlier quoted context omitted.

The community does not resist improvement. The community asks that you acquire some experience, work with what is there, make sure that you understand it, then suggest improvements. The community definitely does resist people who aren't even users loudly declaring exactly what it is that Go needs. I fear the community may have instinctively built up certain callouses that I'm not a big fan of, such as the near inabil…

> The community asks that you acquire some experience, work with what is there, make sure that you understand it, then suggest improvements. So what is it that you think people who want Go to have generics don't understand? You say that people should acquire some experience before criticizing Go, but you're only accepting a certain kind of experience. I've written tens of thousands of lines of code in similar languag…

> By deciding that only users of Go can criticize Go

This describes my feeling when going through the thread and reading that significant weaknesses of Go are not significant.

Re: Stages of learning Go, with code examples

#99
post #21
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…

You really need to look at Cargo in rustlang to see what good package manager can do and how it improves development.

Re: Stages of learning Go, with code examples

#100
post #21
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…

Please somebody explain me how to manage next situation without manual copying of code and forking repos (in other words, we need to still be able get updates for minor versions from repositories).

GOROOT/

pkg

src/

   lib1  

   app1

   app2

And app1 requires lib1 version 3.x, app2 requires lib1 version 1.x. What can we do?

Also, on whole this page https://golang.org/cmd/go/ I can't find ANY info, about how to fetch exact version from repo, not the master branch. In Go world all master branches are for stable code only, not for development? And all tools have only one version?

Post reply on HN