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

Go: Ten years and climbing

commandcenter.blogspot.com

Post reply on HN
Print view View original

181–190 of 193 posts

Re: Go: Ten years and climbing

#181

Post by edef »

tptacek wrote: post #156
elgenie wrote: post #96

Earlier quoted context omitted.

That seems to be an intentional misreading. The criticism of Go being presented is that it's intentionally underpowered so as to make it possible for poor developers to verbosely muddle their way through to developing working real applications without actually becoming better.

This is such an old programming language flame war trope that it was probably first written in Aramaic. When I started programming as a teenager and commented on FIDOnet BBS's, people literally said it about assembly language. If for no other reason than to preserve your own dignity, please don't imply that people program in a particular language because they're not good enough to program in other languages.

> This is such an old programming language flame war trope that it was probably first written in Aramaic.

I love the quip, but

> people literally said it about assembly language. If for no other reason than to preserve your own dignity, please don't imply that people program in a particular language because they're not good enough to program in other languages.

This is an inversion of the sentiment being expressed: the suggestion is to use languages that allow you to shift more cognitive overhead to the compiler and tooling. If anything, I program in Rust when I fear that the keeping track of all the little bits Go doesn't help me with will take up too much of my puny human brain.

Re: Go: Ten years and climbing

#182

Post by infogulch »

kminehart wrote: post #177
infogulch wrote: post #91

Earlier quoted context omitted.

Ok, but why would you do that? Either just vendor it in the new project (copy-paste a directory) or download it to your gopath and import that. The nice thing is that you don't have to change the import when you decide to vendor.

I think you misunderstand. If I have project A, which imports dependency A. I (for faster tests is the only real answer), decided to commit the vendor folder. Now, in project B, if I import a package of project A, which uses dependency A, it will look for that specific version of dependency A. Specifically errors like this: pkg/projectb/example.go:18:30: cannot use *w (type "github.com/dependency/pkg".Example) as typ…

Oh I see. I think the conventional wisdom here is to only ever vendor the end use (binary) projects, not libraries (and maintain such a distinction). (But I guess that's as helpful as "you're holding it wrong".)

So your problem is you have ("binary") packages A and B, and a helper package at A/H that you want to import into B. But A is vendored at A/vendor, so A/H always looks for dependency D at A/vendor, which is wrong for B.

I would fix it by moving A's main into A/cmd, and vendor at A/cmd/vendor instead. A/cmd can still import all its' helper packages like before, but now B can also import them without getting snagged by A's vendoring because it vendors another level up.

Could that work?

Re: Go: Ten years and climbing

#183

Post by kminehart »

infogulch wrote: post #182
kminehart wrote: post #177

Earlier quoted context omitted.

I think you misunderstand. If I have project A, which imports dependency A. I (for faster tests is the only real answer), decided to commit the vendor folder. Now, in project B, if I import a package of project A, which uses dependency A, it will look for that specific version of dependency A. Specifically errors like this: pkg/projectb/example.go:18:30: cannot use *w (type "github.com/dependency/pkg".Example) as typ…

Oh I see. I think the conventional wisdom here is to only ever vendor the end use (binary) projects, not libraries (and maintain such a distinction). (But I guess that's as helpful as "you're holding it wrong".) So your problem is you have ("binary") packages A and B, and a helper package at A/H that you want to import into B. But A is vendored at A/vendor, so A/H always looks for dependency D at A/vendor, which is w…

Hmm yeah I think that would be a good option. One potential problem with that is running tests on the individual packages. I believe that the vendor folder would have to be in a descendant folder. So like... "./vendor", or "../vendor", "../../vendor", and so on. If the vendor folder was in "./cmd/vendor", and you ran the test "go test ./pkg/example", it would not find the vendor folder.

My solution was just to not commit the vendor folder, and before the test starts, run "dep ensure".

Re: Go: Ten years and climbing

#185

Post by infogulch »

kminehart wrote: post #183
infogulch wrote: post #182

Earlier quoted context omitted.

Oh I see. I think the conventional wisdom here is to only ever vendor the end use (binary) projects, not libraries (and maintain such a distinction). (But I guess that's as helpful as "you're holding it wrong".) So your problem is you have ("binary") packages A and B, and a helper package at A/H that you want to import into B. But A is vendored at A/vendor, so A/H always looks for dependency D at A/vendor, which is w…

Hmm yeah I think that would be a good option. One potential problem with that is running tests on the individual packages. I believe that the vendor folder would have to be in a descendant folder. So like... "./vendor", or "../vendor", "../../vendor", and so on. If the vendor folder was in "./cmd/vendor", and you ran the test "go test ./pkg/example", it would not find the vendor folder. My solution was just to not co…

Oh that's certainly a good point and a deficiency in my design.

But then again if you're only testing H against A's vendored dependencies specifically, you're missing testing it against B's. I'm not sure how you would fix that.

Re: Go: Ten years and climbing

#186

Post by elgenie »

tptacek wrote: post #156
elgenie wrote: post #96

Earlier quoted context omitted.

That seems to be an intentional misreading. The criticism of Go being presented is that it's intentionally underpowered so as to make it possible for poor developers to verbosely muddle their way through to developing working real applications without actually becoming better.

This is such an old programming language flame war trope that it was probably first written in Aramaic. When I started programming as a teenager and commented on FIDOnet BBS's, people literally said it about assembly language. If for no other reason than to preserve your own dignity, please don't imply that people program in a particular language because they're not good enough to program in other languages.

That's nice and all, but how is it relevant to my paraphrasing of the grandparent comment to clarify the distinction from the parent's misreading?

As the sibling comment points out, you managed to misidentify the trope to boot.

Re: Go: Ten years and climbing

#187

Post by yahna »

gizzlon wrote: post #135
elgenie wrote: post #111

Earlier quoted context omitted.

I personally think Go and Java were developed for the same audience with similar intentions and language designer skill and are going to face the same criticisms. For natural languages, the research seems to indicate that information is transmitted at the same rate when the languages are spoken (e.g. http://muse.jhu.edu/article/449938/pdf ) with faster speaking rates compensating for higher verbosity. In terms of wri…

I always hated Java but really like Go. Think it's because the Go culture and ecosystem strives for simplicity.

This attitude always seems to be, and I don't know a better word, hipster-ism.

Java isn't cool anymore.

Re: Go: Ten years and climbing

#188

Post by yahna »

aaron-lebo wrote: post #123
pjmlp wrote: post #117

Earlier quoted context omitted.

> Do people really believe that individuals such as Rob Pike, Ken Thompson, and Brian Kernighan are just trying to propagate Blub, the language, so that all devs are lowest common denominator morons? It was Pike himself that stated that as a goal for Go at one of the early Goconfs, because new Googlers aren't skilled enough to pick up C++, Java or Python. If you wish I can track it down for you.

The key point here is our programmers are Googlers, they’re not researchers. They’re typically, fairly young, fresh out of school, probably learned Java, maybe learned C or C++, probably learned Python. They’re not capable of understanding a brilliant language but we want to use them to build good software. So, the language that we give them has to be easy for them to understand and easy to adopt. That's the quote pe…

> They’re not capable of understanding a brilliant language

So his language isn't brilliant. it's for dummies, morons, and fools.

Not sure how else that could be read.

Re: Go: Ten years and climbing

#189

Post by yahna »

staunch wrote: post #20

One of Larry Wall's slogans for Perl is "Easy things should be easy, and hard things should be possible." In its own way, that's what has made Go the kind of success that Perl once was. Perl was the glue language of the web and Go is the production language of the cloud. I'm actually a bit scared to imagine a world in which Go was not created, given how much success I've personally had with it. Thanks to the entire G…

You would write Java instead and nothing would be that different.

Re: Go: Ten years and climbing

#190

Post by yahna »

aaron-lebo wrote: post #151
kod wrote: post #148

Earlier quoted context omitted.

This is a bad comparison. Core philosophy of Perl is to empower programmers with more than one way to do it. Core philosophy of Go is your coworkers are too stupid to be allowed to have nice things.

Seems like the core philosophy of Go is the end result of Python's "there's one way to do it". The "Go's design and users are dumb" meme needs to die. It's not even a constructive criticism. It's dishonest, insulting, and it's too bad grown adults and professionals can't see beyond it.

Then maybe the creator shouldn't have said it.
Post reply on HN