7 ms·

Go shines for network services. The standard library has everything you need for networking and the web with very accessible concurrency primitives. It's also a

Go shines for network services. The standard library has everything you need for networking and the web with very accessible concurrency primitives. It's also a pretty lightweight language that's easy for people to pick up.

90s_dev 1y ago
Are these not also true for Node.js? Add the familiarity of JavaScript, the ecosystem of NPM, and the good-enough speed of V8, and I'm not sure why choose Go.
- acoustics 1y ago
  Go's performance is in a totally different class than node.
  - pjmlp 1y ago
    Depends if nodejs C++ AddOns are part of the picture or not.
- nikolayasdf123 1y ago
  minimalism in dependencies, security, type system and static analysis. tooling (fuzz tests, benchmarks, etc.). uniform syntax (thanks go fmt) in entire ecosystem.
- scripturial 1y ago
  Go has a standard code style, everyone agrees to use the same format and all our code becomes easier to read and standardized. Go is very much faster, you save time and money on computing resources. Go has built in testing and type support, making it easier To write more reliable and more bug free code. But let’s not debate it, learn go for yourself and try it on a small little project. I’m convinced you’ll pretty much not want to switch back.
  - 90s_dev 1y ago
    > Go has a standard code style, everyone agrees to use the same format and all our code becomes easier to read and standardized. I like VS Code's default code style for TypeScript, but partly because it is not too opinionated about whitespace (though it gets close). But after 10 years, I finally went back to manual CSS formatting. I just can't write CSS without the option of single-line rulesets. gofmt doesn't (or at least didn't) allow single-line blocks ever. This is just too opinionated, and for that reason it will one day change, even if that day is 20 years from now. Having a standard is fine. But software is not just technical, it's an art too.
    - haiku2077 1y ago
      > This is just too opinionated, and for that reason it will one day change, even if that day is 20 years from now. Would you be willing to make a Long Bet about it? https://longbets.org https://longbets.org
      - 90s_dev 1y ago
        Interesting site, I bet it won't last more than 20 more years. I've been both right and wrong about long term predictions often enough that I've learned to just stop caring about it. (But I am right in this case.)
  - 90s_dev 1y ago
    > But let’s not debate it, learn go for yourself and try it on a small little project I wrote a lot of Go from like 2010 to 2013 or so. A few days ago I read an article from someone clearly experienced in general software good practices, who masterfully laid out every complaint I had when I left Go. I wish I could find it, but I think it was from this year or last year. The only example I can remember is repetitive explicit error handling with a comparison to more modern languages.
    - jpc0 1y ago
      > I wish I could find it, but I think it was from this year or last year. The only example I can remember is repetitive explicit error handling with a comparison to more modern languages. I have the opposite experience here, I find golangs error handling to be too abstract at times. I need to know what error and in what situation a function can return an error. An abstract error doesn’t help with that and an exception even less so. I need to dive into a functions source far too often to try to understand in what situation an error might occur and what that error would be if it is even typed. If you fine error handling annoying and only handle it high up in the call chain your codebase is either brittle or returns generic unusable errors and you have to rely aggressively on runtime tracing which is very expensive.
- tuckerman 1y ago
  The convenience of shipping a single compiled binary is one. I also think the ecosystem of NPM is, for some, not a positive. I can regularly write go programs with no or very minimal dependencies (and those dependencies are themselves often the same way). The go standard library is pretty well thought out and the included batteries are mostly high quality. Easy integration with pprof, opinionated testing, embed, pretty good datetime primitives, etc
  - 90s_dev 1y ago
    1. Node.js now has SEA 2. Which is better, having 70,000 packages but only 700 good ones, or only 500 packages and every one is good? I'm on the fence.
    - tuckerman 1y ago
      Very cool about the SEA feature, I haven't seen that before. Thanks for sharing that This is sort of the worst case comparison, but a hello world program in go is 1.5 MiB and the SEA node equivalent is 109 MiB. Obviously as your program becomes more complex that fixed overhead becomes less of an issue but I think it's still a useful comparison. For the packages, the thing I prefer even more so is writing an application with 0 dependencies at all. net/http, net/http/pprof, flag, pprof, etc are all built in and high quality and you can easily build clis/servers with them. Even a really full featured CLI builder package like cobra has just a few transitive deps and gorilla/mux has none: https://github.com/spf13/cobra/blob/main/go.sum https://github.com/spf13/cobra/blob/main/go.sum https://github.com/gorilla/mux/blob/main/go.mod https://github.com/gorilla/mux/blob/main/go.mod If I compare that with express.js or commander its a very different story (though, in fairness to commander, they all seem to be dev deps). I don't think it's bad per se to have deps, just a different culture. https://news.ycombinator.com/item?id=43935067 https://news.ycombinator.com/item?id=43935067 kinda beat that horse already though
      - 90s_dev 1y ago
        I actually agree, and my own Node.js web server doesn't use express.js or anything except for 'mime-types', and only because it's not built in even though it really should be. I never liked express.js's design, and pretty much every useful feature of it is now either built-in or 5 lines of code. Plus, when I dug into its source code and dependencies, I found so much outdated and unnecessary cruft. So yeah I don't disagree. But it still doesn't really push me towards Go. Plus, Go's own http route mounting concept also seems kind of overdone. So even though I can just avoid using it, it still becomes part of that 1.5 MiB that I didn't really need but am forced to bundle, even if it is smaller than the 109 MiB. So in principle it doesn't seem a huge win, just a small one. Compare that to the many TypeScript features and JavaScript features I'd have to give up, and it just doesn't seem worth it.
- deleted 1y ago
  [deleted]
- pjmlp 1y ago
  Additionally, if more performance is needed we can always write a native module. However, I would use Go instead when deploying in cloud providers like Vercel and Netlify, as explained in a sibling comment. It is easier to just go with the less friction option, and deploying such modules requires not only knowing how to write them, also mastering the whole deployment process, thus not something I would advise in teams with mixed skill levels.
echelon 1y ago
I've used Go and Rust for network services, and they honestly feel completely on par with one another from a DX and ergonomics perspective. I wouldn't be surprised if Rust starts eating into Go marketshare for microservices. There are some Googlers angling for this.
- emseetech 1y ago
  I can't agree they're on par based on function coloring and slow compile times alone.
- root_axis 1y ago
  I love Rust, but Go is a much much simpler language, especially for network services. For example, the experience of goroutines vs rust async is night and day in terms of complexity. Also, the borrow-checker introduces a lot more ceremony when managing network peer entities, particularly structuring relationships between entities - a very common requirement in network applications. Not that I'm against Rust for network services, but with Rust you're accepting increased complexity for increased safety - a worthwhile tradeoff depending on the project.
Animats 1y ago
> Go shines for network services. Right. Go is a great language for the server side of web client/server things. It's more reliable than C++, easier than Rust, and is hard-compiled to a read-only executable, which is good for security. Goroutines, which are cheap but can block, get rid of the async/sync distinction. The important libraries are maintained by Google people and used internally, so even the unusual cases are well-exercised. What more do you want?
- nikolayasdf123 1y ago
  native GPU (CUDA, BLAS and friends) support would be nice. haha

90s_dev 1y ago

Are these not also true for Node.js? Add the familiarity of JavaScript, the ecosystem of NPM, and the good-enough speed of V8, and I'm not sure why choose Go.

acoustics 1y ago
Go's performance is in a totally different class than node.
- pjmlp 1y ago
  Depends if nodejs C++ AddOns are part of the picture or not.
nikolayasdf123 1y ago
minimalism in dependencies, security, type system and static analysis. tooling (fuzz tests, benchmarks, etc.). uniform syntax (thanks go fmt) in entire ecosystem.
scripturial 1y ago
Go has a standard code style, everyone agrees to use the same format and all our code becomes easier to read and standardized. Go is very much faster, you save time and money on computing resources. Go has built in testing and type support, making it easier To write more reliable and more bug free code. But let’s not debate it, learn go for yourself and try it on a small little project. I’m convinced you’ll pretty much not want to switch back.
- 90s_dev 1y ago
  > Go has a standard code style, everyone agrees to use the same format and all our code becomes easier to read and standardized. I like VS Code's default code style for TypeScript, but partly because it is not too opinionated about whitespace (though it gets close). But after 10 years, I finally went back to manual CSS formatting. I just can't write CSS without the option of single-line rulesets. gofmt doesn't (or at least didn't) allow single-line blocks ever. This is just too opinionated, and for that reason it will one day change, even if that day is 20 years from now. Having a standard is fine. But software is not just technical, it's an art too.
  - haiku2077 1y ago
    > This is just too opinionated, and for that reason it will one day change, even if that day is 20 years from now. Would you be willing to make a Long Bet about it? https://longbets.org https://longbets.org
    - 90s_dev 1y ago
      Interesting site, I bet it won't last more than 20 more years. I've been both right and wrong about long term predictions often enough that I've learned to just stop caring about it. (But I am right in this case.)
- 90s_dev 1y ago
  > But let’s not debate it, learn go for yourself and try it on a small little project I wrote a lot of Go from like 2010 to 2013 or so. A few days ago I read an article from someone clearly experienced in general software good practices, who masterfully laid out every complaint I had when I left Go. I wish I could find it, but I think it was from this year or last year. The only example I can remember is repetitive explicit error handling with a comparison to more modern languages.
  - jpc0 1y ago
    > I wish I could find it, but I think it was from this year or last year. The only example I can remember is repetitive explicit error handling with a comparison to more modern languages. I have the opposite experience here, I find golangs error handling to be too abstract at times. I need to know what error and in what situation a function can return an error. An abstract error doesn’t help with that and an exception even less so. I need to dive into a functions source far too often to try to understand in what situation an error might occur and what that error would be if it is even typed. If you fine error handling annoying and only handle it high up in the call chain your codebase is either brittle or returns generic unusable errors and you have to rely aggressively on runtime tracing which is very expensive.
tuckerman 1y ago
The convenience of shipping a single compiled binary is one. I also think the ecosystem of NPM is, for some, not a positive. I can regularly write go programs with no or very minimal dependencies (and those dependencies are themselves often the same way). The go standard library is pretty well thought out and the included batteries are mostly high quality. Easy integration with pprof, opinionated testing, embed, pretty good datetime primitives, etc
- 90s_dev 1y ago
  1. Node.js now has SEA 2. Which is better, having 70,000 packages but only 700 good ones, or only 500 packages and every one is good? I'm on the fence.
  - tuckerman 1y ago
    Very cool about the SEA feature, I haven't seen that before. Thanks for sharing that This is sort of the worst case comparison, but a hello world program in go is 1.5 MiB and the SEA node equivalent is 109 MiB. Obviously as your program becomes more complex that fixed overhead becomes less of an issue but I think it's still a useful comparison. For the packages, the thing I prefer even more so is writing an application with 0 dependencies at all. net/http, net/http/pprof, flag, pprof, etc are all built in and high quality and you can easily build clis/servers with them. Even a really full featured CLI builder package like cobra has just a few transitive deps and gorilla/mux has none: https://github.com/spf13/cobra/blob/main/go.sum https://github.com/spf13/cobra/blob/main/go.sum https://github.com/gorilla/mux/blob/main/go.mod https://github.com/gorilla/mux/blob/main/go.mod If I compare that with express.js or commander its a very different story (though, in fairness to commander, they all seem to be dev deps). I don't think it's bad per se to have deps, just a different culture. https://news.ycombinator.com/item?id=43935067 https://news.ycombinator.com/item?id=43935067 kinda beat that horse already though
    - 90s_dev 1y ago
      I actually agree, and my own Node.js web server doesn't use express.js or anything except for 'mime-types', and only because it's not built in even though it really should be. I never liked express.js's design, and pretty much every useful feature of it is now either built-in or 5 lines of code. Plus, when I dug into its source code and dependencies, I found so much outdated and unnecessary cruft. So yeah I don't disagree. But it still doesn't really push me towards Go. Plus, Go's own http route mounting concept also seems kind of overdone. So even though I can just avoid using it, it still becomes part of that 1.5 MiB that I didn't really need but am forced to bundle, even if it is smaller than the 109 MiB. So in principle it doesn't seem a huge win, just a small one. Compare that to the many TypeScript features and JavaScript features I'd have to give up, and it just doesn't seem worth it.
deleted 1y ago
[deleted]
pjmlp 1y ago
Additionally, if more performance is needed we can always write a native module. However, I would use Go instead when deploying in cloud providers like Vercel and Netlify, as explained in a sibling comment. It is easier to just go with the less friction option, and deploying such modules requires not only knowing how to write them, also mastering the whole deployment process, thus not something I would advise in teams with mixed skill levels.

echelon 1y ago

I've used Go and Rust for network services, and they honestly feel completely on par with one another from a DX and ergonomics perspective. I wouldn't be surprised if Rust starts eating into Go marketshare for microservices. There are some Googlers angling for this.

emseetech 1y ago
I can't agree they're on par based on function coloring and slow compile times alone.
root_axis 1y ago
I love Rust, but Go is a much much simpler language, especially for network services. For example, the experience of goroutines vs rust async is night and day in terms of complexity. Also, the borrow-checker introduces a lot more ceremony when managing network peer entities, particularly structuring relationships between entities - a very common requirement in network applications. Not that I'm against Rust for network services, but with Rust you're accepting increased complexity for increased safety - a worthwhile tradeoff depending on the project.

Animats 1y ago

> Go shines for network services. Right. Go is a great language for the server side of web client/server things. It's more reliable than C++, easier than Rust, and is hard-compiled to a read-only executable, which is good for security. Goroutines, which are cheap but can block, get rid of the async/sync distinction. The important libraries are maintained by Google people and used internally, so even the unusual cases are well-exercised. What more do you want?

nikolayasdf123 1y ago
native GPU (CUDA, BLAS and friends) support would be nice. haha