4 ms·
ditto for Go. Huge fan, but it does involve a lot of boilerplate. Not that I think that's a bad thing. I prefer it to "magic" (I never got on with Rails becaus
by marcus_holmes 7y ago
ditto for Go. Huge fan, but it does involve a lot of boilerplate.
Not that I think that's a bad thing. I prefer it to "magic" (I never got on with Rails because of this... what just happened? why did it do that? where does it say it should do that?).
And you never know when you have a class/use case that needs the boilerplate to change. Having it the same 99% of the time so that you have the option to change it for that 1% edge case is a good thing, imho.
- pm90 7y agoGo seems to have much less boilerplate than Java. I’m really glad that OOP was explicitly unsupported and the language designers opted for using interfaces instead.
- kjeetgill 7y agoInterfaces are as much a part of OOP as inheritance. Go is as OOP heavy as Java. They differ mostly in how/when an "class" is bound to an interface. Java declares up front, Go does this implicitly at usage sites aka static duck-typing (which is great!). That said, I think OOP education focused a lot on inheritance during Java's rise and that was mostly a mistake in hindsight.
- ickyforce 7y ago> Go seems to have much less boilerplate than Java Maybe if you compare to Java from 10y ago. Have you ever tried to print a map in an alphabetical order of its keys? The only thing more verbose in Java are getters/setters which hopefully will disappear once records are available.
- jimbokun 7y ago> (I never got on with Rails because of this... what just happened? why did it do that? where does it say it should do that?) With Spring you get to ask all these questions...with all the boilerplate of Java as an added bonus!