![[Home]](http://www.bayleshanks.com/cartoonbayle.png)
" Kotlin is a codename for a statically typed programming language compiled to JVMbyte code and JavaScript?.
Kotlin is backed by JetBrains?. Kotlin has language features commonly found in languages like Haskell or ML like algebraic datatypes and higher-order functions. On the other hand Kotlin supports language features commonly found in object-oriented / imperative programming languages. In some way Kotlin blends the two worlds like Rust does without becoming as complex as Scala and leaning a bit more to the imperative and object-oriented side of things.
Kotlin is able to interoperate with Java which implies that Kotlin will have access to Java libraries and frameworks. At the same time Kotlin focuses on being able to be used as a JavaScript? alternative and there is even work on an LLVM backend. Like Dart, Kotlin should therefore support using it as a server as well as a client-side language. And since JetBrains? is behind Kotlin - Kotlin will have great IDE support.
Kotlin seems to generally make most of my wishes true - of course not without some trade-offs. I also tried to implement the aforementioned project in Kotlin and although I didn’t get very far, simply because most of the features that would have been great for that project weren’t implemented yet, I could already see that the eventual program would be equally elegant as Rust.
There is a lot of stuff not yet implemented in Kotlin but the suggestions and ideas are there and they seem very promising. Altogether, I find that Kotlin finds the sweet spot just between being innovative / brave enough to introduce new syntax and semantics to encode common programming patterns and being familiar enough to get going with it quickly. I especially like the “zero-overhead null safety” in Kotlin which provides null safety without needing to use an option type. There are a lot more interesting things to find out about Kotlin (e.g. builder syntax) so take a look at their website if you’re interested.
...
Conclusion and comments
Again, all these listed languages are not in a production ready state yet but I’m going to check back in approximately six months and I hope that by then most of the rough corners will have been polished. I think it obviously came across that I like Kotlin and Rust best and so naturally I hope that these will be extra polished by then.
---
mike_hearn 23 days ago
| parent | on: Ask HN: Has anyone here programmed in Kotlin? What... |
There is a Haskell implementation for the JVM if you want a language like F# (it's called Frege).
Kotlin has some FP features. You can easily make immutable data classes (one line definitions of struct like things), you have map/filter/reduce/etc with a much more efficient approach than Java 8's streams framework, the compiler knows about tail recursion, there's some basic forms of pattern matching.
I suspect Kotlin will take a breather from new features for a while now to try and stabilise what they've got. But after that, I imagine a few more FP features might materialise.
---
cryptos 22 days ago
Kotlin interfaces are essentially the same as Java interfaces. But Traits in Scala are more like (slightly) restricted multiple inheritance. They can have fields, they can be stacked (http://www.artima.com/scalazine/articles/stackable_trait_pat...), you can restrict the types where a trait can be mixed in.
Value types are useful to enforce certain types which helps to avoid million dollar mistakes like the NASA made when mixing inch and meter as simple floating point numbers.
All in all I think, that Kotlin is a good example of the 80:20 rule. You get the most useful concepts and convenience with a low investment. Maybe Kotlin hits a sweet spot in the JVM landscape.
Bienlein 21 days ago
"Kotlin interfaces are essentially the same as Java interfaces." Interfaces in Kotlin offer functionality beyond interfaces in Java. In Java interfaces can only have public methods. In Kotlin interfaces can also have (abstract) variables. Both, methods and vars, in Kotlin interfaces can be public and also protected. You need this if you don't want to break the encapsulation of your classes that implement an interface.
mike_hearn 22 days ago
Yes, being able to define numeric units is a he
---
mike_hearn 23 days ago
| parent | on: Ask HN: Has anyone here programmed in Kotlin? What... |
Traits seem like an odd feature to pick. What are you thinking of, precisely? Kotlin interfaces are basically the same: they can contain method and property impls (same as Java 8). Do Scala traits have some additional feature I am unaware of?
I admit to a little bias: I've tried to get into Scala several times, but the bad documentation and often overly complex approach puts me off. A lot of Scala features seem like workarounds for other features sometimes. For instance value types in Scala have so many restrictions that they are barely value types at all (e.g. they can have only one member!) and so their primary use case appears to be implementing overhead free extension methods. But Kotlin supports extension methods directly. So whilst implicits+value types may appear to be two features that Kotlin lacks, when you boil it down, it turns out that it has simpler and faster approaches to the same thing.
That said, real value classes (with JVM support) will be good when they arrive.
https://news.ycombinator.com/item?id=9946527
---
