Rise of Kotlin: A Programming Language for the Next Generation
hackernoon.com
hackernoon.com
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.
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.
(I say this having worked with Python for 20 years, and loving the language.)
Sounds nice.
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.
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".
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.
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.
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.
It is a necessary condition, certainly not a sufficient one
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.
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).
https://commandcenter.blogspot.com/2012/06/less-is-exponenti...
It's easier to boil the ocean one degree at a time.
A snowball used to be a snowflake.
Anyone can have an idea.
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
* Typeclasses (over higher kinded types)
* Extensible typeclass instance derivation
* Comprehensions on par with SQL in expressiveness
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.
Also, you miss the point of Kotlin; it would be like saying that what you miss from Clojure is similarity to Java syntax.
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.
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# 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.
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.
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.
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.
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.
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.
They haven't yet bothered to make .NET Native understand the MSIL bytecodes required by F#, for example.
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
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.
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
Heck even PowerShell now has a WinForms designer.
F# was always linux friendly, long before .net core
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.
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.
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.
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.
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.
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.
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.
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.
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.
My impression is though that Kotlin really just tries to make a less painful Java, whereas Clojure is a better/nicer JVM language.
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.
Closure is an Alfa Romeo. Amazing, beautiful, frustrating, satisfying, and like nothing else when you get it going.
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'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.
Although there's certainly much less of a gap between Kotlin and C#.
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.
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.
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.
[1] https://en.wikipedia.org/wiki/Smalltalk#Image-based_persiste...
“Java has come a ways towards that,
but made some fundamental mistakes.
I mean, source code in files.
How quaint. How 70’s.”
https://www.oracle.com/corporate/features/understanding-java...
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.
- Not spinning the hard disk all the time indexing libraries
- Showing Javadoc by default without extra configuration steps
I already adressed it in my original comment, is not good enougth.
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.
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.
But the language itself never seemed “cool” — it horribly verbose even from the start. In fact, it's much better now than it was.
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.
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...)
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.
And the recapitulation of emulated versus native Smalltalk UIs, with Swing versus SWT.
And since a large majority doesn't bother to read books like Filthy Rich Clients, the outcome isn't the best.
The author of "Joy, Inc." disagrees with you
https://www.amazon.com/Joy-Inc-Built-Workplace-People/dp/159...
Au contraire!
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."
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.