Go best practices, six years in
peter.bourgon.org
Go best practices, six years in
1–10 of 207 posts
Re: Go best practices, six years in
#2> 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!
Re: Go best practices, six years in
#3> 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!
To vendor a dependency is to store a copy of all the source code you're trying to use inside your project itself. That way, when you compile your project, you also compile the code it depends on.
Updating code you depend on is a semi-manual process - you choose to copy the latest version of the code you depend on into your project again.
This is contrast to stacks like Java, where I can give you a pre-compiled JAR file that you can link your code to.
Re: Go best practices, six years in
#4Good 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 put all commands, even a single one, in cmd/.
I think that inline config objects should be used with useful zero values to try to emulate Lisp's or Python's keyword arguments: if one always needs to provide a value for each config object member, then just use arguments after all.
I think a testing library can be a great addition, since it can turn a three-line if check into a one-line assertion.
Re: Go best practices, six years in
#5> 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.
Re: Go best practices, six years in
#6Slightly 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?
Re: Go best practices, six years in
#7Slightly 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?
Go is pretty good for anything backend related.
Re: Go best practices, six years in
#8Slightly 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 worked with both Go and Elixir but found Elixir and Phoenix better than Go for building backends for web services. I was more productive and all the awesomeness of Erlang VM made me choose Elixir. I would say give Elixir a try.
Re: Go best practices, six years in
#9The 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 all the others listed. IntelliJ is fantastic for Go.
Re: Go best practices, six years in
#10The 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 approaches are totally valid, of course, but I suspect Go developers are biased toward lighter-weight editors.