I've been doing Kotlin on the backend for a while now, and I can't recommend it enough. One of the things that I really enjoy about the language is that it is _not_ a clever language. It's not trying to revolutionise PL theory, it just wants to get out of your way and let you get on with it. This shows up as the language being mostly worried about bringing well-understood modern conveniences into the Java world (interface delegation, property delegation, data classes, generic variance, type inference, etc).
On top of that "modernised Java" base, the language then adds only a small set of clever new features (mostly inline functions and receiver lambdas), and it leverages the hell out of those few features to produce a lot of value — e.g. there is no try-with-resource in Kotlin as a language construct. It's implemented as an inline receiver function that takes a receiver lambda as an argument.
When I think about language that gets out of my way for the backend I think Python. I really need to find time to dig deep into a language like kotlin to confirm or dispel my assumption that nothing else comes close to python for getting out of my way and letting me focus on the problem not the code.
An Android dev told me, it is between JS and Java, some low-level stuff is harder, but most day-to-day tasks are really simple and you can always fall back to Java if you like.
I have nothing against Kotlin, but we should be much more ambitious for the Next Generation of programmers. There's so much more progress to be made in (mainstream) programming languages than the tiny step from Java to Kotlin.
As it has always been in the history of programming, what it takes for this potential to come true is for the current generation of programmers to retire, leaving room for fresh paradigms.
Imagine if all the industry got one generation after Assembly language was "hey, we've made the instruction codes shorter and an IDE that can navigate to line numbers".
It's pretty sad that F# is sitting on the sidelines wondering what it did wrong to not get these accolades. I guess, "Being unable to enter a mobile ecosystem that's being held on a very old language runtime," is perhaps not the most desirable outcome for Android but dang if it hasn't worked out well for Kotlin's press.
People are going TO Kotlin as opposed to the usually Ocaml/F#/Haskell/Idris/Agda world of the community trying to bring people in.
A lot of this seems to be driven by Android developers who are locked into an older version of the JVM because of decisions Google has made. In other words, Kotlin is taking improvements from languages that target other environments (the CLR, native compilation or even newer versions of the JVM) and giving them to programmers who are stuck on a version of the JVM that isn't seeing any progress.
So Google has golang, which seems to be great for some kinds of server-side development. Then it backs kotlin which is great for android development, and also embraced by large server-side framework such as Spring. Then it has Dart for flutter and cross-platform mobile development.
We're now at the point where google has 3 very good programming language, each successful in their initial environment, but are necesseraly going to try to reach out to the other's languages territory. Flutter / Fuchsia is supposed to replace Android, Dart is very interesting for server-side development, and Kotlin aims at "worldwide domination" since it's based on the JVM.
That's exciting, but also very confusing if you want to find the good environment to specialize in.
I would wonder: is there any person with (enough of) experience with both Clojure and Kotlin to say how these two compare together as Java alternatives? Couple of years ago I was looking for "Java.next" and back then I chose Clojure. Needless to say I have been sooo happy with the language... Now for past year or so I have heard so much praise on Kotlin - it always came from Java devs and it seems like a great language with great support from IntelliJ and I am very enticed (but sadly have not enough time to play with it). So I'd wonder how this language is perceived by fellow people from Clojure community...
I have worked with both professionally for 3+ years so here are my 2 cents:
Kotlin is like buying a Volkswagen Passat after having a Golf. Clojure is like buying a BMW. The former is a reliable and solid workhorse, with a bit of charm. The latter is a powerhouse with flaws.
If I only evaluate them based on their merits on paper Clojure definitely comes out on the top.
The problem is that there are countless other factors. While Kotlin is just a Turbo Java, Clojure has a completely new paradigm.
With Kotlin I get an IDE which is superb, I get all the tools Java has. The interop is amazing.
With Clojure the only IDE which worked for me was Emacs but even that is a bit flawed. When I used Clojure I always had this mental overhead of fiddling with Emacs, the concepts of Clojure which are not inherent in LISP and so on.
In the end, I dumped Clojure for Kotlin because I don't see a future for Clojure. I can't get contributors for my open source projects for Clojure but with Kotlin they just come and do some pull requests. I can't get Clojure programmers in my home country because there are like 40 of them in the whole country and most importantly I can't convert Java programmers to Clojure programmers.
Kotlin, on the other hand, is not a big mental leap from Java and a lot of Java developers are excited about it. When I want to hire someone to work on a Kotlin project I can just bring in Java devs who are interested because they get up to speed in a matter of days.
The other problem with Clojure is that it has so much baggage over the basic LISP concept. It is not simple enough to pick up for most programmers with 0 FP experience. If I want a LISP I'd rather go for Racket which is actually simple.
Kotlin is basically a flavor of Java that cleans up some syntax quirks, and adds some new ones. I think it's overall a cleaner language than Java, but it's not fundamentally different from it. I certainly wouldn't view it as a next generation language.
I think it's important to step back and consider the history of programming languages to understand why mainstream languages look the way they do. Hardware was very limited in the 70s. The Intel 4004 CPU that came out in 1971 clocked in at 740 kHz, and it was coupled with a few kilobytes of memory.
So the language had to be optimized to squeeze every last possible bit of performance from this limited hardware. You didn't have to worry about concurrency, there weren't any consumer grade multicore CPUs, and networking wasn't prevalent at the time.
C solved that problem very well. It was effectively portable assembly allowing you to write extremely efficient code that could be compiled across different architectures. Meanwhile, advanced languages like Lisp required super computers at the time, and only a small number of people was lucky enough to work with them. So, a whole generation of programmers grew up on C, and they went on to design languages that look like C.
The problems we face today are completely different from those we solved in the 70s. We work with much larger codebases, we often work in teams, we have multicore chips, and networking is prevalent. Things like managed runtimes, GC, and threading that were absurdly expensive in the 70s are common today, but C family of languages aren't optimized to take advantage of that.
Raw performance is no longer a priority because developer time is far more expensive than hardware. This means that we need to optimize for clean and maintainable code that's concurrency friendly. Languages like Clojure and Haskell are a new breed of languages that are designed to solve modern problems, and that's the fundamental difference between Kotlin and Clojure in my opinion.
Kotlin is fundamentally a nicer Java. Clojure is a Lisp-like language on the JVM. They fulfil very different roles and promote wildly different styles. If you're genuinely happy with either, the other is unlikely to offer what you're looking for.
I prefer Clojure but if you need to develop for android then theres no decision to make, Kotlin wins. Being able to write the backend code for your android mobile app in the same language also makes Clojure less appealing.
I'm by no means an expert in either language, but for two years I learned / tinkered with Clojure as my main language for personal use. In 2015 I started a new job which required me to learn Kotlin. I've found that Kotlin has not only been a joy to work with ergonomically, but that its seamless interop with Java and the tooling make me far more productive than I could hope to be with Clojure.
I love Clojure and enjoy solving puzzles with it, but I can't seem to get anywhere near the level of productivity out of it like I can with Kotlin.
> One takeaway is that Kotlin is an exciting language, and one that makes developers happy.
Context? Probably "makes (Java) developers happy" due to dramatically reduced verbosity. But you get that in most, if not all other languages too. It's not called the Kingdom of Nouns for nothing.
It makes Android developers very, very happy because it brings features and fixes issues they have. They're stuck on a very old version of the Java spec, remember. They don't really have great options for other languages because of the huge amount of specialized executable optimization and processing required to ship on Android.
It'd be awesome if we could see a similar uptake in Eta or something like that. But it's unlikely, as making Eta equally efficient on Android will be a full on PhD thesis of work on top of a mountain of integration work JB finances to get the tooling perfect.
Anecdata: I've had three lifelong Python devs on our team independently tell me that they don't want to do Python anymore, after working in Kotlin for a month or two. It's really a great middle ground between Java and Python.
In terms of "niceness" I prefer Kotlin not only to Java, but also to C#; another language in which I've coded professionally, and one I hold in high regard.
Although there's certainly much less of a gap between Kotlin and C#.
The article talks much about how Kotlin is picked up disproportionally by younger developers. In addition to the obvious Android connection, this might also be because older Java developers are not only more content with Java (self selection: those not locked into Android development would have left Java for good a long before Kotlin came along if they wanted to), but also because many of those open for new languages but still tied to the JVM have already been spoiled and/or burnt by Scala.
Spoiled and burnt? I see a lot of potential overlap where one would have learnt enough Scala to perceive Kotlin as a step back, but not enough to permanently leave Java behind. From that perspective, Kotlin looks just like a pragmatic compromise. Immensely useful, perhaps, but not exciting at all.
I'm a long time Scala guy, and for some reason at the gigs I've been working at Kotlin is far more marketable than Scala. This confuses me, as the style of Scala we've been writing is almost identical to the Kotlin code.
At this point I'm chalking it up to 'better tooling', especially in IntelliJ. And underscores. People seem to hate underscores. Well, and the Google-stamp of approval I suppose.
Scala definitely does provide way more ways to overcomplicate your code, but with a dose of discipline it's quite manageable.
For me, Kotlin does feel like a step back. At the same time the fact that more people are enthusiastically adopting it means I spend less time selling and more time coding - so in that sense I'm actually a reasonably big fan.
There is no one language to rule them all, and there never will be. Compared to when I started in the early 80's there are enormous choices to pick from today. When I started I was allowed to pick any language I wanted as long as it was Fortran. So having new language choices today is a good thing, but it makes it very hard to pick. As an iOS programmer today I am glad to use a nice modern Swift. If I did Android I would likely chose Kotlin. If I did server side I would likely pick Rust or Go or Clojure or Javascript or Erlang or ... too many choices. Its not about the "next generation" its about picking something that works for you and your team/project and hope its not abandoned. No one language is going to be the Next Single Big Thing.
Kotlin is a nice language but being tied to jetbrains with no useable ide/editor around but jetbrain's own idea it won't rise that high. A working lsp language server would help.
Please excuse the tangent, but is there any programming language that has done away with the file as a basic organizing unit of code?
Whenever I consider PL ergonomics (as I do now, in connection with this article), files come to mind as an incidental inheritance of file systems past.
I think the Smalltalk systems that use image-based persistence[1] meet that criterion, despite the image itself eventually being persisted in a file system.
Do you have any alternative to files in mind? There are image-based systems like Smalltalk and some members of the Lisp family, but even in those cases, sources usually end up being stored long-term in files, as a matter of convenience.
In addition to Smalltalk, which was already mentioned, lisp and IIRC some implementations of forth also provided image-based development. Didn't really work out that well though.
I don't recoment Kotling becuase despite being Open Source it requires a proprietary closed source IDE to use it, they have plugin for Eclipse but it will be always a second class citizen and the free version (IDEA) cannot comapre to Eclipse. To me is just a trojan horse that is heavily marketed by Jetbrains, even for Android apps I'd recoment Dart with Flutter over it.
> First off, I was genuinely surprised by the love students and more junior developers are giving Kotlin.
This seems to indicate that the "love" Kotlin gets is mostly fad motivated. Just like younger generations reject the haircuts and "cool" slang the older generation uses, the same younger generations reject older programming languages in favor of fashionable, glamorous, new ones.
Java went from being THE trendy fad language to the old fogey that everyone mocks and derides.
The part you quote is followed by: "I was expecting a bigger difference between more/less experienced developers, ..."
So the article is saying that there is lots of Kotlin love from experienced developers (and this is as expected) but they were suprised to also see similar results with junior developers and students.
The text of the survey resluts page (linked in the article) makes the same point somewhat more clearly:
"In its early days Kotlin was being picked up mostly by experienced and professional developers, but since the announcement its usage has exploded with newer developers, especially students."
This explanation seems to get thrown at every new programming language. Maybe Kotlin is a fad, maybe it's not (I've never used it and don't have an opinion)--either way, comments like this one aren't very insightful or convincing.
After using scala, it was hard to go back to Java. After learning Kotlin and reading others scala code I don't see myself using any other JVM language besides Kotlin unless I'm forced to. I never minded Javas verbosity because I liked the type safety, but after experiencing languages without it java just becomes annoying to right. Scala was great initially, but because they put every concept ever thought of into the language it becomes a mess because people pick and choose from all the esoteric options. Kotlin is a happy middle ground to me.
It does but it also appeals to experienced devs. One person made a point how it allows Android devs to use a wider toolset than the current restricted Android JDK allows. Personally, I've used Java for Android dev for 2 years and Kotlin feels like a breath of fresh air, just like Obj-C to Swift transition.
[+] [-] pdpi|7 years ago|reply
On top of that "modernised Java" base, the language then adds only a small set of clever new features (mostly inline functions and receiver lambdas), and it leverages the hell out of those few features to produce a lot of value — e.g. there is no try-with-resource in Kotlin as a language construct. It's implemented as an inline receiver function that takes a receiver lambda as an argument.
[+] [-] Waterluvian|7 years ago|reply
[+] [-] k__|7 years ago|reply
Sounds nice.
[+] [-] unknown|7 years ago|reply
[deleted]
[+] [-] valw|7 years ago|reply
As it has always been in the history of programming, what it takes for this potential to come true is for the current generation of programmers to retire, leaving room for fresh paradigms.
Imagine if all the industry got one generation after Assembly language was "hey, we've made the instruction codes shorter and an IDE that can navigate to line numbers".
[+] [-] KirinDave|7 years ago|reply
People are going TO Kotlin as opposed to the usually Ocaml/F#/Haskell/Idris/Agda world of the community trying to bring people in.
[+] [-] cwyers|7 years ago|reply
[+] [-] pjmlp|7 years ago|reply
And even for Java 8 you need a latest Oreo device, because not everything can be desugared into Java 6.
There is also the issue that going forward Java 9+ libraries won't be possible in Android.
So the only way forward appears to be indeed Kotlin and Kotlin specific libraries.
[+] [-] jayd16|7 years ago|reply
Switching languages only helps the syntax. If the Android Runtime can't do something it that means it can't do it in Java or Kotlin.
[+] [-] bsaul|7 years ago|reply
We're now at the point where google has 3 very good programming language, each successful in their initial environment, but are necesseraly going to try to reach out to the other's languages territory. Flutter / Fuchsia is supposed to replace Android, Dart is very interesting for server-side development, and Kotlin aims at "worldwide domination" since it's based on the JVM.
That's exciting, but also very confusing if you want to find the good environment to specialize in.
[+] [-] dgritsko|7 years ago|reply
[+] [-] newcrobuzon|7 years ago|reply
[+] [-] edem|7 years ago|reply
Kotlin is like buying a Volkswagen Passat after having a Golf. Clojure is like buying a BMW. The former is a reliable and solid workhorse, with a bit of charm. The latter is a powerhouse with flaws.
If I only evaluate them based on their merits on paper Clojure definitely comes out on the top. The problem is that there are countless other factors. While Kotlin is just a Turbo Java, Clojure has a completely new paradigm.
With Kotlin I get an IDE which is superb, I get all the tools Java has. The interop is amazing.
With Clojure the only IDE which worked for me was Emacs but even that is a bit flawed. When I used Clojure I always had this mental overhead of fiddling with Emacs, the concepts of Clojure which are not inherent in LISP and so on.
In the end, I dumped Clojure for Kotlin because I don't see a future for Clojure. I can't get contributors for my open source projects for Clojure but with Kotlin they just come and do some pull requests. I can't get Clojure programmers in my home country because there are like 40 of them in the whole country and most importantly I can't convert Java programmers to Clojure programmers.
Kotlin, on the other hand, is not a big mental leap from Java and a lot of Java developers are excited about it. When I want to hire someone to work on a Kotlin project I can just bring in Java devs who are interested because they get up to speed in a matter of days.
The other problem with Clojure is that it has so much baggage over the basic LISP concept. It is not simple enough to pick up for most programmers with 0 FP experience. If I want a LISP I'd rather go for Racket which is actually simple.
[+] [-] yogthos|7 years ago|reply
I think it's important to step back and consider the history of programming languages to understand why mainstream languages look the way they do. Hardware was very limited in the 70s. The Intel 4004 CPU that came out in 1971 clocked in at 740 kHz, and it was coupled with a few kilobytes of memory.
So the language had to be optimized to squeeze every last possible bit of performance from this limited hardware. You didn't have to worry about concurrency, there weren't any consumer grade multicore CPUs, and networking wasn't prevalent at the time.
C solved that problem very well. It was effectively portable assembly allowing you to write extremely efficient code that could be compiled across different architectures. Meanwhile, advanced languages like Lisp required super computers at the time, and only a small number of people was lucky enough to work with them. So, a whole generation of programmers grew up on C, and they went on to design languages that look like C.
The problems we face today are completely different from those we solved in the 70s. We work with much larger codebases, we often work in teams, we have multicore chips, and networking is prevalent. Things like managed runtimes, GC, and threading that were absurdly expensive in the 70s are common today, but C family of languages aren't optimized to take advantage of that.
Raw performance is no longer a priority because developer time is far more expensive than hardware. This means that we need to optimize for clean and maintainable code that's concurrency friendly. Languages like Clojure and Haskell are a new breed of languages that are designed to solve modern problems, and that's the fundamental difference between Kotlin and Clojure in my opinion.
[+] [-] swsieber|7 years ago|reply
My impression is though that Kotlin really just tries to make a less painful Java, whereas Clojure is a better/nicer JVM language.
[+] [-] pdpi|7 years ago|reply
[+] [-] Scarbutt|7 years ago|reply
[+] [-] iammiles|7 years ago|reply
I love Clojure and enjoy solving puzzles with it, but I can't seem to get anywhere near the level of productivity out of it like I can with Kotlin.
[+] [-] poe876|7 years ago|reply
[deleted]
[+] [-] DrBazza|7 years ago|reply
Context? Probably "makes (Java) developers happy" due to dramatically reduced verbosity. But you get that in most, if not all other languages too. It's not called the Kingdom of Nouns for nothing.
[+] [-] KirinDave|7 years ago|reply
It'd be awesome if we could see a similar uptake in Eta or something like that. But it's unlikely, as making Eta equally efficient on Android will be a full on PhD thesis of work on top of a mountain of integration work JB finances to get the tooling perfect.
[+] [-] flavor8|7 years ago|reply
[+] [-] V-2|7 years ago|reply
Although there's certainly much less of a gap between Kotlin and C#.
[+] [-] pjmlp|7 years ago|reply
[+] [-] usrusr|7 years ago|reply
Spoiled and burnt? I see a lot of potential overlap where one would have learnt enough Scala to perceive Kotlin as a step back, but not enough to permanently leave Java behind. From that perspective, Kotlin looks just like a pragmatic compromise. Immensely useful, perhaps, but not exciting at all.
[+] [-] switchbak|7 years ago|reply
At this point I'm chalking it up to 'better tooling', especially in IntelliJ. And underscores. People seem to hate underscores. Well, and the Google-stamp of approval I suppose.
Scala definitely does provide way more ways to overcomplicate your code, but with a dose of discipline it's quite manageable.
For me, Kotlin does feel like a step back. At the same time the fact that more people are enthusiastically adopting it means I spend less time selling and more time coding - so in that sense I'm actually a reasonably big fan.
[+] [-] coldcode|7 years ago|reply
[+] [-] stewbrew|7 years ago|reply
[+] [-] tiuPapa|7 years ago|reply
[+] [-] distances|7 years ago|reply
[+] [-] zan|7 years ago|reply
[+] [-] fnordsensei|7 years ago|reply
Whenever I consider PL ergonomics (as I do now, in connection with this article), files come to mind as an incidental inheritance of file systems past.
[+] [-] sls|7 years ago|reply
[1] https://en.wikipedia.org/wiki/Smalltalk#Image-based_persiste...
[+] [-] igouy|7 years ago|reply
http://home.balcab.ch/jpelrine/download/ss99.pdf
[+] [-] igouy|7 years ago|reply
https://www.oracle.com/corporate/features/understanding-java...
[+] [-] TeMPOraL|7 years ago|reply
[+] [-] stewbrew|7 years ago|reply
[+] [-] adrianlmm|7 years ago|reply
[+] [-] weitzj|7 years ago|reply
The current state, as I see it, is: Developers learn Kotlin, not Beginners
So it is not easy to find good learning material to start as a beginner into programming with Kotlin as your first language.
If you have some resources for me that would be nice - so I can convert more people.
[+] [-] AlexeyBrin|7 years ago|reply
[+] [-] throwme_1980|7 years ago|reply
[deleted]
[+] [-] ythn|7 years ago|reply
This seems to indicate that the "love" Kotlin gets is mostly fad motivated. Just like younger generations reject the haircuts and "cool" slang the older generation uses, the same younger generations reject older programming languages in favor of fashionable, glamorous, new ones.
Java went from being THE trendy fad language to the old fogey that everyone mocks and derides.
[+] [-] zellyn|7 years ago|reply
But the language itself never seemed “cool” — it horribly verbose even from the start. In fact, it's much better now than it was.
[+] [-] ptx|7 years ago|reply
So the article is saying that there is lots of Kotlin love from experienced developers (and this is as expected) but they were suprised to also see similar results with junior developers and students.
The text of the survey resluts page (linked in the article) makes the same point somewhat more clearly:
"In its early days Kotlin was being picked up mostly by experienced and professional developers, but since the announcement its usage has exploded with newer developers, especially students."
[+] [-] weberc2|7 years ago|reply
[+] [-] justaman|7 years ago|reply
[+] [-] bogwog|7 years ago|reply
[+] [-] Larrikin|7 years ago|reply
[+] [-] otachack|7 years ago|reply
[+] [-] pjmlp|7 years ago|reply
There is partial support for Java 7 and 8, but it is a matter how many Android versions one wants to target.
Don't forget Java is not only the language, rather standard APIs, bytecodes and .class formats.
Also it doesn't appear Android will ever move beyond Java 8.