3 ms·
> we need better tools Sure, and the "right tool for the right job" is still my mantra. Go is a very good at solving for an incredible amount of tasks in many
by xyzzy_plugh 7y ago
> we need better tools
Sure, and the "right tool for the right job" is still my mantra. Go is a very good at solving for an incredible amount of tasks in many problem spaces. Users will always want to bend tools to work in new places, and that's okay -- sometimes it isn't a fit.
Have some business requirements that make using Go a chore or a pain? Use a different language, or restructure the requirements.
- meddlepal 7y ago> Have some business requirements that make using Go a chore or a pain? Use a different language, or restructure the requirements. That's such a cop out answer when our industry is basically doing fad-oriented engineering. It's great when you can greenfield build a project but when you're taking over a project the selection of language has usually been decided. Or you know the management team has decided for hirability reasons to use X. Or just legacy requirements don't match reality eventually. This is why we need more expressive languages than Go. Requirements change over the course of a projects life and what made sense in year 1 rarely makes sense several years later.