Re: Moving from PHP to Go and Back Again

Frameworks necessarily limit what you can do.

For example, the labstack echo framework in Go is one of my favorite frameworks, it does a lot of work for me. On the downside, I can't hijack HTTP connections in the router, like for example, when I want to host something under customs domains and redirect internally to a subURL. I have to hack around the framework to do that, the solution is rather ugly. But there isn't much I can do otherwise that doesn't have various amounts of bugs.

Frameworks will always limit what you can do, period, you will have to code around them once you want to do something they don't allow out of the box.

On the other hand, the less the framework does for you, the less limiting it is but in the same moment it also does less work for you.

By that definition every language has a runtime (yes, including C with crt0.o). Something has to set up the stack, enter the main() function etc. So how do you differentiate a systems language runtime? One that is bundled with the OS? Or is thin enough by some arbitrary measure?

How many people here subscribe to the "they're all DSLs" theory?

Not strictly about Go, but how is it supposed to impress that 'big company X' uses language Y (in this case the author uses Uber as if that's some kind of + for Go); I would be far more interested in the language + framework used to solve what level of complexity and scale problem with how many servers + people. If you can build & run something with less people and servers than your competitor and which makes you make more money, I think you have something in terms of framework and language. I think K/Q exists because of that and Janestreet uses Ocaml for that reason.

Also one should not forget that a company with 1000s of engineers is probably not you (yet); when you read that some company runs successfully on Node and saves $n amount of money by using it etc; when they have 1000s of engineers and devops on top of that it doesn't mean you can achieve the same (or any) success with it with 2 people. PHP for instance might be a much better choice with a small team; you don't need complex server setup, you don't need (or can handle) middle of the night alerts that require you to dive in vs just reboot the server etc.

At my job, before I joined, I was told we were torn between using Go and Rails and ended up with both. Now we have a Rails frontend (for web requests / authentication) and a Go backend (for business logic), which communicate over Thrift RPC.

I don't think it was a very wise decision because not only are you doing things twice, you're doing it three times, because you have to serialize/deserialize to/from Thrift for every request. It adds development time, more tests, and Thrift's binary protocol makes debugging RPC almost impossible.

This isn't really an argument for/against Go, but it just shows that you should try to avoid using multiple codebases that have to be tightly integrated. Personally, I would've gone with a Ruby-only codebase that used Thrift RPC only if there was some backend task that was too slow in Ruby, and that Go's concurrency and speed might be better at. Then I'd serialize it and send it over to be processed by a better language. I wouldn't do it for every request.

That being said, if I had the choice between writing an API in Go vs Rails, I would do it in Rails for the faster iterative development speed and quick debugging capabilities that is made possible by an interpreted language.