3 ms·

I recently spearheaded the creation of a new Go service at my company. If it was Node or Python I could easily imagine a team getting sucked into weeks of bikes

I recently spearheaded the creation of a new Go service at my company. If it was Node or Python I could easily imagine a team getting sucked into weeks of bikeshedding the API framework, the test framework, linting tools, formatting tools, the TLS stack, research spikes on packaging and distribution, etc. With Go, all of these problems were basically solved by the strength of the standard library. We could not be happier.

Abishek_Muthian 5y ago
> the TLS stack Networking prowess of Go is often underrated in these discussions. Building an web application with server, router, mux, auth etc. all from standard library and just deploying the binary blob on the cloud (irrespective of the architecture) to get your application running with less effort than competing programming languages/frameworks is itself enough for most use cases.
- theshrike79 5y ago
  Did the programming on macOS, build machines were Linux and the customer ran the code on Windows. Zero Go-related issues during the whole project. Just drop in one executable and one config file and it just works.
takeda 5y ago
I think having options is just sign of more mature language. In python you could also implement the API framework, do unit testing, TLS, packaging using standard library. And similarly there are 3rd party frameworks for Go as well.
- loopz 5y ago
  There's always tradeoffs, to be sure. What many are trying to convey is that Go's defaults tend to be the stronger and simpler options. However, for a lone wolf project, I'd lean more on something like gorm, than just hand-craft and maintain lots of sql. Another misconception is that it's all for inexperienced programmers. But you need decades of experience to appreciate all the opinionated tradeoffs already made in Go. It's just one more tool though, and nowhere near FP, which is a different beast altogether. Lots of features around Go and ecosystem is clearly inspired from Haskell. That might be another good tool from the other end of the spectrum.
  - takeda 5y ago
    Go is just new, so it had opportunity to build what we already know. Python is older than Java. When it was first released there was no World Wide Web even, not mentioning REST.

Abishek_Muthian 5y ago

> the TLS stack Networking prowess of Go is often underrated in these discussions. Building an web application with server, router, mux, auth etc. all from standard library and just deploying the binary blob on the cloud (irrespective of the architecture) to get your application running with less effort than competing programming languages/frameworks is itself enough for most use cases.

theshrike79 5y ago
Did the programming on macOS, build machines were Linux and the customer ran the code on Windows. Zero Go-related issues during the whole project. Just drop in one executable and one config file and it just works.

takeda 5y ago

I think having options is just sign of more mature language. In python you could also implement the API framework, do unit testing, TLS, packaging using standard library. And similarly there are 3rd party frameworks for Go as well.

loopz 5y ago
There's always tradeoffs, to be sure. What many are trying to convey is that Go's defaults tend to be the stronger and simpler options. However, for a lone wolf project, I'd lean more on something like gorm, than just hand-craft and maintain lots of sql. Another misconception is that it's all for inexperienced programmers. But you need decades of experience to appreciate all the opinionated tradeoffs already made in Go. It's just one more tool though, and nowhere near FP, which is a different beast altogether. Lots of features around Go and ecosystem is clearly inspired from Haskell. That might be another good tool from the other end of the spectrum.
- takeda 5y ago
  Go is just new, so it had opportunity to build what we already know. Python is older than Java. When it was first released there was no World Wide Web even, not mentioning REST.