5 ms·
Kotlin's taken over HN.
by subsidd 9y ago
Kotlin's taken over HN.
- softawre 9y agoDeservedly so. It is a great language, and it's backed by the ultra-power JVM. You can use a hipster language with great features and still use JodaTime and maven and all the enterprise stuff that just works.
- subsidd 9y agoAgreed.
- betatest 9y agoWhat exactly make it a great language? What are the advantages compared to Java? I search for it but couldn't find any simple answer to that question. The fact that things are shorter to declare doesn't make it better. It makes it less readable.
- torinmr 9y agoI haven't used Kotlin, but glancing over their comparison page the one that jumped out to me was that it (almost) eliminates the possibility of null pointer exceptions: https://kotlinlang.org/docs/reference/null-safety.html https://kotlinlang.org/docs/reference/null-safety.html
- thatswrong0 9y agoThis is my litmus test to determine whether a modern language is not terrible. Why wouldn't you want to eliminate an entire class of errors? Unfortunately, my day to day language at work is Go.
- tathougies 9y agoThis is like an entry-level expectation for a modern language. Hardly something to write home about in this day and age.
- fixermark 9y agoIt is when you bring it first-party to a platform the size of Java. The userbase of Objective-C was much smaller before OSX brought Cocoa to the Mac ecosystem.
- itp 9y agoFor advantages (and some disadvantages!) compared to Java, I'd start with https://kotlinlang.org/docs/reference/comparison-to-java.html https://kotlinlang.org/docs/reference/comparison-to-java.htm....
- ionforce 9y agoA wide array of quality of life changes to Java. > The fact that things are shorter to declare doesn't make it better. This is debatable. In fact, shorter code could (but not always, of course) mean less room for error and more room to hold higher abstractions. Boilerplate is a less efficient use of cognitive energy.
- jakub_g 9y agoAgreed, with an exception of magic non-standard out-of-context characters (#$=%>^<) with non-intuitive language-specific meanings; see bash, perl, angular... I prefer short textual keywords 99% of the time
- kbenson 9y ago> The fact that things are shorter to declare doesn't make it better. It makes it less readable. That's not a hard and fast rule. There are obvious inflection points. A 200 character long identifier is less readable than a 20 character identifier in almost all cases. A 1 character identifier is less readable than a 8 character identifier in almost all cases. Somehwhere between those extremes is the sweet spot, and it's likely somwhat different depending on person. As for language keywords, as long as they are unique, unambiguous, and not likely to conflict with written code often, shorter is likely better since it's purely a matter of learning them when learning the language. Given those constraints, it's easy to see it's possible to be too short though (any single character keyword that is not context sensitive is likely a horrible choice).
- sevensor 9y agoSteve Yegge drops a blog post, and we all freak out :) He needs to get back on a regular scheudle so we can react like reasonable people to the next one.
- dtech 9y agoProbably a spike in interest/activity/articles because of Google's announcement that it now is officially supported on Android.
- subsidd 9y agoAlso because some of us absolutely needed a break from java.
- miguelrochefort 9y agoStill looks like Java.
- Filligree 9y agoNot past the first day. Kotlin code can be beautiful, and I've yet to see beautiful Java code.
- dcow 9y agoNot even a bad thing. It's a pragmatic JVM language. It's 100% interoperable with Java without baggage like Groovy has. It's probably going to look like Java. Scala can look like Java if you write it very imperatively. What's nice about Kotlin is that the language supports idioms that allow you do diverge from "looking like Java" as you write it more.
- vorg 9y agoHope we never see "looks exactly like Java syntax but behaves differently when you run it" like we see in Apache Groovy, e.g. their == operator acts differently to Java's.
- meddlepal 9y agoPretty much every language's `==` operator acts differently and more sanely when compared to Java's. Groovy had a very different initial design philosophy compared to Kotlin. The Groovy design philosophy was give Java developers a good highly-dynamic scripting language that still felt like Java but also made it more suitable for writing quick and dirty plugins, scripts and other extension bits to Java programs. Kotlin is more in the "Java is great already, but has a lot of legacy issues, let's take all the stuff learned in the last two decades and make a Java++"