Rise of Kotlin: A Programming Language for the Next Generation(hackernoon.com)
hackernoon.com
Rise of Kotlin: A Programming Language for the Next Generation
https://hackernoon.com/rise-of-kotlin-the-programming-language-for-the-next-generation-27beeb529204
149 comments
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.
Kotlin is very much meant to operate at the same level of abstraction as Java, which is a fair bit lower-level than Python. If you don't need to work at that lower abstraction level, Python will still feel a bit nicer. Kotlin definitely closes some of that gap, though.
Kotlin gives you enough metaprogramming and syntax sugar to feel a rung above Java. You can pack a lot into a short line (list / map literals, compact map / fold / iteration, elvis operator), so it feels to me much closer to Python than Java 8 ever did.
If you're working in a small enough team (or solo) or a young codebase I think you won't see a ton a lot of value a basic type system can bring. I say this with experience with both Java and Python but not Kotlin.
Reading old undocumented code and refactoring it confidently is wildly easier with Java than Python. The structure provides obvious moves and shifts and reason about code you haven't fully read yet. Even with relatively clean Python (i.e. No messing with scopes or abusing dicts as params or monkey patching) you can still end up with difficult knots. One of the most frustrating examples is that even typos can remain uncaught without near 100% code coverage. I find these occur readily not when I'm writing code but when refactoring.
Reading old undocumented code and refactoring it confidently is wildly easier with Java than Python. The structure provides obvious moves and shifts and reason about code you haven't fully read yet. Even with relatively clean Python (i.e. No messing with scopes or abusing dicts as params or monkey patching) you can still end up with difficult knots. One of the most frustrating examples is that even typos can remain uncaught without near 100% code coverage. I find these occur readily not when I'm writing code but when refactoring.
Python gets out of your way as long as your code base is small enough. It's great for experimentation and building quick things. But it strains you a fair bit when your code base becomes large, with many contributors, and a significant amount of components and interfaces between them. You start to grab for static analysis tools.
(I say this having worked with Python for 20 years, and loving the language.)
(I say this having worked with Python for 20 years, and loving the language.)
[deleted]
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.
Sounds nice.
Sounds nice.
Huh. I'd be interested to hear what low-level stuff they thought was harder than in Java. Can't think of anything you can do in Java that can't be done at the same abstraction level in Kotlin.
My guesses would be handling unsigned hex https://youtrack.jetbrains.com/issue/KT-4749
And bitwise operations https://discuss.kotlinlang.org/t/when-does-bit-fiddling-come...
And maybe handling generics. I haven't had any issues, but kotlin is a bit stricter which is generally a good thing, but I'd believe that for some edge case it makes things harder.
And bitwise operations https://discuss.kotlinlang.org/t/when-does-bit-fiddling-come...
And maybe handling generics. I haven't had any issues, but kotlin is a bit stricter which is generally a good thing, but I'd believe that for some edge case it makes things harder.
Yes, the bitwise operator stuff.
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".
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".
Edit: Oh ho ho. I missed that "Next Generation of Programmers" is in the title. I think it's a pretty misleading title. I think Kotlin just makes places where java is required less painful.
You mean like Rust, Scala, Clojure, Haskell, Erlang, etc?
I don't think Kotlin is aimed at the Next Generation of programmers. I think it's squarely aimed at "We Have A Big App In Java" or "It's This Or Java" programmers. The other bits that don't seem related (the typescript support, the native support), support that because it reduces code duplication. Why write things twice (once in Kotlin, once it java), when you could just write things once, in Kotlin.
Don't get me wrong, they are sanding down a lot of rough corners; but ultimately their explicit goal of really nice java interop limits them. But their goals isn't to be for the Next Generation of programmers, it's to be for java programers.
You mean like Rust, Scala, Clojure, Haskell, Erlang, etc?
I don't think Kotlin is aimed at the Next Generation of programmers. I think it's squarely aimed at "We Have A Big App In Java" or "It's This Or Java" programmers. The other bits that don't seem related (the typescript support, the native support), support that because it reduces code duplication. Why write things twice (once in Kotlin, once it java), when you could just write things once, in Kotlin.
Don't get me wrong, they are sanding down a lot of rough corners; but ultimately their explicit goal of really nice java interop limits them. But their goals isn't to be for the Next Generation of programmers, it's to be for java programers.
What features do you miss in Kotlin so much?
Not the person you are replying to but:
* Typeclasses (over higher kinded types)
* Extensible typeclass instance derivation
* Comprehensions on par with SQL in expressiveness
* Typeclasses (over higher kinded types)
* Extensible typeclass instance derivation
* Comprehensions on par with SQL in expressiveness
Typeclasses can be introduced; there's a PR doing that in a reasonable manner: https://github.com/Kotlin/KEEP/pull/87 It's not shot down.
Instance derivation is likely not impossible when typeclasses support is there. I wonder how expensive it could be, though. Making them also usable from Java (e.g. Comparable) would likely be problematic sometimes due to Java's inconsistencies.
Can receiver lambdas (the "DSL" feature) be used to produce something comparable? For something comparable to LINQ, though (same expression targeting e.g. an object graph and an SQL database), compiler support would likely be needed.
Instance derivation is likely not impossible when typeclasses support is there. I wonder how expensive it could be, though. Making them also usable from Java (e.g. Comparable) would likely be problematic sometimes due to Java's inconsistencies.
Can receiver lambdas (the "DSL" feature) be used to produce something comparable? For something comparable to LINQ, though (same expression targeting e.g. an object graph and an SQL database), compiler support would likely be needed.
I don't recommend assessing languages by looking at features individually - how they play together is much more important
"hey, we've made the instruction codes shorter and an IDE that can navigate to line numbers".
That's almost what happened with C. In general I agree with your point though.
"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."
Not so sure about this. I see more of a trend to repeat previous errors because the industry as a whole quickly forgets lessons.
That's almost what happened with C. In general I agree with your point though.
"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."
Not so sure about this. I see more of a trend to repeat previous errors because the industry as a whole quickly forgets lessons.
Does it truly forget? A lot of the past knowledge is locked away or it was only experienced by 1000 programmers back in the 70s. It stands to reason that the huge amounts of programmers today have to learn their own lessons.
I think maybe in 2050 or so we will reach software development maturity, once the base of experienced developers is not dwarfed by the generation of developers joining the work force in one single year.
Keep in mind that the number of programmers is not only increasing moderately in developed countries, but much more so in developing countries, where hundreds of millions of people are joining the global middle class.
I think maybe in 2050 or so we will reach software development maturity, once the base of experienced developers is not dwarfed by the generation of developers joining the work force in one single year.
Keep in mind that the number of programmers is not only increasing moderately in developed countries, but much more so in developing countries, where hundreds of millions of people are joining the global middle class.
A lot of past knowledge is also very available and mostly ignored. Even the most popular books about programming are read only by a tiny minority of programmers. Listening to our elders is simply not part of the current programming culture.
I always think that a lot of the young guys who are struggling with C would actually read K&R instead of random blogs they would quickly have a solid understanding.
Most of today's books are really bad in comparison. Too long, no depth.
On the other hand the cool thing about programming is that you can get started and be productive without almost no knowledge of theory. Compare that to physics or math where anything interesting requires years of prior training.
I hope we'll find some balance where we don't lose the ability to get started quickly but still respect and study older achievements.
Most of today's books are really bad in comparison. Too long, no depth.
On the other hand the cool thing about programming is that you can get started and be productive without almost no knowledge of theory. Compare that to physics or math where anything interesting requires years of prior training.
I hope we'll find some balance where we don't lose the ability to get started quickly but still respect and study older achievements.
> Not so sure about this. I see more of a trend to repeat previous errors because the industry as a whole quickly forgets lessons.
It is a necessary condition, certainly not a sufficient one
It is a necessary condition, certainly not a sufficient one
Is that how it works? So in order to progress in other fields such as physics, medicine, robotics - the current incumbents must retire?
Anyone can have an idea.
Anyone can have an idea.
The innovation dynamics in the software industry are (have been) really different than in these fields IMHO.
But there are some similar historical precedents. Fourier's work was rejected in his time because Lagrange wouldn't adopt his approach to mathematics.
This video is a great retrospective on the evolution and adoption of programming languages / paradigms: https://www.youtube.com/watch?v=JxAXlJEmNMg
But there are some similar historical precedents. Fourier's work was rejected in his time because Lagrange wouldn't adopt his approach to mathematics.
This video is a great retrospective on the evolution and adoption of programming languages / paradigms: https://www.youtube.com/watch?v=JxAXlJEmNMg
Such an argument is bereft of logic and full of lazy moralization and Utopian rhetoric.
It has not always been that incumbent programmers hold back the next generation and in many cases it was absolutely warranted due to shortsighted and narrow-minded ambitions. Your talk of "fresh paradigms" reeks of NIH syndrome.
The advancement of an industry requires careful consideration and conscientious measurement of competency, not some nihilistic desire to burn everything down for the sake of some vague Utopian future.
It has not always been that incumbent programmers hold back the next generation and in many cases it was absolutely warranted due to shortsighted and narrow-minded ambitions. Your talk of "fresh paradigms" reeks of NIH syndrome.
The advancement of an industry requires careful consideration and conscientious measurement of competency, not some nihilistic desire to burn everything down for the sake of some vague Utopian future.
I'm sorry you feel that way, but why get so angry?
> we should be much more ambitious for the Next Generation of programmers
There's a lot of value in using simpler (but modern) languages in production instead of something choke-full of paradigms. Creators of popular languages seem to more or less agree with that (e.g. Java -> Kotlin, C++ -> Golang, Scala -> Dotty/Scala3).
There's a lot of value in using simpler (but modern) languages in production instead of something choke-full of paradigms. Creators of popular languages seem to more or less agree with that (e.g. Java -> Kotlin, C++ -> Golang, Scala -> Dotty/Scala3).
I guess C++ -> Golang is debatable, maybe Python -> Golang?
If I remember correctly, one of the motivators for Go was the desire to avoid having to use C++ by the original authors. That said, I agree that Pyhon -> Golang fits in that trend too.
True, but they dumbed Go so much down that they hardly attracted anyone used to write modern code in C++.
https://commandcenter.blogspot.com/2012/06/less-is-exponenti...
https://commandcenter.blogspot.com/2012/06/less-is-exponenti...
To be fair, Googlers can't write modern C++ because they have a critical mass of legacy code that has never been exception-safe. Avoiding RAII kneecaps the whole language badly.
Google doesn't avoid RAII, they just avoid exceptions.
The beauty of RAII is that every resource is tied to the lifetime of an object, and every object is always in a usable state. Having to call extra open/close methods and check error codes breaks these invariants, and leads to objects with bad fidelity to the normal copy and move semantics the language is built on.
Totally agree - and "new paradigms" isn't the same thing as "choke-full of paradigms". What's more, there's as much value in taking things away than in adding them (how about classes for example?)
The two aren't incompatible. Progress tends to be made of revolutionary jumps followed by evolutionary refinements. It's perfectly legitimate and useful for Kotlin to fall firmly under the "evolutionary refinement" category, and we can all reap the rewards of that evolution, while other teams elsewhere are trying for the revolutionary jump.
Sure, but I do hope that there's at least one revolutionary jump per generation. If the next generation ends up with Kotlin, we'll have missed ours
Clojure tried that and it was a step too big. And we better not talk about the baroque abomination named Scala. I think Kotlin is in the sweet spot.
While Clojure has failed to become mainstream so far, it certainly hasn't failed to be influential. Whatever programmers use in a generation, it may have a lot of ideas from Clojure in it!
And while it's far from mainstream, it's certainly a healthy language with a vibrant community nowadays. There's also a lot of exciting work being done on ClojureScript, and I think that it has even higher value proposition seeing how front-end development with Js is a hot mess right now.
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.
People are going TO Kotlin as opposed to the usually Ocaml/F#/Haskell/Idris/Agda world of the community trying to bring people in.
F# isn't owned by the .NET team, which then focus on VB.NET and C#, and anything that improves F# just happens to be a "nice to have".
They haven't yet bothered to make .NET Native understand the MSIL bytecodes required by F#, for example.
They haven't yet bothered to make .NET Native understand the MSIL bytecodes required by F#, for example.
Kotlin is competing against Java, while F# is competing against C#.
F# is a great language, but so is C#. MS has done a really great job evolving C# away from a Java clone. C# keeps adding features inspired by functional languages, narrowing the gap to F#. Of course this makes it easier to switch, but on the other hand it also makes it less interesting.
F# is a great language, but so is C#. MS has done a really great job evolving C# away from a Java clone. C# keeps adding features inspired by functional languages, narrowing the gap to F#. Of course this makes it easier to switch, but on the other hand it also makes it less interesting.
There's an argument to be made that F#'s place in the .NET ecosystem is to be a feature sandbox for C#.
When F# first dropped, I was instantly in love. It was just so much nicer than C#, which was already nice. But, in the intervening years, C# has been adding new features at such a steady clip that it's hard for me to have such strong feelings anymore. Stylistically I like to have algebraic types and pattern matching, but from a practical perspective I think the two languages probably offer about the same level of productivity.
When F# first dropped, I was instantly in love. It was just so much nicer than C#, which was already nice. But, in the intervening years, C# has been adding new features at such a steady clip that it's hard for me to have such strong feelings anymore. Stylistically I like to have algebraic types and pattern matching, but from a practical perspective I think the two languages probably offer about the same level of productivity.
from where do you get that F# is sitting on the sidelines?
i see more books and open source projects for F# than kotlin, which for a while made me skeptical about the truth of kotlin popularity
i see more books and open source projects for F# than kotlin, which for a while made me skeptical about the truth of kotlin popularity
I talk to a lot of Android folks. Most have already made the switch, and consider the growth of the language "explosive". That Google is opting in there only makes it better.
F# has been around a long time and while it's experiencing modest growth and I think it has a positive track, I've certainly never seen it hyped and on the tip of every tongue the way Kotlin now is within the Android space.
F# has been around a long time and while it's experiencing modest growth and I think it has a positive track, I've certainly never seen it hyped and on the tip of every tongue the way Kotlin now is within the Android space.
I think it is completely unrealistic to expect F# to gain traction in Android. Google would never support it, and I don't think the platform is open enough for others to make it happen.
[deleted]
well, sure, if what you mainly work on is android, then it make sense that kotlin is getting hyped
that being said, for an outsider (i mainly do BI and DB stuff), it seem like xamarin (C# and F#), flutter (Dart), react native (reasonml) .. might seem like the options to investigate first nowadays
i think outside of android development, kotlin .. is not hyped at all
that being said, for an outsider (i mainly do BI and DB stuff), it seem like xamarin (C# and F#), flutter (Dart), react native (reasonml) .. might seem like the options to investigate first nowadays
i think outside of android development, kotlin .. is not hyped at all
Sure, but Android is one of the top 3 most deployed application environments in the world. It's a pretty big and important market.
Try to write a UWP or WPF application in F#, use EF designers with F#, follow up on Visual Studio changes related to F#.
Heck even PowerShell now has a WinForms designer.
Heck even PowerShell now has a WinForms designer.
I think, this might be because F# is community driven, and there is little interest in pushing API that is not portable to Linux
F# was always linux friendly, long before .net core
F# was always linux friendly, long before .net core
Maybe but F# has been around for much longer. It failed already to become mainstream.
Why are you throwing out all kinds of FP languages when Kotlin is not one?
Kotlin's "not FP" in the way Scala is "not FP" and Swift is "not FP." It's pretty FP, in my experience. Just not strictly. :)
Notice how none of the langs you point out are not mentioned though. Comparing an FP-light to classical FP languages is not equivalent.
I'll see your F# and raise you one Clojure.
I was around when the Clojure community seemed to make a conscious decision to not chase Android, so it's precisely their decision to miss that train.
But I think Clojure isn't in a terrible spot right now. It gets a modest amount of use. More than I think many people imagined it possibly could have.
But I think Clojure isn't in a terrible spot right now. It gets a modest amount of use. More than I think many people imagined it possibly could have.
Clojure approach to mobile development is to piggy back on React Native. Using [re-natal](https://github.com/drapanjanas/re-natal) is pretty smooth nowadays, and you get some really nice benefits such as hot code loading, and being able to use re-frame for the UI.
React Native works well enough for a lot of apps out there, and makes it relatively easy to write cross-platform apps. So, it's a pretty good platform to build on in my opinion.
React Native works well enough for a lot of apps out there, and makes it relatively easy to write cross-platform apps. So, it's a pretty good platform to build on in my opinion.
I dunno. I've yet to meet a shop that isn't tactically retreating from it within a year of shipping.
I've seen about as many companies talking about being happy with it as those retreating from it. Personally, I haven't seen any issues with it that I would consider to be show stoppers.
I sincerely hope Datomic Ions[1] take off, they are an amazing way to run Clojure code.
[1] https://www.youtube.com/watch?v=TbthtdBw93w
[1] https://www.youtube.com/watch?v=TbthtdBw93w
Coming from Java - learning Kotlin is borderline trivial. I think having the huge audience of Java (+Android) (+IntelliJ) developers to draw from was a huge advantage for Kotlin.
> People are going TO Kotlin as opposed to the usually Ocaml/F#/Haskell/Idris/Agda world of the community trying to bring people in.
The familiarity of C-style syntax and object orientation immediately places Kotlin above ML-style programming languages from the standpoint of adoption. It's a bit unfortunate that this is the case, but selling Android developers on a better C-style OO language than Java is a lot easier than selling them on something different.
The familiarity of C-style syntax and object orientation immediately places Kotlin above ML-style programming languages from the standpoint of adoption. It's a bit unfortunate that this is the case, but selling Android developers on a better C-style OO language than Java is a lot easier than selling them on something different.
Kotlin has its merits but the only real reason it is where it is is because its JetBrains' language.
Kotlin has been treated as a first class citizen in the official Android IDE and one of the major Java IDEs in a way that no other language but Java itself is.
Kotlin has been treated as a first class citizen in the official Android IDE and one of the major Java IDEs in a way that no other language but Java itself is.
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.
Yes, Google has radio silence on adopting anything beyond Java 8.
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.
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.
Probably has something to do with that ongoing lawsuit with oracle
Easily avoidable if Google had not screw Sun in first place, and if they bothered to buy it afterwards when Sun went bankrupt.
Apparently they thought they could get away with it.
And there are still lots of jars on Maven central that are unusable on Android Oreo.
Because even after switching to OpenJDK, they cherry pick APIs from there and ART does not support all JVM bytecode features.
Apparently they thought they could get away with it.
And there are still lots of jars on Maven central that are unusable on Android Oreo.
Because even after switching to OpenJDK, they cherry pick APIs from there and ART does not support all JVM bytecode features.
I don't think it's that. They switched to OpenJDK a while ago.
It seems to be more that they don't prioritise keeping up with the Java ecosystem very much, they'd rather work on their own stuff. It's more a cultural issue than anything else IMO. Google has always had a big NIH problem.
It seems to be more that they don't prioritise keeping up with the Java ecosystem very much, they'd rather work on their own stuff. It's more a cultural issue than anything else IMO. Google has always had a big NIH problem.
Android doesn't use the JVM. They're slowly rolling in newer Java language features bit by bit though.
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.
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.
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.
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.
Steve Yegge had an entertaining and informative post last summer describing his own experience with Kotlin and his thoughts on what makes it a compelling language. It's a great read: https://steve-yegge.blogspot.com/2017/05/why-kotlin-is-bette...
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'm somewhat familiar with Kotlin, but not really with Clojure.
My impression is though that Kotlin really just tries to make a less painful Java, whereas Clojure is a better/nicer JVM language.
My impression is though that Kotlin really just tries to make a less painful Java, whereas Clojure is a better/nicer JVM language.
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.
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.
LISP was implemented on the PDP-1 in the early sixties - originally it was implemented for the IBM 704 in 1959. C was implemented on a larger machine, the PDP-11 in the early 70s. There were LISP implementations for the PDP-11 - Richard Stallman himself wrote one.
One of the problems was that LISP was not friendly to timesharing, since a LISP program could take over the whole RAM and something like GC would walk over lots of memory, which meant lots of slow memory swapping in machines with virtual memory. It was then best to use LISP when alone on such a machine.
One of the problems was that LISP was not friendly to timesharing, since a LISP program could take over the whole RAM and something like GC would walk over lots of memory, which meant lots of slow memory swapping in machines with virtual memory. It was then best to use LISP when alone on such a machine.
I'm well aware of the origins of LISP, but reality is that C model is much closer to hardware architecture used in commodity hardware at the time. C made a lot of sense under the constraints, and that's the reason it became popular.
Other than what you wrote, LISP did not need 'super computers'. It ran on the same and smaller machines as the original C. A PDP-1 was never a 'super computer', neither were the other PDPs. They were 'minicomputers' or 'mainframes'. Actually super computers (CDC, Cray, ...) were not a particular popular target for LISP implementations, ...
Fair point, you didn't actually need super computers to run LISP.
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.
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.
Kotlin is a Honda Accord. Good, solid, little fuss, more pleasant than you'd expect from the outside.
Closure is an Alfa Romeo. Amazing, beautiful, frustrating, satisfying, and like nothing else when you get it going.
Closure is an Alfa Romeo. Amazing, beautiful, frustrating, satisfying, and like nothing else when you get it going.
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 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 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.
I've been working with Clojure for about 8 years professionally now, and I haven't touched Emacs in all that time. I started with CCW for Eclipse, and later moved to Cursive with IntelliJ. I find the IDE experience for Clojure is quite reasonable now. You get a lot of what you'd expect in terms IDE support such as automatically requiring namespaces on usage, finding usages for symbols, auto-refactoring, and so on.
In terms of hiring developers my team hasn't had a problem with that either. We've only hired a single person who knew Clojure ahead of time, and we trained the rest of the hires on it on the job. Our experience is that it takes about a couple of weeks for somebody to start writing useful code with guidance. We start by doing a bit of pairing, and we do code reviews for pull requests where we help make sure new hires are writing idiomatic code. When you have at least one experienced Clojure dev on the team already, onboarding tends to be pretty smooth.
One huge benefit we found posting for Clojure is that we get completely different set of applicants than when we posted for Java. There are many excellent Java devs out there, however finding them is like looking for a needle in a haystack and you're competing with many other companies for them.
Meanwhile, most people applying for Clojure jobs tend to have genuine interest in learning something new, and they're very enthusiastic about it. We get a smaller pool of applicants, but on the other hands most of the people applying are actually worth considering.
In terms of hiring developers my team hasn't had a problem with that either. We've only hired a single person who knew Clojure ahead of time, and we trained the rest of the hires on it on the job. Our experience is that it takes about a couple of weeks for somebody to start writing useful code with guidance. We start by doing a bit of pairing, and we do code reviews for pull requests where we help make sure new hires are writing idiomatic code. When you have at least one experienced Clojure dev on the team already, onboarding tends to be pretty smooth.
One huge benefit we found posting for Clojure is that we get completely different set of applicants than when we posted for Java. There are many excellent Java devs out there, however finding them is like looking for a needle in a haystack and you're competing with many other companies for them.
Meanwhile, most people applying for Clojure jobs tend to have genuine interest in learning something new, and they're very enthusiastic about it. We get a smaller pool of applicants, but on the other hands most of the people applying are actually worth considering.
Where do you live? SF I presume?
I work at a hospital in Toronto, Canada.
Yep, Toronto is a nice place, but in Budapest, Hungary Clojure programmers are basically non-existent. What you are saying might fit Canada, or the USA, but not every other part of the world.
My main point was that we don't hire Clojure programmers on my team. We hire programmers who are willing to learn new things on the job, and one of these things happens to be Clojure. I see this is as a helpful filter because if somebody isn't willing to learn a new language, chances aren't very flexible as a developer in general. The nature of our industry is that it's constantly evolving, and you have to be adaptable to keep up.
I do have to add that I still miss Clojure and its homoiconicity every time I bump into a limitation of metaprogramming in Kotlin or any other language which is not LISP...
> 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.
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.
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#.
Although there's certainly much less of a gap between Kotlin and C#.
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.
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.
Anyone that calls that to Java never programmed in Objective-C, which is like Java's grandfather.
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.
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.
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.
I agree that they should implement a language server but they do have an eclipse plugin[0] that they develop. It's very generous of them to do.
[0]:https://github.com/JetBrains/kotlin-eclipse
[0]:https://github.com/JetBrains/kotlin-eclipse
The eclipse plugin sometimes doesn't provide the best developer experience though. I doubt they would accept that for intellij idea.
Hey everyone, I'm Zan - the person being interviewed. Any questions about the survey, let me know :)
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.
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.
[1] https://en.wikipedia.org/wiki/Smalltalk#Image-based_persiste...
[1] https://en.wikipedia.org/wiki/Smalltalk#Image-based_persiste...
Smalltalk.
http://home.balcab.ch/jpelrine/download/ss99.pdf
“Java has come a ways towards that,
but made some fundamental mistakes.
I mean, source code in files.
How quaint. How 70’s.”
http://home.balcab.ch/jpelrine/download/ss99.pdf
Do you consider modules to be "a basic organizing unit of code"?
https://www.oracle.com/corporate/features/understanding-java...
https://www.oracle.com/corporate/features/understanding-java...
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.
> …but even in those cases, sources usually end up being stored long-term in files, as a matter of convenience.
Is that "the file as a basic organizing unit of code"?
Even when code is organized in applications and classes and versions… and persistence comes from a database, the database will be implemented using a computer file system.
https://books.google.com/books?id=ld6E19QIMo4C
Is that "the file as a basic organizing unit of code"?
Even when code is organized in applications and classes and versions… and persistence comes from a database, the database will be implemented using a computer file system.
https://books.google.com/books?id=ld6E19QIMo4C
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.
Idea Community Edition is free and open source. It supports Kotlin with the same plugin. Whether it's comparable to Eclipse is debatable. I like Idea much more.
Objectively, Eclipse is milles ahead and more complete than IDEA, it is a toy compared to Eclipse
Having used both I can't imagine what you are talking about. Which features in Eclipse is Idea missing?
First of all, I'm talking about the free version of IntelliJ (IDEA), you cannot use it to create Java EE applications and the HTML and JavaScript editors are pretty basic as everything else.
- Incremental compilation on save
- Not spinning the hard disk all the time indexing libraries
- Showing Javadoc by default without extra configuration steps
- Not spinning the hard disk all the time indexing libraries
- Showing Javadoc by default without extra configuration steps
AFAIK intellij/idea is open source:
https://github.com/JetBrains/intellij-community
https://github.com/JetBrains/kotlin
https://github.com/JetBrains/intellij-community
https://github.com/JetBrains/kotlin
>and the free version (IDEA) cannot comapre to Eclipse.
I already adressed it in my original comment, is not good enougth.
I already adressed it in my original comment, is not good enougth.
I enjoy Kotlin, but what is missing is a book: "Kotlin for Beginners".
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.
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.
Available in the next few days: https://www.amazon.com/Kotlin-Programming-Nerd-Ranch-Guide/d...
> 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.
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."
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.
Kotlin seems to either have a lot of advocates or a strong marketing department. Its almost like a advertising company supports it.
Java was cool at allowing a couple of things nothing else did: applets, and an actually cross-platform language.
But the language itself never seemed “cool” — it horribly verbose even from the start. In fact, it's much better now than it was.
But the language itself never seemed “cool” — it horribly verbose even from the start. In fact, it's much better now than it was.
It was surely cool in 1996, vs Frankenstein C compilers still stuck between K&R C and Ansi C (hello aCC), C++ compilers playing catch up with ongoing ISO work.
Then there was VB 6, Delphi, Eiffel, Oberon, Modula-3, Component Pascal, Smalltalk, Common Lisp and a few others more.
Big difference was that Sun was giving the JDK away for free every way they could.
Magazine CDs, conferences, sending them free by post, whatever.
I was on my last year and everything that had to do with distributed conputing or compiler development switched to Java. With teachers carrying Java branded bags.
Then there was VB 6, Delphi, Eiffel, Oberon, Modula-3, Component Pascal, Smalltalk, Common Lisp and a few others more.
Big difference was that Sun was giving the JDK away for free every way they could.
Magazine CDs, conferences, sending them free by post, whatever.
I was on my last year and everything that had to do with distributed conputing or compiler development switched to Java. With teachers carrying Java branded bags.
Two other cool things about Java:
The library. It had everything.
Garbage collection. You didn't have to keep track of when to free memory any more. If you were in C or C++, this meant a major headache just... went away. (If you were in Common Lisp, well, you never had that headache in the first place...)
The library. It had everything.
Garbage collection. You didn't have to keep track of when to free memory any more. If you were in C or C++, this meant a major headache just... went away. (If you were in Common Lisp, well, you never had that headache in the first place...)
Quite true.
I already used Oberon, Caml Light, Prolog and Smalltalk by then, but it was the way Sun was pushing it no matter what that actually made it mainstream, regarding GC adoption.
If I am not mistaken it was Guy Steele that stated it brought developers half way to Scheme.
As for the library I remember the first commercial Java collections based on the ongoing C++ STL work, before Java 1.2 adopted their own, with a few similarities to Smalltalk ones.
C++ on those days had each compiler vendor provide their own view of what a C++ framework should look like, and although RAII was already a thing, very few of them already offered some way of doing smart pointers, with the exception of COM wrappers.
I already used Oberon, Caml Light, Prolog and Smalltalk by then, but it was the way Sun was pushing it no matter what that actually made it mainstream, regarding GC adoption.
If I am not mistaken it was Guy Steele that stated it brought developers half way to Scheme.
As for the library I remember the first commercial Java collections based on the ongoing C++ STL work, before Java 1.2 adopted their own, with a few similarities to Smalltalk ones.
C++ on those days had each compiler vendor provide their own view of what a C++ framework should look like, and although RAII was already a thing, very few of them already offered some way of doing smart pointers, with the exception of COM wrappers.
> As for the library … with a few similarities to Smalltalk ones.
And the recapitulation of emulated versus native Smalltalk UIs, with Swing versus SWT.
And the recapitulation of emulated versus native Smalltalk UIs, with Swing versus SWT.
Yeah, the error there was that Swing does not have the right defaults, so it does require some graphical programming skills to make nice UI experiences out of it, or buying component libraries.
And since a large majority doesn't bother to read books like Filthy Rich Clients, the outcome isn't the best.
And since a large majority doesn't bother to read books like Filthy Rich Clients, the outcome isn't the best.
Please consider that the competition was 1990's era C++. For every way Java's old versions were bad, C++ was bad in 3 distinct ways that often lead to program faults. Folks left old-C++-world like it was plague infested when they could, because it was a genuinely unforgiving environment to program in and no one took Objective-C seriously outside of the world of NeXTSTEP.
Java was very definitely "cool" in the 90's.
> But the language itself never seemed “cool”
The author of "Joy, Inc." disagrees with you
https://www.amazon.com/Joy-Inc-Built-Workplace-People/dp/159...
The author of "Joy, Inc." disagrees with you
https://www.amazon.com/Joy-Inc-Built-Workplace-People/dp/159...
> …nothing else did … cross-platform language
Au contraire!
http://www.davethomas.net/papers/ubiquitous1995.pdf
Au contraire!
http://www.davethomas.net/papers/ubiquitous1995.pdf
My takeaway from this is that Kotlin appeals to junior/inexperienced developers, cargo-culters, and JetBrains developers.
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.
Easy/common things should be easy and hard/uncommon things should be possible. So it's scala for me :)
And Android devs that would otherwise be stuck using Java 6.
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.
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.
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.
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.