3 ms·
I'm a little confused by the author's belief Go needs to be more pragmatic. All the points made in the "I Love Go" section (gofmt, the toolchain, interfaces) di
by dcw303 10y ago
I'm a little confused by the author's belief Go needs to be more pragmatic. All the points made in the "I Love Go" section (gofmt, the toolchain, interfaces) display strong qualities of pragmatism to me. The article literally describe interfaces as 'no-nonsense and pragmatic'. And, even if they do not personally like the opinionated nature, it is a prime example of solving questions in a practical way.
No language can be everything to everyone. One thing that encourages me to keep writing Go is the team has done a very good job at communicating their intentions for the language.
It's very clear to me when to write Go and when not to. That's a sign of strength to me, as it shows the language has the confidence to tell you "perhaps I'm not the best choice for this particular problem".
- tuxt 10y ago>It's very clear to me when to write Go and when not to. Would you care to elaborate on this? :)
- dcw303 10y agoMy main two use cases so far have been services and command line tools where it's not worth taking the effort to manage memory. The former I would have previously written in Java or C# (yeah, tie me to the cross right now language hipsters, I don't care, I already said I'm a pragmatist), and the latter in Ruby or Python. I actually enjoyed going from dynamic to static typing for command line tools, the compiler saves me a lot of time tracking down bone-headed errors, which are typos in variables 95% of the time.
- deleted 10y ago[deleted]