3 ms·

> For me it was like going back to being 8 years old on my Commodore Plus/4 and really enjoying writing code again. Your comment is the problem with the Go com

> For me it was like going back to being 8 years old on my Commodore Plus/4 and really enjoying writing code again. Your comment is the problem with the Go community. I have seen a number of comments from Golangers that they want a "fun" language that helps them reminisce about the past. They also want to write a lot of senseless boilerplate because for them more typing is somehow about them reliving their past. And tracking down nil pointers... and writing containers for every concrete type. The simple fact is software development has gotten more complex because business requirements have changed and Go does a poor job of addressing that with its limited feature set. The rest of the programming world has accepted that we need better tools whether it be toolchain stuff or language features. Hate on Java all you want but at least it, like most other non-Go languages, has realized the need for better tools in the toolbox.

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.

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.