The case against Kotlin
medium.com
medium.com
But it's smarter Java. It gets out of your way. If you understand Java, the 1:1 mapping between Kotlin and Java is trivial. I can tell you what the auto-generated Kotlin code from the IntelliJ helpers is gonna look like when you convert Java to Kotlin and it's just...obvious? The only thing I have ever had even the slightest trouble with was how to take a var (which I understood immediately to be a backing field with getter/setter methods under the hood, both because the doc says so and because IDEA says "from getFoo/setFoo" when importing Java so it's an obvious intuitive leap) and apply a Hibernate Validator attribute only to the getter. It was a hole in the docs at the time, but I figured it out: `@get:Something()`. If that's the only thing that gets an experienced but largely out-of-the-game Java developer a little head-scratchy, this should be a slam-dunk type of thing for somebody who writes Java every day.
Maybe it's harder for Android. (I think you should write React Native for Android for basically anything you can--and I have, I released a Google Play app a couple weeks ago that I really should get around to marketing--because while I am down with Kotlin,I also like being able to actually share code everywhere.) But Java-to-Kotlin is a no-brainer, in my book, at literally any Java shop not targeting, like, Java one-dot-ancient.
> This requirement is a willful violation of RFC 5322, which defines a syntax for e-mail addresses that is simultaneously too strict (before the "@" character), too vague (after the "@" character), and too lax (allowing comments, whitespace characters, and quoted strings in manners unfamiliar to most users) to be of practical use here.[0]
[0] https://www.w3.org/TR/html5/forms.html#e-mail-state-(type=em...
[1] this assumes programmer skill is normally distributed, which I doubt.
Median. It can happen that 90% of programmers literally better than the average.
While mathematically true, in practice almost impossible
Nobody cares.
I mean, look at JSX, which is just JavaScript. Coming from all the crap templating languages pulled off the last 10 years it is basically god sent. Still people hate around and they always will, that's what we do, we lern stuff and if it gets obsolete, we want to keep it because it fed us for years.
Scala was treated for a long time as "a better Java"; but Kotlin really is way more befitting of the title. There shouldn't be as much resistance.
Kotlin on the other hand, really is a better Java. If you take Java, remove all the biggest day to day headaches, change around the defaults to be sane (I.E. the default is what you want 90% of the time, instead of the other way around), and add in some functional inspired helpers, you basically arrive at Kotlin. The delegate system, the way they finally got rid of the need to make pointless getters and setters on the off chance you might some day want them and not want to refactor your entire codebase, making classes and methods public by default since that's what you want almost always, and making types non-nullable by default are all MAJOR improvements over Java, but not something completely alien to the Java way of doing things.
First, it took a little time to get the hang of json manipulation. We got to a solution we liked, but a dynamically typed language like groovy has some advantages there.
Closed classes by default can make some testing a little more difficult. We have continued using Spock rather than moving our tests to Kotlin, and there are a few places where we compromise our design until we can figure out a better way. (Yes. Dependency Injection and less coupling is the answer, alongside adding a level of abstraction in between third parties. The devil is in the details.)
In general, we like it and are planning on expanding our use, but conversion has had its challenges.
Does it? I really prefer JSON.NET's approach, which involves declaring models that represent your JSON, over dynamic "hope it's there" approaches.
Was gonna say what you did about testing, but you have it, so, yeah. ;)
[1] https://kotlinlang.org/docs/tutorials/mixing-java-kotlin-int...
We had the same hope for Scala - the idea being that the developers who were interested in using it functionally could do so in the more complicated parts of our application, but the 'rest' of the developers, many who were honestly either not capable or just not interested in picking it up, would be able to still use traditional Java.
Unfortunately, Scala just had too many incompatibilities: things like Options instead of null or to call a Scala method in Java would require some confusing method call like new Function0<String> because that is how Scala converts to bytecode.
And collections and immutable types never really worked back and forth very well.
The final straw was when we had Thrift interfaces that simply broke if a project moved from Scala 2.10 to 2.11 without recompiling all the dependencies.
But if Kotlin really is completely compatible with Java without too many show stoppers dragging down productivity, this could be helpful for a lot of larger enterprise shops which contain a small subset of engineers who want and can use the language to improve things (or simply don't want to work with old Java code and will jump ship if forced to do so), but still need to keep things simple enough so that the rest of the team can still be productive.
`val` in Kotlin creates an (inaccessible, except via reflection) backing field and a bean-compatible getter. `var` the same, but with a setter. Stuff like that. It works incredibly well.
I'm a solo developer, and I use K and J together on most codebases (about 10), and at this point I only ever create K files.
Regarding interop, I think it's a valid claim that K is 100% J compatible.
I think instead of arbitrarily mixing the two, maybe start with a single module, or with testing.
I write a lot of JS, and have been planning on trying out Kotlin with JS, because at this point, taking a JS function and converting it to Kotlin results in code that's between 70-80% Kotlin (const to val, add return types, etc.)
I'm personally convinced that Kotlin is a good language to learn if you know Java.
More concretely, Scala actually had very little in common with Java. Yes it ran on the JVM, but that was where the similarities stopped, its functional layer and type system were effectively incompatible with Java or the Java standard library. Actually Scala was so badly made, its functional pieces weren't even really compatible with its own OO pieces, if you tried to mix and match the two it caused all kinds of problems. Kotlin in contrast is almost entirely compatible with Java. There are a couple rough spots, mostly around when frameworks depend very heavily on reflection and bytecode manipulation (particularly around annotations), but those can be worked around from both sides without too much trouble, and the rest of the time it's pretty much completely transparent.
Are engineering teams at Pinterest really so weak that going from Java to Kotlin—an extremely similar language—is a major hurdle? The entire mindset of this article is alien to me.
I asked him what he used if he just wanted to write a quick little script. "Objective-C."
There's something to be said for his kind of mastery of a single language, but it was different from the multilingual culture I'm used to.
I wonder if he's using Swift now...
The problem is that the ecosystem is what matters nowadays. A language can suck donkey balls and win as long as it has a robust ecosystem (see: VB6, PHP, etc.)
Python and Rust have phenomenal ecosystems. I have no clue about the C++ ecosystem nowadays.
CoffeeScript simply made the shortened term more popular, but the use of a more specific term is nothing to get irritated about.
Some context I think might not have made it to the Hacker News readers. We use Kotlin at Pinterest, we were one of the two teams talking about the value of Kotlin when google announced support at IO https://www.youtube.com/watch?v=fPzxfeDJDzY.
The article is meant to show the reasons we considered not to use it. The language is very similar to Java and we've written some about how even "the grumpy java developer" can learn it https://medium.com/@Pinterest_Engineering/kotlin-for-grumpy-....
We don't expect to be able to hire Android engineers that are familiar with Kotlin to the level of expertise we expect with Java. We do expect everyone to be able to work with any part of the Android code base and not be guessing at how of the concepts many android devs aren't familiar with work. If you don't consider the time for engineers to learn this, you are not considering some of the cost of adopting. If you think it's not that big of a deal, then go for it, we did.
Introducing a new language to an organisation is completely different from the above and it's nice for a change to see blog posts that also consider the long-term sustainability of a solution, maintenance costs, potential staffing and training difficulties, etc. These are things that are very important for a mature project.
Normally, I wouldn't even think about using a language developed and championed by a litle Czech company, however, JetBrain's tooling is incredible and I gladly give them money every month for R#.
On the other hand, usually I would think that the language being endorsed by a major company for their platform was a big plus, but the way that Google drops products and initiatives, their support means little.
So yeah, I trust JetBrains a lot more than I trust Google and if I ever decide to bite the bullet and start developing for Android, Kotlin will be my first choice.
Some of my most used patterns
1. Create a class
2. Type ctor + tab - create a constructor (VS)
3. Type a parameter type and a variable (R# auto completes with a reasonable name)
4. Type Alt+Enter+Enter. R# creates a private class field and assigns the parameter to the private field
----
I need to create an equality operator for a class. This is the standard c# pattern:
https://msdn.microsoft.com/ru-ru/library/ms173147(v=vs.80).a...
It's tedious. R# does this with one shortcut -> Generate Code -> generate equality comparer and then it gives you a choice of which properties should be part of the equality comparison
---
You need to quickly create an override of .ToString() maybe you just want something friendly during debugging. Say you have 10 properties. Again, that's Generate Code -> create formatting member.
----
Say your class has gotten to big and you see some methods that should be their own class.
Refactor -> Extract class.
And it will automatically create a reference to the extracted class
----
Say you have a base class and your inherited class has some members that should be in the base class or the interface.
Refactor-> Move members up
----
You have a method that has too many members and you want to create an object that encapsulates your parameter list into an object. R# can do that for you and change all of your usages throughout your code base to use your new class.
---
What if you decide to "prefer aggregation over inheritance" or you have a sealed class that can be inherited and you want to make it inheritable by doing a wrapper class.
Generate Code -> Create delegating members.
----
Say you wrote a foreach loop and realized you needed a for loop:
Alt-enter convert foreach to for
---
Say you wrote some Linq code that would be clearer imperative -> there is a shortcut for that too.
---
What if you really hate Microsoft's test runner and prefer Nunit -R# has got you covered.
----
This list doesn't include all of the other random niceties:
-Fixing namespacing throughout your project with one click
-suggesting coding standards
-Ctrl-T for universal search
-convert code to Linq expression
-safe parameter removal
-navigation shortcuts
-warns of unused classes and is smart enough to know if you're using a class via convention based Dependency Injection (i.e. automatically use Foo when a constructor asks for IFoo)
-Asp.net MVC has a lot of "stringly typed" conventions for specifying controllers and actions that will only give you runtime errors not compiled time errors R# is smart enough to know when you are using an invalid Controller/Action combination.
-extract method, extract class, extract variable and the inline reverse of all of the above.
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.
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!).
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.
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.
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.
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.
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
"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.
"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.
> If you’re going to use Kotlin in your code base, you’ll need to teach almost every developer on your team how to use it.
Not true. Java and Kotlin can be used on the same project and Kotlin also has seamless Java interop. If you don't want to write Kotlin you don't have to. It is also easy to read for other devs so readibility is not an issue.
Then the writer goes on and on how the velocity is affected by learning Kotlin but misses the point: you don't have to burn any bridges by using it.
> When I realized very few developers actually saw the developer velocity gain, I was left with a bit of a, “so what’s the point” feeling.
Then the op should question the capabilities of his developers. I came from a Java background and after several weeks of Kotlin exposure my productivity skyrocketed. It helps if you have some FP background but you can learn it on the way. Currently the whole team writes Kotlin code and looking back at previous sprints I can say that the velocity increased by a double digit percentage.
> Kotlin accounts for about 25 percent of our clean build time and 40 percent of our incremental build time.
Then the op has some serious Gradle configuration problems. We also had this then tweaked Gradle (upped the version, started using parallel builds, etc) and now the difference is minimal. You are also better off with tools like JRebel even if you work with Java.
> Not being familiar with Kotlin, the developer immediately assumed Kotlin was causing the problem and lost time investigating what was a simple fix. This “weirdness” combined with the actual stability issues means there’s significant maintenance time lost.
I've been using Kotlin for more than a year and I only had a single stability issue (and it was an IDEA plugin problem). Kotlin works amazingly well with other libraries and after using it for several months I felt that I never want to go back to Java.
Maybe the op's issues are with the Android ecosystem or a bad development team, and not with Kotlin itself since we use it on the backend and we don't see the problems mentioned in the article.
The only valid point I've seen in the article is the lack of static analysis tools and as the article states it will get better.
Until you have to trace a bug through both codebases.
Dual interop codebases never work. A computer language simply takes up too much mental space to know even one language well and stay up-to-date on it.
Yes, I know there are exceptions, but I have yet to actually meet and work with one.