Hacker News Reader

Comment by wazoox | Hacker News Reader

Well maybe, but the Steve Yegge wrote this:

https://steve-yegge.blogspot.fr/2017/05/why-kotlin-is-better...

Obviously these guy love Java. This, frankly, I can't understand. I've hated Java for 20 years :) However if you love Java, obviously you don't need to switch to Kotlin. If like 99% of people used to leaner languages, you find Java unbearably verbose, ugly, etc. Kotlin is a godsend.

View on HN

Agreed. A lot of this has to do with where you came from and what you were used to previously.

I initially switched to Java in the late 90's from C++. At that time, C++ was just achieving (imo) its densest, most arcane features that were making me crazy. What I really wanted was a C+- or something that didn't force a bunch of stuff I didn't need on me. Java was exactly what I needed at that point.

After 15-20 years of Java, I recently switched to full time Javascript development and woah! It was like the freshest breath of fresh air. What, no types if I don't want them? Closures and protoype inheritance? Yes, Omg!

Imagine my dismay when I was first introduced to TypeScript! My code looked just like Java again. :( Seriously, I understand the reasoning behind TS and getting into it a little further convinced me it wasn't too bad after all. Again, what are you used to has a lot to do with your state of mind as a dev.

Any language that lets developers express their intent in the way they like is great. Kotlin, Scala are like the JS & TS of the Java world. All good (as long as they work!).

In case you haven't played with it, you may find that you like Groovy for writing Java in a JavaScripty fashion.

I have a ton of JS experience, and one thing that has continued to pain me with Java has been the arcane incantations required for Async and Closures.

I'd used Groovy just a little bit here and there for Jenkins stuff, but I finally looked into while building a DSL for our company. Closures are first class, typing is generally pretty optional, and you can use just about any Java library. When in doubt, you can always just write plain old Java.

I've become a huge fan, though I haven't started introducing any Groovy to my existing Java projects as they're mostly Maven built, and I don't really want to rock the boat.

Speaking of Kotlin and JetBrains, IntelliJ has pretty good support for Groovy, and follows @Delegate annotations very well for hinting and IntelliSense. I made my entire DSL type hintable with like four annotations and a 4 line GDSL file.

I'm curious what you mean here with the implication that you couldn't simply add Groovy code to your existing apps built with Maven. Have you tried it?

It has been probably over 5 years but when I was writing a lot of Java and Groovy, we were standardized on using Maven at that company. The Groovy Maven plugins worked and I had several projects with various mixtures of Groovy, all built with Maven: from Java with Groovy tests, to Groovy and Java throughout, to pure Groovy web services. It was a bit of a pain getting the configuration set up initially but it worked well.

What I didn't say was that my only experience so far is with Groovy by itself, and using Gradle to build. It's not an implication of Groovy or Maven for not supporting it, it's that I don't know the right way to do it yet.

You can mix Java and Groovy with Gradle as well. This might help: https://stackoverflow.com/questions/22369033/how-to-use-grad...

I haven't used Maven in a long time and I'm not sure what is the state of the Groovy Maven plugin. Writing unit tests in Groovy for your Java projects is a great, low risk way to get things working.

It still works if you use the groovy-eclipse plugin in Maven, otherwise no. A lot of the Groovy interop tooling has fallen behind in 2017. For example, the developers I work with who use Eclipse could not run Spock tests because the plugins for 2.5 are busted. If you use IDEA you are still gtg.

> typing is generally pretty optional

Don't use Apache Groovy in typed mode -- hardly anyone else does, and you won't find any typed Groovy in its own codebase, only Java. Groovy was originally built as a JS-style dynamic language and is best used in untyped mode.

Fwiw, I use @CompileStatic it extensively and find it pretty good. There are the odd times when it generates a bizarre failure that I can't solve, but they are rare enough that I don't mind. I recently converted a whole project from Groovy to Scala hoping for performance benefits and found that my dynamic Groovy sprinkled with a few static compile hints ran faster than the Scala version. By the time I got the Scala version to the same speed as the Groovy version it looked a lot less like idiomatic Scala than the typed Groovy looked like idiomatic Groovy. So overall pretty happy with it, and I hope they keep improving it.

Most developers will use known code samples (e.g. Groovy's lack of statically compiled Groovy in it's own code base) rather than anonymous claims (e.g. you using @CompileStatic extensively) when deciding on a programming technology.

I had the opposite experience - nearly a decade of Ruby and JavaScript, switched to Java and felt like I could finally breathe again! Not that it doesn't have its annoyances, but I sleep a lot better at night now. Kotlin (and TypeScript for that matter) seem like they cut out some annoyances while keeping everything that makes me breathe easier.

I think the difference is with typescript you can gradually type things or just us any when you don't want too. You get the best of both worlds IMO.

I'm more excited about using typescript def files in my JS code for third party libraries than I am using Typescript itself. What I really want is code completion and type hints

The problem with Yegge's post, is he opens up with these arguments:

"Unfortunately -- for long complicated legacy reasons that nobody cares about -- some of Android's core APIs really are bad. I mean baaaaad bad. Shut the book, take a deep breath, and go out for coffee bad."

"It turns out the perfect killer app here -- and this brings us full circle -- is Android's crappy Red Light APIs."

He then concludes with:

"Kotlin manages to help you route around just about all of Android's Red Lights, and turns the experience into something that on the whole I now find superior to iOS development. "

... but offers no compelling reason how Kotlin supports this conclusion.

Try it and you'll see.

i didn't get any sense that they loved java - note that none of their (very fair!) caveats dealt with kotlin as a language, just with the undeniable fact that the tooling ecosystem was a lot more immature than java's, and could cause you unexpected problems.

His entire post basically boils down to:

"It's like Java" and "It's got one hell of an IDE"

Um, okay. I guess?

There are other languages that are "like Java", and they don't count?

So, basically all it takes to get a language adopted is a snazzy IDE? Wow. I guess we need to remember to design new languages to optimize for IDE integration rather than actual programming.

Reply on news.ycombinator.com