Kotlin is the hero Android needs(10clouds.com)
10clouds.com
Kotlin is the hero Android needs
https://10clouds.com/blog/kotlin-android/
179 comments
I am using Kotlin for a year now and man...it is a joy to use after Java. I don't care whether it is hyped or not I will never return to Java.
well more languages, with incremental improvements, isn`t always good
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
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 like kotlin and I am not angry about the news. I am angry because the people is starting to notice it now because Google bla bla bla. It is a great language, with or without Google, it is going to keep being a great language.
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)
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)
You're coming across as a Kotlin hipster. I would just be happy the language is now on more people's radar. Maybe some folks had never even heard of the language before this year's IO. Learning a new programming language and its idioms isn't a trivial time investment for devs swamped with work, so waiting until a heavy hitter like Google throws its weight behind it is quite a pragmatic approach.
I am happy more people is aware of kotlin now, I am not happy the people wasn't aware before. Even when you were pointing them to the goods of the language. But still I trust more JetBrains than Google for programming langues, only because is a company that create tools for programmers, they have more experience.
The suitability of a language for a particular project doesn't just depend on language features.
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.
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.
That's still nothing to be angry about. That's like being pissed off that more people are suddenly talking about your favorite author after he wins a Pulitzer. Being adopted as a fully supported language by the platform maintainer is about the biggest milestone it could achieve, of course more people are going to take notice.
[deleted]
> I wish the people would have more critic sense and asses the things by themselves before a big company says anything.
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.
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.
> learn with the support of a large company.
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.
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.
> There were so much hype about swift
Probably would have had the same as Kotlin if Apple hadn't announced it in WWDC.
Probably would have had the same as Kotlin if Apple hadn't announced it in WWDC.
The hero that android needs is a complete rewrite of Activities and Fragments into something that makes sense in a stateful application
I was gonna go with "a complete rewrite of the API/SDK by someone other than (apparently) the Summer interns" but yeah, that's a big part of it.
Kotlin was not required. Android developers keep losing focus on what's more important and what's less; with the dance of variations of MVP patterns, RxJava, 10 ways to do the same shit. Now even Google has to focus on 2 things, providing support for 2 languages. Java 9 is on the verge of being released and we are just getting parts of Java 8. Yes, we do not need all features, but what we actually need is FOCUS.
What would you like "us" to focus on? As for MVP variations and RxJava, those are useful tools. MVP variations are often for organization and writing more modular, testable code. RxJava and other Rx implementations are useful for describing data flows and transformations while also making complicated asynchronous problems more manageable.
MVP & Rx are good, no doubt. But there are a crazy amount of Pundits preaching different variations and thanks to the internet an early developer/beginner is confused. I have spent several hours helping others rectify basic mistakes. There should be some serious and well-documented approaches to achieve something (a performant app in this case). Decay is also important. As frameworks mature and android itself moves ahead, old documentation or answers which no longer have relevance should be purged. Android documentation itself boasts old sample codes, while the framework has deprecated some of them. The problem which OEMs faced are being resolved now, but the reality is it will take another year or two for it to come live. In 2013 Huawei had come up with its own extension to segregate its own modification with vendor and base; very sure that's not getting removed at least in the next 1 year.
Check out architecture components announced on Wednesday, I think you'll be interested in LifecycleObserver and LifecycleActivity
Right. Fundamental flaws in the architecture that they try to paper over with some half-baked library that stays stuck in beta forever, is poorly documented, has major bugs and oversights, and in the end does much less than what you would expect. See: databinding library.
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.
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.
but we don't get the hero that we need. Kotlin is the hero we deserve...
I am what they call a Dilbertish Java Developer and I really like what they've done with Kotlin, wanted to jump ship to .NET ecosystem just because of C# but now I changed my mind. Articles like this are focused on syntactic sugar and kool-aid. What I really want to know is the following:
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?
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?
> How different is idiomatic Kotlin in respect to Java?
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.
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.
> Remember POJOs? With the introduction of Kotlin’s data classes, we can say goodbye to generating the getters and setters for all object fields and writing implementations of toString(), hashCode() and equals() methods. Instead of 50+ LOC in Java, we can reduce that number to 1 (!) in Kotlin.
So this is like Python's attrs module
So this is like Python's attrs module
It's very sad that our industry is so hype driven.
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.
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.
The funniest part is how much this discussion sounds like the Java vs. Perl on web programming from decades ago.
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.
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.
But it doesn't seem better enough to force old Java dogs to care for new tricks.
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.
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.
> 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.
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.
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.
I find Scala suffers from similar problems you find in Haskell or C++: an overly complex type system, obsession with operator overloading, way too many ways to do things leading people to find a "manageable subset" they can deal with. Like Haskell (and its many extensions), 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.
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!
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!
Scala has no operator overloading. You cannot blame language on somebody picking bad method names. There are plenty of bad names in Java and Kotlin libraries as well.
> 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.
> 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.
[deleted]
[deleted]
[deleted]
Kotlin is a smart subset of Scala.
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.
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.
> Kotlin is a smart subset of Scala
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.
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.
Scala does all the features of Kotlin equally well, not 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.
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.
I have written Scala code and kotlin code, and it is much more legible the kotlin code. When I tried also there were problems calling Scala code from Java (I think there were problems with the type inference system that was giving me non-sense errors). Scala adds like 500kb to an Android app, kotlin only few kb. The compilation times are much faster with kotlin, the tooling support is also better. It is easier to become more productive with kotlin than with Scala.
> 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?
> 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?
> Scala adds like 500kb to an Android app
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.
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.
I totally agree. My main point against Scala is the mass of features, it's like a modern C++. In the worst case you end up with a dev team in which everyone codes in his very own style.
> 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".
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:
[1] - https://github.com/builtamont-oss/cassandra-migration
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:
[1] - https://github.com/builtamont-oss/cassandra-migration
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.
Uh.
Yeah. Exactly.
Uh.
Yeah. Exactly.
I see Kotlin as a fixed Java, not a subset of Scala. While both may be true views, I think the "fixed Java" view explains the drama behind the announcement.
Kotlin is better at being Java than Java is. Scala is not.
Kotlin is better at being Java than Java is. Scala is not.
Ever tried to code a robust Android app in Scala? It's a nightmare. Kotlin you just plugin and you can convert your source files very easily. I would agree syntax is not that much different but the compatibility is.
Scala has the same problem as java. Too many different opinions on how to do things. Too much cruft and ways to shoot yourself.
I see Kotlin as a clean-up job of a lot of syntax design flaws in java.
I see Kotlin as a clean-up job of a lot of syntax design flaws in java.
[deleted]
Should someone that's starting to learn native android development switch to Kotlin, or is it better to learn Java first?
I knew C++, and went straight to Kotlin when I started Android dev. Haven't felt like I'm missing much with Java. Kotlin is often similar with nicer syntax; it'll prepare you to read Java just fine, and if you need to write java later, there's time to learn, then.
Learn Java first. You must be able to read existing code at least from StackOverflow and it's Java.
I'd go with Java and the standard APIs at first. Kotlin looks very similar to Java just less verbose (I have not used it) and they say that you can mix it in with Java if you like.
Kotlin uses Java Byte-Code and JetBrains has put in a lot of effort to make it so that any Java you do write can be automatically translated into Kotlin in their IDE's. Idk how well this works because I haven't tried it but apparently it worked well enough for them to try and do it with JavaScript as well which is still in Beta.
It works well. The resulting code often won't compile without manual changes on the Java side, but they're simple changes, and it does automate 90-95% of it. I've never yet introduced bugs this way. It doesn't produce idiomatic Kotlin, of course.
It's also a nice Rosetta stone while learning Kotlin.
It's also a nice Rosetta stone while learning Kotlin.
I just started trying to pick up Android development in the last few weeks. I'm comfortable with Java from college, but don't really keep up with it or the ecosystem. Should I consider Kotlin for learning the platform with, or are the docs and learning resources Google provides not up to speed yet?
Note: I'd eventually just use Kotlin anyways cause I don't care all that much for Java.
Note: I'd eventually just use Kotlin anyways cause I don't care all that much for Java.
[deleted]
It's easy to use Java libraries from Kotlin, to the point that there's nearly a 1:1 syntactic mapping. So in my opinion, yes, you should be able to use Kotlin from the start.
That said, I've never written an Android app. There may be issues with that particular platform.
That said, I've never written an Android app. There may be issues with that particular platform.
If you can read code in Java, then you'll be able to pick up Kotlin within couple of hours, the only difference in Android APIs in Kotlin are the nullable types as parameters
Its not a hero and android doesn't need it. Android is a near monopoly, they could tell us to start programming in Ada and we'd all have to follow along whether we wanted to or not.
Java is baggage ridden. I wonder if Java would've been the language of choice had Rust or Go existed when it was started.
Java is baggage ridden. I wonder if Java would've been the language of choice had Rust or Go existed when it was started.
I don't see how this is at all true. Android store is unregulated and allows anyone to submit a crApp. This language looks stupid and it's no different than a dozen other languages in principle. Why not port Swift to Android so we can truly write once and run on two places?
[deleted]
What about Clojure? If Kotlin works for Android, shouldn't Clojure by now?
Clojure is unfortunately implemented in such a way that makes it extremely slow to load/start. It's really only suitable for heavy duty long running servers where you don't care about startup time or resource usage, the exact opposite of what android apps need. It's sort of sad to see such an amazing language packaged up in a J2EE'ish manner.
Probably same issue as talked about here, maybe even to a larger degree
https://news.ycombinator.com/item?id=14368125
https://news.ycombinator.com/item?id=14368125
I had mixed feelings about Kotlin when I first heard about it. Usually I wouldn't think twice about a language developed and championed by a small company. But the "small company" being JetBrains, I had a feeling it would be well thought out with a good IDE. It doesn't seem like I'll be disappointed. I've avoided Android development because I dislike both Java and Eclipse. Both of those problems seem to be solved. Now of only the emulator was better and building GUIs....
The Kotlin interest strikes me as funny, it feels like Java programmers are just realising what the rest of us have been using for years is pretty nice.
Is it easy to learn for someone who doesn't know any programming languages beforehand? Like I only know a bit of JavaScript
The strong point of kotlin is definitely that it's "java pseudocode" - it's what you'd have to write on a whiteboard to leave no questions about what was elided. Like data classes - in kotlin you write the attributes, but get setters and getters, so you could to validation on change or whatever you might need steers for beyond beans.
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.").
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.").
Okay thanks, maybe I'll go into it through Java.
To be clear: I believe kotlin is a much better language to start with than java (but then, java is a pretty awful language inmho). But I've yet to see or read/hear about any books for teaching programming through kotlin as a ~first programming language (while there are many for python, ruby, java etc - or even lisp/scheme).
I would probably rate kotlin as a better starting language than javascript, for that matter.
I would probably rate kotlin as a better starting language than javascript, for that matter.
Wow that's a big one then, I wasn't a Computer Science student but I like tech. Tried to learn Java a couple years ago and gave up, decided to go with HTML/CSS on Codeacademy as baby steps and did Javascript from there. If Kotlin is easier than that I'll definitely try to learn it ASAP I'm really interested.
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 expressionsKotlin examples on the site are not much different from Java ones. They're almost identical in length. Why bother to use it and add one more step for translation to a compiler chain that is already very slow.
Same with Scala. I once ported a Scala program to Java one and ended up with much shorter and concise code.
Same with Scala. I once ported a Scala program to Java one and ended up with much shorter and concise code.
Compiles aren't that slow compared to other languages and Kotlin compiles directly to bytecode, not through Java, so its replacing the last link on the chain, not extending it.
> Why bother to use it and add one more step for translation to a compiler chain that is already very slow.
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 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.
But, from what I know, Scala is compilation is really, really slow. So if you're only familiar with Scala and not Kotlin, you may get the wrong idea.
Few days back I start investigating Kafka for our project. I was under the impression that it was all Scala. But downloading, setting up, and reading document I realized that a large amount of Scala API is deprecated and replaced with newer Java equivalents.
Hmm, migrate to Java from Scala in search of shorter, concise code? Something tells me the Scala developer in that case basically wrote Java code to begin with.
> 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 don't see why you are surprised. Especially at the concise part.
Does anyone know of something like hyperpolygot.org for Kotlin? I guess my main question is can anonymous functions be nested with out requiring final in Kotlin? Java requires final either implicitly or explicitly which makes anonymous functions rather uslesss.
I've been watching this for a bit - it is my understanding that large parts of IntelliJ itself are written in Kotlin.
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.
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.
Title is hype. IMO the hero Android needs is root access to be accessible easily out of the box. Buying closed phones is a fool's game.
Sincerely, a developer.
Sincerely, a developer.
It's just Java with a few Swift features. The only thing Kotlin does is help you to be more efficient at writing terrible OO code.
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.
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.
Did someone spend some cash on 'promote this link' for Kotlin today? It seems like we've had a flood of Kotlin links.
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.
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.
I think you're just underestimating the huge number of Java programmers in the world, and what this announcement means for them, that's all.
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.
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.
Java has become entrenched as a corporate language. Kotlin on Android has a chance to make Kotlin a real alternative to Java, which has been extremely slow to change over the years.
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.
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.
Google making Kotlin an official Android language has everyone freaking out.
Whenever Java programmers discover a new language they get really excited, which is understandable. I am happy for them!
Whenever Java programmers discover a new language they get really excited, which is understandable. I am happy for them!
Whichever language is promoted as an alternative to Java on the JVM, i'll support. We need to let that crippled, oracle-owned dinosaur die and move on to better technology.
Did anyone said Kotlin?
So... I just started getting into writing an Android app. What would be the advice... I installed Android studio last week, is that still a preferred IDE?
I would say yes. After having horrible personal experiences using Eclipse and Android, Android Studio is more immersive, and I think it's the approach Google wants developers to use. If you're not going to use Kotlin or Java for Android development you would use the other IDE's for those other stacks / approaches, otherwise Android Studio is fine.
Yep, don't know if you can change the channel in settings to get canary updates, but either way I installed from here: https://developer.android.com/studio/preview/index.html
edit: I'm assuming you want, like me, to try Kotlin
edit: I'm assuming you want, like me, to try Kotlin
You don't actually need to use the 3.0 preview for kotlin development in android. You can use the stable version and just follow the instructions provided by jetbrains: https://kotlinlang.org/docs/tutorials/kotlin-android.html
I personally prefer a mix of studio and vim. I'm more productive writing and refactoring in vim but studio is a head and shoulders above for fixing compiler errors. (alt-enter)
WTF? Some people are spending serious money on a PR campaign to promote Kotlin this week!
1. Android is the largest mobile platform on the planet.
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.
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.
What?!
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.
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.
Maybe the OP meant using C++ without at least a Application dispatcher/container object written in Java. This has only been possible with the introduction of NativeActivity (which you don't need to derive from, but only refer to via the Manifest).
The NativeActivity class was introduced in Android 2.3, released in December 2010, almost 7 years ago!
Historically the Android platform provided only a very minimal C++ runtime support library, with no RTTI or C++ exceptions.
STL and exceptions are available since Android NDK Revision 5, released in December 2010, alongside Android 2.3.
https://developer.android.com/ndk/downloads/revision_history...
How can it be historically, when the features are available since almost 7 years?
https://developer.android.com/ndk/downloads/revision_history...
How can it be historically, when the features are available since almost 7 years?
No man, next week the threads will be: Why I moved from Go (Or whatever was the FOTM) to Kotlin.
That will be a short article, though: "Because Go doesn't really work on Android. In fact, I don't even know what I was thinking. Seriously. Why'd I do that?"
(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)
(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)
It's not about android. People will start using Kotlin everywhere.
Remember Swift hypetrain a year or so ago? I do. People even made web frameworks with it.
Remember Swift hypetrain a year or so ago? I do. People even made web frameworks with it.
7. Oracle can't sue Google over Kotlin.
You can write android apps in c# or JavaScript too.
I'm not sure if you consider them "supported" but they both have pretty advanced tooling for the purpose.
I'm not sure if you consider them "supported" but they both have pretty advanced tooling for the purpose.
If you write a C# app with Xamarin and have problems, then it's Xamarin's support problem. If you write a JavaScript app with Qt (I assume?), then it's Qt's support problem.
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.
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.
Google support - you mean this 50cm thick concrete wall developers and users are banging their heads on when they want some bugs fixed? Like e.g. this: https://productforums.google.com/forum/#!topic/hangouts/A5Rp...
What are you going to do if your Kotlin app has some problems? Call Google on the phone? Write and email and expect an answer?
You can write a forum post. And then you'll get confirmations from another 100 developers, so you'll definitely feel a bit better and not alone in your pain. ;)
Not really.
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.
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.
The C# tooling is good but it's partially closed-source and sold by a vendor (Xamarin). On that basis I don't think it really 'counts'. JS does, at least, since there are many ways to ship JS-based Android apps for free.
Xamarin got bought by Microsoft, and they opened almost everything from Xamarin, except Xamarin Studio which got rebranded as Visual Studio for Mac.
> 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.
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 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.
The list of events seem pretty connected.
I doubt it's being paid promoted, but I don't think your cynicism is unreasonable. It is pretty obvious that the big tech companies maintain a presence on this board and attempt influence through human and automated measures.
Yeah. Those nefarious Elm and Nim cartels, using Russian hackers to push their #fakenews to the top of HN every other week.
(I feel like I'm living through a bad acid trip)
(I feel like I'm living through a bad acid trip)
Eh, neither Nim nor Elm are backed by huge companies. You'll want to look at Rust and Swift for that. ;)
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.
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.
> You'll want to look at Rust and Swift for that. ;)
Is Mozilla a "huge company"?
Is Mozilla a "huge company"?
Any community of sufficient size and influence invariably becomes an astroturf target.
As someone who's become adept with a few modern statically typed languages (C#, TypeScript, F#), and still sometimes has to write (pull teeth) crufty old Java for Android development, I can tell you that I'm happily pitching into this PR campaign unpaid and of my own volition.
I wouldn't be surprised if money wasn't involved, HN has always worked like this.
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
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
Kotlin is simply a much more modern option than Java in general, and doubly so for the old version of Java used for Android. Giving Kotlin some official backing gives it a lot of credibility. The big argument favour of using Java over Kotlin until now has been that Kotlin was seen as more of a fringe language than the one (Java) officially endorsed by Google. Now that has changed. As a Scala developer I'm quite happy that Kotlin is getting this much attention as I see it as Scala-lite. I doubt there's a campaign of any sort, just lots of excited developers who are sick of Java and excited about Kotlin.
You see too much into this. It was the same wave of HN interest when Swift was launched, back in 2014. Or when RubyMotion was announced a few years ago.
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 ...
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 ...
People are just excited. Articles I have seen so far don't sound like PR. People are just excited that they will have an alternative to Java.
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.
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.
I think it would behoove you to use Kotlin. When every other post on this board is about Kotlin, it is clear that is where the industry is headed. Use Kotlin, or risk being left behind.
Edit: Kotlin. Kotlin. more Kotlin.
Edit: Kotlin. Kotlin. more Kotlin.
"But it was all right, everything was all right, the struggle was finished. He had won the victory over himself. He loved Kotlin" - George Orwell
Um, no. What happens on HN is nowhere near an industry driver. It's better than many forums, but it's not some powerhouse of technology industry influence, nor does a trending topic on HN necessarily indicate a particular trend in the industry in general.
Successful in spite the of the name
Couldn't be that people are actually hyped about Kotlin?
Couldn't it be that we are all hyped about Kotlin because we read a new article about how incredible it is every 10 minutes? Chicken and egg.
No, because Google dropped huge announcement that Kotlin will be first-class citizen on Andorid. And there were people who like Kotlin, but knew it will be hard to use it in real life. They are happy now and having a moment. With time this wave will decrease, and something other will come. That's normal.
Is it possible that Google views JetBrains as an acquisition target?
I have been hoping for this move, and then Google using Kotlin for Android. They made the smaller step of officially endorsing Kotlin which I think helps, but acquiring Jetbrains and opening the entire Intellij would be huge for the developer community, Android, Kotlin, etc...
Of course that assumes Google doesn't drop support a year later.
Of course that assumes Google doesn't drop support a year later.
Yeah, please, no. Jetbrains have been a consistent, effective, and mature presence in this world for a long time. The last thing I would want would be to inflict Google's capricious approach to acquisitions on such a valuable player.
Anything is possible but I believe both parties have stated they're happy with their current relationship and no one is looking for acquisition.
To put it into more perspective, I live in Orlando and Kotlin has been the new growing language for Android since before the announcement. Developers wind up trying Kotlin for themselves and enjoying it for themselves, the rising numbers and the fact Google realized it's popularity and adjusted their support for it shows that Kotlin is a reasonable solution for Android development. It also doesn't help the fact that Java is hostile against Android, and that Kotlin is working on native compilation, which could make it one day one of the most powerful assets of Android if they go full on for native compilation for Android, a benefit that afaik Java doesn't have.
The same thing of thing happens during/immediately after Google I/O, Microsoft Build, Apple WWDC(?), etc.
Hype can also occur (somewhat) naturally. It does happen.
Hype can also occur (somewhat) naturally. It does happen.
News tends to follow current events.
Can someone compare their productivity with React Native or Xamarin to "native" Java/Kotlin development? Having used RN, the whole state/data layer can be shared across two platforms, and I guess the same is doable with C# and Xamarin. I get that both require bridges when interfacing with ObjC/Java, whereas Kotlin seems to have great (but only) Java interop.
I can only say I'm way more productive in Xamarin than I am in Android native with Java, I do a fair bit of both. I'm excited about Kotlin and will definitely give it a try, but Xamarin does still retain some advantages over Kotlin, even though it seems to be a slightly more advanced language than C#:
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?"
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?"
> 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.
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.
[deleted]
That is my experience as well with Xamarin.
I haven't used Xamarin. React Native I have used. You can make some stuff really fast but I feel like some stuff is unfinished at this point. As an example simple navigation does not feel complete with React Native.
"Remember filtering lists with for loops? Thanks to the functional approach to collections, we can also reduce all the complex, multiline instructions to only one line of code."
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.
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.
Even after 10,000 armchair lawyer discussions about the Google-Oracle lawsuit, I feel like 99% of developers still do not grok that Android's "Java" isn't really Java.
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.
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.
Aka language fork.
True, but the stream API isn't very friendly. You have to get a stream (.stream()), filter, then collect in a collection (.collect(..)) for which you need to find a suitable collector (the stdlib supplies some for lists and maps, but you have to find where they are defined).
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.
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.
Actually I'm not sure if Kotlin's code is that performant. It'll create new ArrayList on each step just to discard it after. It won't matter for tiny lists, but even for moderate lists it does matter. If you want to iterate without creating new arrays on each step, you'll need to use Sequence. And now there's another problem: Sequence doesn't know its lengths. So when you'll collect computation result, you can't just allocate exact memory, you'll need to allocate some memory, then grow it, and so on. Java streams are lazy and they try hard to know expected output size, so they are better in some aspects.
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.
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.
You don't have access to this API in Android.
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.
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.
The last time I looked, Java 8 wasn't available (and probably never will be?) available on Android, which is what this article is talking about.
Edit - http://www.infoworld.com/article/3180758/mobile-development/... it looks like Android is gaining Java 8 support now
Edit - http://www.infoworld.com/article/3180758/mobile-development/... it looks like Android is gaining Java 8 support now
No, some Java 8 features are available (https://developer.android.com/studio/preview/features/java8-...) but streams are only available on Android Nougat
Wow! One line of code that is 400 characters long and difficult to parse! I don't know anyone worth their salt who writes functionally that doesn't use line breaks liberally to make things readable.
Functional programming has very little to do with terseness IMO.
[deleted]
What's with the kotlin hacker news spam this week? Isn't one article enough?
This is pretty common on HN.
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.
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.
During Google I/O it has been announced as a officially supported language in Android to the same level as Java, so all documentation, tooling, etc, will have a Kotlin version. Therefore, everybody wants to know more about this language.
Thats right, forgot google io stuff is going on, makes sense. After a apple keynote we see ipad and swift flooding to the top.
Someone in an earlier Kotlin discussion (there has been quite a few just today) was praising how Kotlin solves the "1M$ mistake" having no null. He was also complaining that sadly is day-to-day job involves Go.
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?
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?
The only way b.length would compile, if b is a nullable array, is if it's defined in a Java class. In which case Kotlin will assume it's non-nullable in the absence of nullability annotations. That is not perfectly ideal, but it's not Kotlin's fault; they decided (rightly, I think) that the reduced friction is worth the risk. And you can add annotations.
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.
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.
b.length on a nullable type wouldnt compile in Kotlin.
Genuine question: what is wrong with Java from a pragmatic point of view?
One major issue is that Android only supports java 6. All the nice things java 8 brings aren't available. With Kotlin officially supported in Android, you can finally have nice things.
Java on Android is not the same as the latest stable Java from Oracle. Example, there is no complete Java 8 support on Android, only a few things were ported and these are only available on latest versions of Android. The problem is that on Android land people don't/can't upgrade as easily as on iOS, so as a developer you are stuck on Java 6/7.
I don't know about "wrong", per se, but one pet peeve of mine as it relates to Android development is the callbacks system that is ubiquitous in the API. Since functions don't exist in Java except as methods of a class, this means what should be a simple function definition and use of it (e.g. via a pointer) requires at least a class wrapper. It's pointless to have to write it. And this indicative of development in Java, especially for the Android platform, in general.
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.
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.
1: https://en.wikipedia.org/wiki/Usage_share_of_operating_syste...