News for hackers. Stuff that matters.
Re:Generating a Java program with 90% less code by marcus_holmes on Wednesday December 04, 2019 @11:57AM (#21703914)
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.

Re:Generating a Java program with 90% less code by jimbokun on Wednesday December 04, 2019 @12:05PM (#21704033)
> (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!

Re:Generating a Java program with 90% less code by pm90 on Wednesday December 04, 2019 @11:59AM (#21703945)
Go 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.
Re:Generating a Java program with 90% less code by kjeetgill on Wednesday December 04, 2019 @12:11PM (#21704114)
Interfaces 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.

Re:Generating a Java program with 90% less code by ickyforce on Wednesday December 04, 2019 @03:08PM (#21706376)
> 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.