I am disapointed. Not very impressed. Sorry. I was expecting something bigger,better and revolutionary,but it didn’t happen.
If you mean the lack of low hanging fruit, if it were that easy Java would have had it. Try using the language for longer time and it may become clearer what the benefits are.
2 Likes
What would have made it more revolutionary for you?
I felt the same when I first met kotlin, but when I tried to use it, I fell in love with it. So I sugguest you give her some time to show
To me as a Java developer, Kotlin is currently technically the best alternative and has the lowest threshold of all alternative JVM languages.
I like the approach of pragmatically improving on Java’s quirks and legacy issues, basically what JetBrains do is take “Effective Java”, and implement support for everything mentioned in there directly in the language and the libraries… This is a non-academic approach that makes it easy for experienced Java developers to start being productive in Kotlin right away.
Without the need of completely changing your mindset, you will find that you will type less, get less errors, and write more expressive code from day 1 in Kotlin…
6 Likes
Indeed, the non-academic approach is what I like most. I personally don’t really want or need a ‘revolution’, as I find Java to be okay (especially when using a powerful IDE). Also agreed that spending time with Kotlin, especially on a ‘real’ project (something for work, etc.) is what reveals the benefits best. It’s so easy to enable Kotlin in an existing project if you have Gradle, which makes it very low risk to try it for a few months.
3 Likes
A few years ago I immediately fell in love with Scala. I still like this language for all its powerful and elegant concepts. But today I see many downsides of them
- everyone uses its own Scala style
- some incomprehensible APIs
- functional programing as a fetish (even if it makes little sense)
- tools struggling to understand Scala edge cases
- slow compile times
- you need much time to learn Scala
- sometimes tricky Java interop
- binary incompatibility between major versions (2.10 → 2.11)
And then compare that with Kotlin, where you get some nice productivity boosts without the downsides of Scala mentioned above. It is good to concentrate on really important features instead of implementing every language research feature available!
3 Likes
I agree,
I feel Scala too hard to write :\
major version 2
minor version 10
PS:
:\ is Scala operator
@medium - it was like I typed your thread entry. I am 100% with you on every point. Scala to me is like a brother in jail - love him - but don’t talk about him anymore. Back to @androidguru007 convincing of Kotlin - and the point has been made between the lines but here is my take.
When I develop, I develop for money - that means that academics is of little consequence if the tool works. If the tool increases productivity by being concise, easy (especially) easy on the eye, well structured, then it means that I can develop quicker, understand quicker, and maintain with less time spent. (keeping in mind that the academics are indirectly taken care of by Java to a large degree anyway)
And this is where Kotlin shines. It makes most natural things, natural again (property assignment etc), it runs without too much extras on the JVM, it shortens the code considerably vertically as well as horizontally, it removes the need for plenty of the punctuation, its closures feel much more natural - and it has a near perfect Java interoperability. All of which - to academics or to those looking for the next big thing is really not a big thing - but functionally as well as enjoyment in the code - big difference to me personally.
2 Likes
major version 2
minor version 10
Yes, I know, but the Scala devs somewhat redefined “major” and “minor” (I think they just used a macro or implicit conversion for redefinition 
).
1 Like
Couldn’t disagree with this more. As a java developer, I’ve wanted “java-lite” for a long time. Kotlin’s focused scope is what allows it integrate into existing java infrastructure so effortlessly. Something “revolutionary” would probably break your entire tool stack and be mostly of academic interest.
And to be frank, it’s quite rude to belittle the achievement of the Kotlin team when you don’t offer any constructive criticism or explanation in your post.
2 Likes
Take a look at ceylon if you want more features. Its type system is indeed revolutionary. It also fixes most of java failures still being a pragmatic language
Btw it can android too
Scala is something between Java and Haskell → neither Java nor Haskell.
If I want something more pure Haskell like I would check http://eta-lang.org/.
But https://www.lightbend.com/ did good think for Java, the bring http://www.reactive-streams.org/ .
Personally my favorite alternative for JVM languages is Groovy. But not because I would want to program in it. I like it because I can make it take a text file containing groovy code and have it parse and execute it at run time.
The main advantage of that capability from what I have done in the past was to create a bunch of Selenium code functions put it in a context variable e.g. c then pass that to a Groovy engine which reads a file from notepad.
Then with Maven shade plugin to jumble everything up into one .jar file.
What happens is the tester just needs to have the JRE installed on their computer and notepad, no IDE other complex tools.
They just start writing their scripts like
c.login("username", "password")
c.assertPage("Home")
c.click("New case")
c.takeScreenshot("new case.png")
c.assertPage("New case")
I think I can do the same with JRuby and Jython, but the advantage of Groovy is that it is more Java or C like for the less experienced people.
I’m curious what your experience was. I liked Kotlin for the almost one to one conversion from Java. However, I still “think in Java”, the key things that I found good in Kotlin are
- compile time null checking (in a way it forces you to think about it)
- lack of checked exceptions since it reduces boilerplate code.
However, null checking is usually something I would think about regardless, but that just comes with experience.
Checked exceptions may be annoying, but a lot of frameworks are already getting rid of it. Short of Java NIO and Concurrent which still have IOException and ThreadInterruptedException. There are still a lot of old baggage but those aren’t too bad to deal with once you know how. It could be worse that you didn’t think about it and at run time it just bombs the whole request. But then it is also worse when you have less experienced developers catching the exception and not doing anything with it or not chaining it up.
At the moment, my main qualm with Kotlin is tooling support, specifically in Eclipse with WTP which provides Java EE support. I guess it’s a way for us to be forced to pay for IntelliJ Ultimate Eclipse + Maven(M2E) + WTP with Kotlin
Because of the tool limitation and that also applies to almost every other JVM language not just Kotlin, I usually end up with Java because it is tested better.
1 Like
I believe it is not been done to impress anyone. In my opinion, the best thing is that there are no revolutions. Kotlin makes some java coding easier and that’s it. The most important thing is that it is two-way compatible with Java. Groovy is a great language, but dynamic typing is not always convenient and it in fact has only one-way compatibility with java (calling groovy from java sometimes is problematic).
1 Like
Kotlin 1.1 supports the javax.scripting API so I believe you can do the same with Kotlin. I have not done it personally, so can not offer any help in getting it to work.
See http://kotlinlang.org/docs/reference/whatsnew11.html#javaxscript-support
1 Like
I’m new to the Kotlin programming language. I spent many years with C and Java. Both are very good with flaws. Then I spent far too much of the last two years beating my head against the brick wall called Swift. Then I moved to Kotlin, and given the horrible experience I had with Swift, Kotlin is a very pleasant surprise. Yes it has some flaws which I won’t go into here, but it is today the best, most portable choice for a programming language for most programs that I deal with (millions of lines of code - both tools and higher level business applications). And yes, the metric “best” is my opinion for my programming world. When the Eclipse plug-in gets built to commercial quality (it has many holes and several bugs), it will get even better (again, IMO).
1 Like
I wouldn’t wait for the Eclipse plug-in to improve. Just make the cross upgrade and use IntelliJ.
A. Are you saying that JetBrains has no interest in fixing the Eclipse plug-in?
B. The programming staff I work with uses Eclipse for a variety of workflows, in several programming languages. For a variety of reasons, we have no interest in changing to IntelliJ. If we have to stay with Java to stay with Eclipse, we will. And if the real purpose of Kotlin is to lure programmers into the JetBrains camp (ie. bait and switch), no thanks.