After working with .NET/Java/Node.js/Ruby/Python etc the move to Go involved a larger investment in time. I found this really informative and it's great to have the learnings condensed down.
Go best practices, six years in
21–30 of 207 posts
Re: Go best practices, six years in
#22Earlier quoted context omitted.
I've done a lot of ruby and go. Honestly, I would think twice before building a major website/product API on go. Development time is markedly slower in go, some causes off the top of my head: - testing is way harder (ruby has some amazing mocking/stubbing/testing tooling). - debugging is way harder. Hope you like printf. - Json; the strict typing & struct searialization rules make dealing with Json a pain in the arse…
Median latency is a completely useless number. There is literally no use for it, ever. Satan invented median latency to confuse people, because it lies to you and whispers sweet nothings in your ear. Averaging latencies in your monitoring leaves the outliers out in the cold because you will never see them, and tail latency is way more important for user experience. Quantile your latency. I suspect you'll find 99th te…
> Median latency is a completely useless number. There is literally no use for it, ever. Satan invented median latency to confuse people, because it lies to you and whispers sweet nothings in your ear. Averaging latencies in your monitoring leaves the outliers out in the cold because you will never see them, and tail latency is way more important for user experience.
Umm, you do not get the median latency by averaging anything. Median latency is just the 50th percentile. It is definitely not one of the interesting ones to reason about or care about improving, but not valueless to measure. It is interesting to have if you are graphing your latency curves, to make an example.
Re: Go best practices, six years in
#23Slightly tangential, but, could someone share their experience using Go specifically for building websites? How does Go (including Go frameworks specifically geared towards web development) compare in terms of performance, ease of development with RoR, Laravel? Is building websites using Go a good use case or is Go better suited for building high performance microservices?
I really enjoy using Go for building websites. But I use Go for everything, including games, frontend (instead of JavaScript), etc. There's nothing else I'd rather use. Heck, I even rewrote my resume in Go that renders HTML on frontend [0], hehe.
[0] view-source:https://dmitri.shuralyov.com/resume
Re: Go best practices, six years in
#24It was a great talk at QCon London earlier this year - the video is due to be published towards the end of next month. I'll try and come back to this thread when it is with the URL.
(Disclaimer: I was the track host for Perer's talk)
Re: Go best practices, six years in
#25After working with .NET/Java/Node.js/Ruby/Python etc the move to Go involved a larger investment in time. I found this really informative and it's great to have the learnings condensed down.
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.
Re: Go best practices, six years in
#26Good 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 such a trivial thing, and yet the fact that Go lacks a level of indirection (package.json, Cargo.toml, pom.xml, etc) to map a chosen directory structure to the standard build tooling causes problems that get really annoying. For instance, there's a ton of Go repositories out there that are not go gettable because the author wanted to put source code under a src directory and hacked that together using make. 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.
It all makes me sad since Go's decentralized dependency management (i.e. go get being able to pull/build based on a meta tag) is brilliant and I always hate having to rely on a single, centralized repository to deal with dependencies.
Re: Go best practices, six years in
#27> That advice still holds today: vendoring is still the solution to dependency management for binaries. This might be a stupid question, but can someone explain to me what this means? Thanks!
"Vendoring" means maintaining local copies of third-party libraries and other dependencies in your local repo so exactly what you depend on is a part of your internal history. Git provides ways of doing this easily, such as subtrees.
Just to add: the name comes from the convention of storing all those dependencies in a subdirectory named "vendor".
Re: Go best practices, six years in
#28Slightly tangential, but, could someone share their experience using Go specifically for building websites? How does Go (including Go frameworks specifically geared towards web development) compare in terms of performance, ease of development with RoR, Laravel? Is building websites using Go a good use case or is Go better suited for building high performance microservices?
My experience says "don't use Go for building web applications". Compared to something like Ruby on Rails, the development story with Go is much less batteries-included. You'll find yourself gluing together lots of components, and they're not really that friendly. Plus, for any front-end code, you'll end up using Node or whatever anyway to build assets. It's big and messy and not a good match. Go does excel at two ki…
what would you use go for then?
Re: Go best practices, six years in
#29The article sort of glosses over IntelliJ with the golang plugin as an "other" IDE, but it's best in class hands down. At one point in my past I had sworn off of Java-based IDEs, and used Sublime Text for years with primarily Python and Go. Something convinced me to try Go in IntelliJ, and really it's fantastic. It also covers "important-to-me" features the author mentions. I haven't tried VSCode yet, but have tried…
In my experience most Go developers seem to favor a terminal-heavy workflow, sometimes frequently shutting down and re-opening their editors in new paths and projects. The barebones simplicity of Go-the-language seems to be a nice match to this workflow. It's a different thing altogether to how large IDEs like IntelliJ expect you to work: opening up a project and staying in the IDE for a long period of time. Both app…
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 any size, don't pass over trying IntelliJ. I spend 95% of my time in Go now, and IntelliJ has been surprisingly good.
Re: Go best practices, six years in
#30"those parameters should be part of type constructors"
I'm not sure if this is a nit, a misunderstanding on my part, or a difference in terminology, but I think what is meant here is "value constructors" (or more commonly, just "constructors"). As I understand the term, "type constructors" construct types.