Kotlin is the hero Android needs
10clouds.com
10clouds.com
1: https://en.wikipedia.org/wiki/Usage_share_of_operating_syste...
There were so much hype about swift, when kotlin was here and probably doing better (no incompatibility issues between versions for example). Swift and kotlin are the languages to look to the future. One or two years ago, and today.
I wish the people would have more critic sense and asses the things by themselves before a big company says anything. (Because kotlin was great before Google said anything)
Most new languages will fade away without ever getting enough traction to survive. It's a real risk that is mitigated by corporate backing.
Many people may have been aware of Kotlin's strengths but found themselves unable to justify its use for a mission critical task.
When there is more mindshare around an up and coming programming language, it's simply easier for a community to build and learn with the support of a large company. There are several JVM languages devs can select from, but it's not practical to expect devs to sit around and explore each and every one of those languages.
Isn't JetBrains a large company? Or even a company without experience in programming languages?
I trust more a language created from a company which create tools for programmers that any other one.
Probably would have had the same as Kotlin if Apple hadn't announced it in WWDC.
look at all the languages that compile to javascript: bucklescript, clojurescript, elm, dart, purescript, coffeescript, livescript ...
as a developer, you can`t learn them all, and because there is too many, some will surely drop from the race
some people are worried, because kotlin may just become another technology you need to learn, more than another technology you really need
I normally try not to be so vitriolic on HN, but I'm so frustrated with Google's handling of the Android API that I can't help it.
Edit: Kotlin. Kotlin. more Kotlin.
Some tech post about some technology gets a ton of votes, some people get excited about the tech, they investigate and find articles about that tech, they share it, and all the excited people upvote it.
Has happened several times with Rust, Go, Ember, Meteor, Angular, TypeScript, etc etc
This time android support and that steve yegge blog post set it off (it probably wasn't an accident that these two coincided though?)
It's like an echo-chamber with ADHD
Of course that assumes Google doesn't drop support a year later.
2. It's been around for a decade now, but has only supported development with Java and C++.
3. The most recent version of Java supported comes from 2011. And full C++ support is only recent.
4. Few people (if any) really like these options.
5. This week Google announced that Kotlin is the next "official" language with first-class support.
6. A temporary wave of stories appear on HN.
Are you new here? I'm sure that next week it'll go back to the usual threads about Rust or Haskell, or someone will start a retro fad around Algol-68 or something.
C++ might be a 2nd class citizen in SDK tooling, but it is supported since Android 1.5 and C++14 is fully supported.
How is that very recent?
EDIT: The NDK was actually released with v1.5 (2009), the v2.3 was when STL and exceptions support were added hence my error.
https://developer.android.com/ndk/downloads/revision_history...
How can it be historically, when the features are available since almost 7 years?
I'm not sure if you consider them "supported" but they both have pretty advanced tooling for the purpose.
Now, if you write an app with Kotlin, then it's Google's support problem. I can see how that would change the game for a lot of shops.
You don't have direct access to Android's API with C#, you use a dedicated runtime wrapping your calls and allowing you to interact with the framework. This comes with a very large variety of issues.
With kotlin, you have 100% interop for free.
I just do not get how the disconnected list of events you provided justify the promotion of Kotlin we have seen this week. But hey, you might even be on the payroll.
(I feel like I'm living through a bad acid trip)
Seriously though, speaking as a contributor to Nim, I can confidently say no-one in the Nim community organizes massive multi-post promotion campaigns like this. The only submissions that come from the core developers are the announcements for new language versions, and (unfortunately) none of the community members seem particularly inclined to regularly submit links to libraries/blog posts either.
I'm sure Elm developers do the same thing - it's the only way for such projects to actually gain recognition among other communities.
Is Mozilla a "huge company"?
(Yes, I know you can run Go code on Android but last I knew that's almost exactly literally what it is; you can run Go code on Android, but it has next to no integration with the rest of Android, just a very basic binding to things that are very cross-platform: https://godoc.org/golang.org/x/mobile/app)
Remember Swift hypetrain a year or so ago? I do. People even made web frameworks with it.
This is the same kind of an excitement as the one when Apple announced that Swift will be a first class citizen of iOS development. I rarely get excited with programming languages, but this one went straight to my heart. Maybe I am biased because I like JetBrains as a company.
Hype can also occur (somewhat) naturally. It does happen.
People are simply excited about being able to use Kotlin as an official alternative to Java on Android. I'm also pretty excited about this ...
Xamarin allows you to target iOS, MacOS, and Windows in addition to Android. Though you have to rewrite the view layer for each platform. If your view layer is in HTML, then you mostly have WORA.
Xamarin converts a lot of crufty weird Android API to a slightly more modern form. So instead of int constants hanging off random classes all over the place, you have proper enums.
Coroutines and async/await seem much more ready for primetime in C# than in Kotlin.
Xamarin builds seem saner and faster than Android native.
There's some very advanced and battle-tested C# libraries that Xamarin opens up that I think are unmatched in native Android land. For full-application frameworks, ORMs, DI, databinding, and serialisation.
There's way more C# devs in the world than Kotlin devs.
Though I have to say that Xamarin has one big disadvantage - it adds another layer of sometimes leaky abstraction, and a whole new source of framework bugs to Android. So you spend a lot of time asking yourself "is this a Google bug, or a Xamarin bug, or my bug?"
This the main reason why while I dabble in all interesting technologies to get a taste of what they bring into the table, production code is always written 100% with official SDK languages for the system being targeted.
Unline Kotlin, Go does support len() (.length in Kotlin) on nil: https://play.golang.org/p/koqYbIdltw
In Kotlin, b.length can throw a NPE, only a b?.length won't (it will return zero or null, I have not understood that).
Together with the var/val debacle, it seems like it is designed to be very terse, which can lead to easier errors.
I don't think it solves the 1M$ mistake at all. And how could it, while maintaining full compatiblity with Java?
If b were defined in kotlin, as nullable, then b.length is a type error. You can use b?.length, or you can add an explicit null check and depend on the smart cast.
How different is idiomatic Kotlin in respect to Java?
How complex Kotlin Native will get? (I know that they want it for iOS, IoT, games, data science but something like this will require some types of manual memory mechanism, at least for gaming)
Will Kotlin Native work in Android NDK (calling it from JVM in general)?
Will Kotlin Native support WebAssembly?
Not much, but there are differences. It's generally things that Java just don't have.
> How complex Kotlin Native will get? (I know that they want it for iOS, IoT, games, data science but something like this will require some types of manual memory mechanism, at least for gaming) Will Kotlin Native work in Android NDK (calling it from JVM in general)?
I think it'll be native code with small stdlib which will compile to many platforms. So generally if you can write something with C, you'll be able to use Kotlin.
> Will Kotlin Native support WebAssembly?
I think so. Kotlin Native uses LLVM and LLVM can produce WebAssembly output.
Erm, same can be done in Java with the Java 8 stream API.
I like Kotlin and use it with Spring, but articles like this where programming languages are not compared properly make me cringe.
Edit - http://www.infoworld.com/article/3180758/mobile-development/... it looks like Android is gaining Java 8 support now
Except maybe if you minAPI is something ludicrously high like 25, but that's not going to be the case for almost all apps in the coming year. Kotlin is useable right now.
These are small things, and easily corrected with a bit of know-how and/or utility methods. But I think it has had a huge impact on the (non-)adoption of streams.
Another obvious API gap: going from an iterator or iterable to a stream requires much more ceremony than it should.
That said, Sequence have very simple implementations while Java Streams are hairy monsters under the hood and you can use Java Streams from Kotlin without problems, if you're targeting JDK8.
They wrote their own implementation of an earlier version, and at this point will probably never update its API to fully match Java 8 or beyond. Android devs who want advancements will have to add "shims", like retrolambda or (quite frankly) Kotlin.
So this is like Python's attrs module
Nothing really changed, you could write Android apps on Kotlin before, as well as on any other JVM language. But now "Kotlin is the hero".
I suspect that Google's adoption of Kotlin is just politics: JetBrains develops Android Studio for Google, so they pushed Kotlin as part of the deal. Google could acknowledge Scala years ago, but didn't, because Scala authors spend less time on bullshit politics and more time on actually improving the language.
Also, I don't understand the point of Kotlin. Clojure, Groovy and Scala are all very distinctive from each other and have their own niche. Kotlin is just a subset of Scala. Same thing, but less features. I guess it's NIH principle applied to JetBrains.
Scala did a lot of things that pushed mainstream programming forward, but it's also crapped up with a lot of detritus, ideas that didn't work out, and ideas that were always obviously bad.
Yes, it is only the subset you need, nothing else. That is why is here to stay and Scala not.
Making the things more complex doesn't mean making them better. Do one thing, and do it right. Don't do a lot of things half good.
Actually Kotlin inherited a few bad ideas from Scala as well - which Scala already dropped like procedure syntax.
And some features like null handling or coroutines in Kotlin are implemented as language features - special cases in the compiler, because the core of the language lacks abstraction mechanisms. This is making the language more complex than Scala.
Scala: minimal and powerful language core, the rest is in libraries.
Dotty: make this core even smaller
Kotlin: take a powerful language like Scala, remove almost all of the unnique abstraction features, leave only "better Java syntax" and then reimplement missing features by special cases directly in the language instead of libraries. Feels like VB of XXI century.
> Scala already dropped like procedure syntax
Do you mean this?: https://groups.google.com/forum/#!topic/scala-internals/q1YX...
Kotlin does not do that.
> some features like null handling or coroutines in Kotlin are implemented as language features
null handling yes, and it is very well done. Coroutines so so, they added a couple of keywords to the language and most of the implementation is in the library. You can create your own coroutines: https://kotlinlang.org/docs/reference/coroutines.html
Go do coroutines quite good and they have also implemented in the language, why is it bad they use a couple of keywords for those special cases?
This is a lie. Please stop spreading these lies about Scala requiring a huge runtime. Scala runtime adds about 30 kB, which is nothing in 2017.
> the tooling support is also better.
Both use the same IDE from Jetbrains and both are officially supported. Hard to tell which one is really better, but Kotlin support has more issues in its bug tracker, despite being less popular :P
> (nulls) it is very well done.
It is not. It makes the type system more complex, and you can't abstract over optionals and other collection types. You also can't make your own flavor of optional-kinds, like Either or Try that would behave similar to the builtin nullability feature.
The biggest problem with builtin features is that you can't make your own slightly different ones. You're at mercy of one company controlling the language. With a smaller language + libraries, you can always fork a library and do modifications.
Kotlin is better at being Java than Java is. Scala is not.
The announcement shows Google making a commitment to make Kotlin successful in Android, rather than leaving the effort all to the community and JetBrains.
> I suspect that Google's adoption of Kotlin is just politics: [...] Google could acknowledge Scala years ago, but didn't [...]
I think this post explains it best: https://medium.com/@ScalaWilliam/why-scala-didnt-miss-the-an... .
In regards with the Scala evolution, there's a lot of things to be excited about. In the near term, 2.13 should see various optimisation to core libraries and faster compilation.
> Also, I don't understand the point of Kotlin. [...] Kotlin is just a subset of Scala. [...]
Kotlin is a better Java, whereas Scala is much, much more.
Scala is still my go-to JVM languages, but one Kotlin use case for me is to write libraries that will be called from Java [1]. Its biggest advantage is that it's succinct, has useful functional features (e.g. Scala-like collections), while producing code signatures that's very close to Java.
Notes:
I see Kotlin as a clean-up job of a lot of syntax design flaws in java.
In the end it is just politics. What will make a framework or language succeed is how influential its sponsors are (e.g.: IBM -> Fortran & Cobol, ATT -> C, MS -> Basic & C#, Sun -> Java, Google -> Python, MS & ATT -> C++, Apple -> ObjectiveC). The ideological arguments are just decoration, fancy wrapping and cosmetics to convince people to buy the thing.
If language "quality" alone was enough to win adepts, both Smalltalk and Lisp would be among the top 10 most used.
Kotlin might be better than Java, in the same sense a Dvorak keyboard might be better than a qwerty. But it doesn't seem better enough to force old Java dogs to care for new tricks.
Edit: typos.
Don't count on that.
I'm an old dog when it comes to Java. But I decided to give Kotlin a try on a little pet project of mine.
JetBrains are mad geniuses. In Intellij, with a hotkey you can convert Java to Kotlin. A couple of Alt-Enters and you have something almost idiomatic.
I converted the entire (small) project in an hour and then spent a bunch of time reworking parts to take advantage of Kotlin's functional features.
And I could convert incrementally and test each migration because the Java interop is absolutely seamless. They've completely eliminated the risk and friction of trying the language out.
I even found a bug along the way due to Kotlin's null checker.
It's brilliant!
JetBrains gets it. They produced a language that's new yet familiar (sorry Clojure), powerful yet still easy to understand (sorry Scala), and has essentially zero barrier to entry due to interop and tooling support.
The same works for Scala.
> powerful yet still easy to understand (sorry Scala)
Kotlin is way less powerful than Scala. And if you dumb down Scala to Kotlin level by just not using the more advanced features (it is easy to turn them off globally), you're basically writing Kotlin. I can't see how Scala is less readable then - the differences are really cosmetic.
Add in the slow compiler, sbt (I don't need another build system, thanks), and IDE support that's only finally decent, and speaking for myself, it's not my thing.
Fortunately, it is the nature of the Java ecosystem that we can pick the language and tooling we prefer and we can all still get along! So while I'm a fan of Kotlin, hey, if Scala is your bag, enjoy!
> an overly complex type system
It is only as complex as it has to be to solve problems it was designed to solve. I take a more complex type system that make complex problems hard to solve rather than a simplistic type system that make complex problems impossible to solve.
> it feels a little too much like a language that was designed by throwing nifty ideas at a wall without cutting out the stuff that didn't stick
Name a few that could be removed without making the language significantly less powerful. Most people saying "Scala is complex" really want to say "Scala has many concepts I'm unfamiliar with". Java or C are also "too complex" for most VB programmers.
> Add in the slow compiler
It is not as bad as you may think, and IDE support is stellar, so I don't need to compile really that often. Many successful languages have much slower compile times: C++, Rust. Incremental compilation is fast enough. I get typically 1-5 seconds compile times.
> sbt (I don't need another build system, thanks)
SBT is not mandatory. Just a tool. Pick whatever you wish. Scala works perfectly fine with Gradle or Maven.
Uh.
Yeah. Exactly.
It's also a nice Rosetta stone while learning Kotlin.
edit: I'm assuming you want, like me, to try Kotlin
Note: I'd eventually just use Kotlin anyways cause I don't care all that much for Java.
That said, I've never written an Android app. There may be issues with that particular platform.
Java is baggage ridden. I wonder if Java would've been the language of choice had Rust or Go existed when it was started.
Given that; it's a pretty simple language - a lot like python or ruby, but with a touch more of syntax beurocracy.
If you only have some javascript, it would probably be best to learn it from a proper kotlin book - there's a few out/coming out - but I've not read them.
But if anyone took a typical "java as a first programming language"-book and shifted it to idiomatic kotlin, such a book would probably be a decent first programming book.
Note that I do agree somewhat with the comments about kotlin being lipstick on java's broken and strange single-inheritance oo, which leans more on Simula than Smalltalk. But I think the result is rather pretty. Maybe just because it manages to get rid of so much cruft from java ("Doctor it hurts when I do this." - "Then stop doing that.").
I would probably rate kotlin as a better starting language than javascript, for that matter.
Lambdas
Data classes
Function literals & inline functions
Extension functions
Null safety
Smart casts
String templates
Properties
Primary constructors
Class delegation
Type inference
Singletons
Declaration-site variance
Range expressionsSame with Scala. I once ported a Scala program to Java one and ended up with much shorter and concise code.
I don't see why you are surprised. Especially at the concise part.
I think you have a misconception about how Kotlin and Scala are compiled. Java source code is not generated by either of these compilers -- they both compile directly to .class files, just like javac does. There is no extra step, just a different step.
I, for one, am very interested in how I can use it to speed my JVM-based development.
I'm also interested in doing front end dev with it as well.
Others have different opinions of course, and mine is no better than theirs (or vice versa). There are good reasons for the system as implemented, because all such things have trade-offs and a "pros and cons" list. I just don't care for it.
Sincerely, a developer.
A topic gets on the mind and people are ready to chat it out along a series of related comments sections. Nothing new or evil. It just might not be something you personally care about.
I mean, the first one I saw was Steve Yegge's so that lends a bunch of credibility but still, this is more than Baader-Meinhoff.
Whenever Java programmers discover a new language they get really excited, which is understandable. I am happy for them!
For example, adding modules to the language was 10 years in the making, and it was just rejected. Kotlin might not be the big change everyone would like but it will be seen as a better alternative.
HN is usually flooded with stories like "Show HN: I wrote a config parser in Rust" or "Show HN: a web server that serves JSON in Go", which are irrelevant to 90% of working programmers. We just get blind to it. There's no money at work there, just the enthusiasm of the users ... along with a dire need to spark enthusiasm in others given that Rust and Go hardly interop with anything except C.
Kotlin's getting a lot of attention right now, but it'll die down because Kotlin users don't need to win converts to their ecosystem. You won't be seeing the next two years of HN front pages be filled with "My experience of converting a microservice to Kotlin" type stories, because Kotlin users can just use all the Java and JVM ecosystem support already, so there's no need to win people over. Getting more Kotlin users in the world doesn't make a huge difference to your own experience.
This is even less of a reason to to be excited than when C++ came out, and solved none of the issues C had, just introduced a weak inheritance system, and search-and-replace level of meta-programming.