4 ms·

web services

• latch 8y ago
  Really? Most webservices are dealing with untyped data at their input as well as their data sources. In this respect, Go inherits all the pain points of most static languages with the addition of having a pretty poor type system. Further, the most common way to deal with errors in a webservice (frankly, in a lot of types of systems) is to have an outer error handler catch an exception, log the error and tell the user "oops, try again". Pain to achieve this in Go. It's hard for me to come up with a type of system where Go is more ill suited given how much choice you have. Go for web services only makes sense if your workload is CPU bound or you need to throw cores at large block of shared memory (and you have your reasons for not wanting to use Rust or the JVM ). 99% of webservices are better off in Elixir, Node, Ruby, Python or even PHP. Go's best use case is for CLIs.