3 ms·
Yeah this is exactly the stuff that you'll have to reinvent yourself on an ad-hoc basis in any sufficiently large project. I would argue it's sorta related to
by treyd 1y ago
Yeah this is exactly the stuff that you'll have to reinvent yourself on an ad-hoc basis in any sufficiently large project.
I would argue it's sorta related to Greenspun's tenth rule: https://en.m.wikipedia.org/wiki/Greenspun%27s_tenth_rule https://en.m.wikipedia.org/wiki/Greenspun%27s_tenth_rule
Of course, you'll probably retreat and say "Go is better for small projects", but every large project started as a small one, and it's really hard to justify rewriting a project in a new language in a business context.
- samdoesnothing 1y agoYou don't need a hierarchy of abstract classes, dependency injected implementations, nested pattern matching with destructuring, etc for any project. If one decides to implement these techniques in an ad-hoc basis in Go to solve problems, that's more to do with trying to apply principles and techniques from other languages in Go.