61–70 of 207 posts
Earlier quoted context omitted.
Appreciate it was written as tongue in cheek, but I am glad that today a developer can start with Go, test, write code, build, deploy all with Go, whereas nearly every other ecosystem requires additional tools, often external competing tools. Then life becomes about having to learn whole new toolbekt before even coding. Go still keeps it lean, and is great. The fact it does not have hipster dev approved status is als…
Rust has that built in, but managed to be a much more solid language (feature wise).
The site blocks Tor users; ugh.
Good article on the whole, but I have a few quibbles: > If your repo foo is primarily a binary, put your library code in a lib/ subdir, and call it package foo. IMHO, that's just ugly, uglier than foo/foo or foo/foolib or foo/libfoo. I also think that anything which has commands other than a single-command project which will always be a single-command project (there are fewer of these than one might think …) should p…
> IMHO, that's just ugly, uglier than foo/foo or foo/foolib or foo/libfoo. > I also think that anything which has commands other than a single-command project which will always be a single-command project (there are fewer of these than one might think …) should put all commands, even a single one, in cmd/. It's this kind of inflexibility in the directory structure of ones repo that really turned me off of Go. It's su…
Are there? If someone's that ignorant of the language, I don't think I'd want to run something written by him …
> And good luck with organizing any repository that contains multiple languages where go is one of them...go's "code lives at the repository root" doesn't play well with others.
I've actually built libraries which involved both Go & Python without a problem.
Earlier quoted context omitted.
Oh me too - my setup is usually split screen IntelliJ and iTerm2. But as projects grew larger, (and I wasn't a vim-er) a lot of the tools that come with a full fledged IDE became nice-to-haves (definition-on-hover as source code, click-to-definition, tree and object graph always open, and so on). I know my setup isn't for everyone, but if you're looking for a good Go IDE experience, especially if your projects are of…
As a Java developer that uses Intellij exclusively this is great news. Maybe I'll check out Go more. I really hate using languages without good IDE integration.
Earlier quoted context omitted.
Check out YouTube conf. talks from the same author, where he shared his experience developing services in Go, while working at SoundCloud. Also, very helpful.
Could you please provide the link?
> No statements go by where the object is in an intermediate, invalid state. This seems kind of misleading. Per my understanding of Go, omitted fields in a struct initialization are defaulted not reported as errors. So you're equally likely to be passing invalid state, in the two situations. One pattern I like in Haskell, for this kind of thing, is to define a defaultConfig value that contains typical defaults and wh…
The stages of go enlightenment: 1. Holy crap, this is like coding in early Java days, what the heck were the language designers smoking?! They just ignored everything! Where's my testing framework! DI?! Build system, dependency management?! WTF. 2. Holy crap, this is like coding in the early Java days! This is awesome! I can understand all golang code I read! Everything is so simple and easy. I finally get "less is m…
> No statements go by where the object is in an intermediate, invalid state. This seems kind of misleading. Per my understanding of Go, omitted fields in a struct initialization are defaulted not reported as errors. So you're equally likely to be passing invalid state, in the two situations. One pattern I like in Haskell, for this kind of thing, is to define a defaultConfig value that contains typical defaults and wh…
Hopefully you'll combine that idiom with "make the zero value useful" so that omitted fields still give valid behavior.
It still breaks down when a zero value is meaningful for a configuration parameter, but means something different than what was done before the parameter was configurable. I think that's probably not super often.
In light of all this, I still don't really see what harm we're avoiding by preferring the inlined struct initialization. I do agree it looks a little prettier, but the article seems to give it a greater import.