3 ms·

Go really just isn't designed for the same kind of service that PHP is normally used for. Its best at small API services (and, tangentially, its also pretty gre

by 013a 8y ago

Go really just isn't designed for the same kind of service that PHP is normally used for. Its best at small API services (and, tangentially, its also pretty great at CLI tools). > They were a little surprised to hear our stack involved Golang and some flat out told us they’d prefer PHP, because that’s what most of our products rely upon. I believe this is the real reason why, and everything else above it is pointless technical justification for a sound business decision. I also believe there's an unvoiced, even more powerful reason, in "I already know PHP and don't want to learn a whole new thing." These are both sound reasons. The technical justifications are not. Choosing Go for something like this was a bad decision. But choosing PHP is only slightly better. Opting for Django, Rails, or Phoenix would have better technical justification, but technical justification is rarely the real reason why we make decisions like these.

exceptione 8y ago
You are comparing frameworks with a language here. I think that if they choose to use a high-quality, modern php framework like Symfony, the technical decision would still make sense in the context of the alternatives you mentioned.
- 013a 8y ago
  That comparison is intentional, for one reason: Go doesn't have any "frameworks", let alone frameworks that are remotely comparable to the productivity offered by Symfony, Django, or Phoenix. The language actively opposes the development of tools like these. At best, we've got libraries that wrap net/http, io/ioutil, etc and moderately increase developer productivity, but there's nothing holistic and opinionated. The closest you can get is something like gRPC, but its not even the whole story, and it also relies on codegen so that's a disqualification in my book. This isn't just technical; its baked deep into the culture of Go. And that's fine. Its designed for something different.

by 013a 8y ago

exceptione 8y ago

You are comparing frameworks with a language here. I think that if they choose to use a high-quality, modern php framework like Symfony, the technical decision would still make sense in the context of the alternatives you mentioned.

013a 8y ago
That comparison is intentional, for one reason: Go doesn't have any "frameworks", let alone frameworks that are remotely comparable to the productivity offered by Symfony, Django, or Phoenix. The language actively opposes the development of tools like these. At best, we've got libraries that wrap net/http, io/ioutil, etc and moderately increase developer productivity, but there's nothing holistic and opinionated. The closest you can get is something like gRPC, but its not even the whole story, and it also relies on codegen so that's a disqualification in my book. This isn't just technical; its baked deep into the culture of Go. And that's fine. Its designed for something different.