Live data from Hacker News

Learn Kotlin in Y Minutes

learnxinyminutes.com

141–150 of 239 posts

Re: Learn Kotlin in Y Minutes

#141
post #104

Earlier quoted context omitted.

Mutable hashmap/associative array/whatever literals like: var map = {"a": 6, "b": 12} [Whatever list type is most common/idiomatic in Kotlin] literals like: var list = [1, 2, 3] etc. Plus list/map comprehensions like Python or Haskell, as you mentioned. Not a big deal or anything. It's only a little bit of extra typing. And the syntax sugar they do add is definitely a massive step-up over Java. I know it'd be hard to…

While somewhat longer, you do have var map = hashMapOf("a" to 6, "b" to 12) var list = listOf(1, 2, 3) This is still not Java-level verbosity.

I like that a lot, but the `to` syntax bugs me. Why not a colon, or Scala's `->`?

Re: Learn Kotlin in Y Minutes

#142
post #31

Earlier quoted context omitted.

I 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

This is like an entry-level expectation for a modern language. Hardly something to write home about in this day and age.

It 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.

Re: Learn Kotlin in Y Minutes

#143
post #66

Earlier quoted context omitted.

The language itself isn't 'more cool' or better, but the risk profile of adopting it has dropped dramatically. That makes it much more interesting.

There weren't any risk before apart form the kotlin plugin not working with beta versions of the gradle build plugin. Using kotlin in Android is like using a library, and you don't have official support from Google for all popular libraries used in Android.

There are risks other than just not being able to build it.

If I have an app with a codebase in a language that very few people know, that's a risk. What if my main developer leaves and I need to find someone else to continue working on the code base?

You can now bet that a lot of people will be picking up Kotlin as a result of the latest announcement.

Re: Learn Kotlin in Y Minutes

#144

> Declaring values is done using either "var" or "val". "val" declarations cannot be reassigned, whereas "vars" can. I wonder why they decided on these very mistakable names. Why not const/constant/cons/whatever else just as long it's distinguishable from each other?

I bet you can change the val color to something that contrasts the var color in an IDE.

Re: Learn Kotlin in Y Minutes

#145
post #84

Earlier quoted context omitted.

If your 'let' doesn't propagate so that immutable collections are used, it's not very valuable. Just like 'final' in Java doesn't prevent anyone from mutating your ArrayList. Using 'val' instead of something more suggestive like final/const/'not mut' seems a lot nicer to me. (Edit: and indeed Kotlin having "mutableListOf" and "listOf" separation is a good step in readability. The val/var before either of those is les…

I thought that's how the majority of languages worked. It just means the variable cannot be changed to reference a different value. It does not make the value immutable.

In Rust, it does (in general) make the value immutable. Most mutations of values in Rust are done through mutably borrowing the value, which you can't do when the value is defined with `let` rather than `let mut`, the exceptions being things like `Mutex`, which gives you a value that can be mutably borrowed when you acquire the lock.

Re: Learn Kotlin in Y Minutes

#146

> Declaring values is done using either "var" or "val". "val" declarations cannot be reassigned, whereas "vars" can. I wonder why they decided on these very mistakable names. Why not const/constant/cons/whatever else just as long it's distinguishable from each other?

Kotlin as a language has expectations on IDE capabilities. I doubt the problem of accidentally typing "r" instead of "l" at the end of a keyword is as prevalent as someone typing "var" instead of "const" and not coming back to make it immutable. A quality compiler can warn about an unmutated mutable variable which solves all problems. Remember recently on the Java mailing list there was a lot of bikeshedding concerni…

my beef is with 'val' being keyword. How many variables did you name val in all your coding? I certainly did.

Re: Learn Kotlin in Y Minutes

#147
post #79

Earlier quoted context omitted.

Still looks like Java.

Not 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.

Hope 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.

Re: Learn Kotlin in Y Minutes

#148

Earlier quoted context omitted.

If a language or tool is officially supported, then that means the project maintainers (Google, in this case) promise to support its use with official documentation, priority bug fixes (for example, if an Android update breaks your app which is written in Kotlin and uses only public, non-deprecated APIs, Google will consider it just as high-priority a bug as if it were written in Java), and first-class access to new…

JetBrains is doing this, not Google. Google is only going to collaborate with JetBrains to help with the Android support. > Android update breaks your app which is written in Kotlin then it also breaks the same app written in java. Because the good thing about kotlin is that it is transparent, it generates bytecode as java does. So from the point of view of the platform there is no difference between kotlin and java.…

> JetBrains is doing this, not Google. Google is only going to collaborate with JetBrains to help with the Android support.

Jetbrains isn't doing anything differently with Kotlin from what they've been doing for the past 7 years. The headline here is "Google officially supports Kotlin on Android," and that is what has HN so excited. Regardless of how the work involved in supporting Kotlin on Android is split, this represents a guarantee that did not exist before. If all Jetbrains employees were abducted by aliens tomorrow, Google will now still have committed to first-class support of Kotlin through the next couple of major versions of Android.

> then it also breaks the same app written in java. Because the good thing about kotlin is that it is transparent, it generates bytecode as java does. So from the point of view of the platform there is no difference between kotlin and java.

They share the same compilation target, not the same semantics and idioms. Just because Go, Haskell, C and LuaJIT all target x86 assembly does not mean a Linux kernel update won't break a properly-written program in one of those languages but not the others. This in fact happens all the time.

> This makes me think you don't know how kotlin works. You can mix java and kotlin files in the same app and call methods from one to the other without problems.

I was answering their question generically. But first-class official support means that, for example, if Google adds a new feature to the [Java] Android Runtime, they will, where relevant, now ensure it's implemented in the official Android Kotlin compiler as well as the Java compiler.

Re: Learn Kotlin in Y Minutes

#149

Earlier quoted context omitted.

Kotlin as a language has expectations on IDE capabilities. I doubt the problem of accidentally typing "r" instead of "l" at the end of a keyword is as prevalent as someone typing "var" instead of "const" and not coming back to make it immutable. A quality compiler can warn about an unmutated mutable variable which solves all problems. Remember recently on the Java mailing list there was a lot of bikeshedding concerni…

my beef is with 'val' being keyword. How many variables did you name val in all your coding? I certainly did.

`val` is never an appropriate name for a variable because it tells you nothing at all about what the variable contains.
Post reply on HN