As the title states, did you switch to Go/Golang for developing REST api’s or other kinds of web services? What has been your experience? Would you use Go again in the future? Would you rather use something else?
Yes, in 2017 and 3 companies later I've never looked back. Current application is an event-sourced system that includes a REST API, asynchronous event processing over SSE, and a scheduled job runner.<p>It's been great. We don't use any frameworks, just the http package. It's blazing fast and highly reliable (low bug occurrence and easy refactors due to the safety provided by strong typing).
I went from Python to Go to Rust. Go plays up this fantasy of types helping you catch bugs, buts it’s really C with lipstick. There’s no enums, no exhaustive matching of any kinds, there’s null to worry about everywhere, and every utility function has to be painfully written out for each type (maybe that’s starting to change now with Go having basic support for generics).
I switched from Python to Go for API development and never looked back. Performance is great, deployment is a breeze and the compiler and type system are good enough that my code normally works on the first try. I've also been building AWS Lambda backends and Go is great in that role as well. Workloads complete much more quickly than equivalent Python code and use a fraction of the memory.
First of, just like the term "hacker" became popularized by the media and turned into the meaning of someone who cracks computers and software, so has HTTP based APIs been popularized and turned into REST applications, but this is wrong. A HTTP based API cannot, by its very nature, ever be REST.<p>Now that's out of the way, yes. We use Go for both API and web development, actually full stack WITHOUT any JavaScript. We have written a custom error handler that deals with runtime HTML template errors, if any, which improves the otherwise tedious work when a template makes the web service crash.<p>Go is superb at HTTP and all web related. We still have some PHP development, but would very much like to do Go all the way, we just haven't gotten there yet.<p>Last, but not least, we do not use any frameworks or libraries, only the Go standard library and we love it. No matter were we put it, it just always works and is very performant.
Well if you ask people that specifically switched to Go, then all you are going to get is responses and anecdotes that meets your expectation.<p>However, if you ask people that switched away from Go, then you will see responses that also match that expectation.<p>So it really is down to your preference.
I made a few APIs on Golang and it was fine. It was easy and it performed well in production for many years.<p>Today, I would go with Rust instead because of personal preferences. But if my code base has to be shared with not very experienced developers, perhaps Golang again.
Yes! trying to use it for new things.<p>Because of the stable nature of the base language and library, and the way libraries are imported, with multiple pinned versions allowed and without import loops, it gives better longevity to "set and forget" type back-end services.<p>I rarely have a problem when coming back to work on an old project, it still compiles and even updating dependencies is usually fine.<p>This helps with the problem of back-end services becoming "forgotten children" that don't receive attention for extended periods.
When some of the teams I've worked with switched from PHP / Laravel to go the most common complaint was that their code must be broken because it was just too fast.
Golang is my default for REST API’s. I may swap that to elixir for certain use cases.<p>That said, being able to use pprof to debug and the single binary deployment makes life really easy.
Yes - for cloud functions. Even reasonably simple python APIs can exceed the 128mb lowest mem spec while go equivalent gets you an extra 60 ish meg breathing room
My team and I have built many dozen services using Go and Fiber (fiber.io) and have been insanely pleased with the experience and the performance of the code. We have quickly onboarded new devs and got them productive very quickly thanks to the relative simplicity of the language, amazing documentation and strong start of tools. We are writing most of our components, APIs and tools in Go. Go for it!
Yes, go is still my go to technology for API work. I usually go about it like this: write an OpenAPI spec, generate clients and servers, implement individual operations. I like how lightweight a go implementation is and how easy, no-bs it is to setup a new module. I like go for apis.
Look into the embedded filesystem for storing static stats and metric pages, it's nice to have that packaged up in the same single binary and goes a long way in making small webserver utilities more usable.