4 ms·

I've done real-life web dev using PHP and using Go, and have dabbled with Node. Thoughts: 1. Go's strict, statically typed, thou-shalt-check-thy-errors approa

I've done real-life web dev using PHP and using Go, and have dabbled with Node. Thoughts: 1. Go's strict, statically typed, thou-shalt-check-thy-errors approach is a breath of fresh air. The compiler does a whole load of checking which can (and therefore should) be automated, which in many other languages is left to the developer. Go code tends to have the property that if it compiles, it probably works as designed. I love this. 2. IMHO it makes more sense to think of a web app as a server application one of whose functions is to listen for and respond to HTTP requests. So, the question I'd ask is "is this a good language for server programming, and how easily can I make it speak HTTP?" In Go's case I've found the answers to be "hell yes" and "very". 3. The tooling is really nice. go fmt takes a whole load of pain away from everyone (no more effort required to format code properly, the tab/space and where-to-put-the-{ debates are solved decisively, reading other people's code is made easier), the package management is lovely, statically-linked executables are easy to move around and go doc encourages proper commenting. 4. Really good performance. 5. The biggest drawback I've seen with Go is verbosity - although a lot of the time it turns out that my verbose Go code is checking errors properly and my compact PHP code wasn't.

codygman 11y ago
> The compiler does a whole load of checking which can (and therefore should) be automated, which in many other languages is left to the developer. Go code tends to have the property that if it compiles, it probably works as designed. As someone who works with Go daily, these statements are both very untrue. Claiming "if it compiles it works" applies to Go code makes my eye twitchy. For instance, type assertions have no exhaustivity checker. Interface{} and liberal usage of it throws type safety out the window. > the package management is lovely, Go doesn't have package management per SE, just vendoring.
- mjw_byrne 11y ago
  I did fudge a little - "tends" and "probably". Of course compilation is not a guarantee of correctness, I just find that it gets me most of the way there. JavaScript, by comparison, feels like it's trying to give you rope to hang yourself. Maybe I'm abusing the term "package management". I'm talking about go get, the way imports function, the cute private/public lowercase/uppercase mechanism, the recently-added vendoring support etc.

codygman 11y ago

> The compiler does a whole load of checking which can (and therefore should) be automated, which in many other languages is left to the developer. Go code tends to have the property that if it compiles, it probably works as designed. As someone who works with Go daily, these statements are both very untrue. Claiming "if it compiles it works" applies to Go code makes my eye twitchy. For instance, type assertions have no exhaustivity checker. Interface{} and liberal usage of it throws type safety out the window. > the package management is lovely, Go doesn't have package management per SE, just vendoring.

mjw_byrne 11y ago
I did fudge a little - "tends" and "probably". Of course compilation is not a guarantee of correctness, I just find that it gets me most of the way there. JavaScript, by comparison, feels like it's trying to give you rope to hang yourself. Maybe I'm abusing the term "package management". I'm talking about go get, the way imports function, the cute private/public lowercase/uppercase mechanism, the recently-added vendoring support etc.