Live data from Hacker News

Kotlin 1.0 Released: Pragmatic Language for JVM and Android

blog.jetbrains.com

71–80 of 112 posts

Re: Kotlin 1.0 Released: Pragmatic Language for JVM and Android

#71
post #47

Congratulations to Andrey and the rest of the JetBrains team. This really has been a long time coming. I've been following and experimenting with Kotlin now for the past year or so and it definitely solves a lot of Java's pain points without having to reinvent the way one thinks about programming languages. The interoperability and backward compatibility is one of the most useful features, meaning I don't have to wai…

> Especially with Java9 on its way, it's only going to get better. What's Java 9 going to add that Kotlin can benefit from?

Presumably, they coexist; if you have a lot of old Java code, upgrading to Java 9 will likely be much easier than translating to Kotlin, but you still have a healthy codebase.

Re: Kotlin 1.0 Released: Pragmatic Language for JVM and Android

#72
post #50
post #37

Earlier quoted context omitted.

While it's an excellent example, I wonder if people don't see "endoMonoid" and run away screaming. I really wonder if people would have different reactions if this was presented as "Addable" instead.

Yeah, I wonder about calling it "addable" or "mergeable". But neither of those really captures the full generality of it - would you expect composing functions to count as "adding" or "merging"?

"Combinable"?

Integers can also be combined with other operations, like multiplication, min or max. None of those sound like "adding" or "merging" them to me.

Re: Kotlin 1.0 Released: Pragmatic Language for JVM and Android

#73
post #26

Earlier quoted context omitted.

No. Structural types are called structural types. The best known typeclass implementation is that of Haskell where they're built into the language, but Scala has them as a pattern implemented with implicits; I can try to explain the concept here if you like but honestly there are probably better explanations out there. Typeclasses are more powerful than structural types in that the implementation doesn't have to be t…

> The best known typeclass implementation is that of Haskell Oh, I don't know about that one. In Scala type-classes are interfaces and you can put that OOP to good use. For example in the Cats library, you get an Applicative type-class inheriting from Apply, a FlatMap inheriting from Apply and a Monad inheriting from FlatMap and Applicative. By comparison in Haskell a Monad is not automatically an Applicative and you…

He means best-known, not best known. It's a statement about which is better known, not which is better.

Re: Kotlin 1.0 Released: Pragmatic Language for JVM and Android

#74
post #69
post #53

Kotlin is a beautifully designed language: small, modern + statically typed that's naturally terse and elegant - ideal for both OOP and LINQ-like/functional programming: https://github.com/mythz/kotlin-linq-examples Thanks to JetBrain's tooling prowess it also has great integration with Android Studio - Light years better for functional programming than Java 1.7: https://github.com/mythz/java-linq-examples Which can…

You're really comparing a small subset of what "LINQ-like functional programming" is to the (small) pieces that Kotlin can do. LINQ is not (just) an interface over some collections. It is a comprehension syntax (that kotlin doesn't have) that works on any types that have Select/SelectMany/Where. This gives you a lot more power than what Kotlin gives you, as you can 'extend' other things that don't inherit from an IEn…

It's not a small subset, it's the most popular subset that .NET developers use LINQ for everyday as identified by C#'s 101 LINQ Examples and compares them against the equivalent code in Kotlin. The C# examples does use the LINQ SQL-like DSL whereas other languages get by with a more readable and less indirection version using functional API's available on collections. It's up to the developer which they prefer however the LINQ DSL is no more powerful than regular function chaining with lambdas.

LINQ also allows capturing Expression Trees however that's only useful for developers creating LINQ providers or where they need to capture and rewrite/reproject the expression. None of these examples are in the published LINQ 101 examples as they're usefulness is limited to a small niche of use-cases.

Re: Kotlin 1.0 Released: Pragmatic Language for JVM and Android

#75
post #56

Kotlin sort of feels like Groovy "done properly" (with no disrespect to the authors of Groovy). Groovy kind of evolved in an opportunistic, unplanned manner and ended up with millions of features, cool whiz bang aspects that look awesome that don't always turn out well when you use them on a large scale. Kotlin seems to capture the same ideas (highly pragmatic, maintain perfect bidirectional compatibility with Java),…

I like Kotlin, but I prefer Xtend. I find it to have even less verbosity and more expressiveness, and it uses the same Java types. I'm using Eclipse with it for now, but I prefer Android Studio. Congrats on the release!

Re: Kotlin 1.0 Released: Pragmatic Language for JVM and Android

#76
post #74
post #69

Earlier quoted context omitted.

You're really comparing a small subset of what "LINQ-like functional programming" is to the (small) pieces that Kotlin can do. LINQ is not (just) an interface over some collections. It is a comprehension syntax (that kotlin doesn't have) that works on any types that have Select/SelectMany/Where. This gives you a lot more power than what Kotlin gives you, as you can 'extend' other things that don't inherit from an IEn…

It's not a small subset, it's the most popular subset that .NET developers use LINQ for everyday as identified by C#'s 101 LINQ Examples and compares them against the equivalent code in Kotlin. The C# examples does use the LINQ SQL-like DSL whereas other languages get by with a more readable and less indirection version using functional API's available on collections. It's up to the developer which they prefer howeve…

>languages get by with a more readable

I'd love to see how you think the kotlin (or java) version of the following would be more 'readable'

     var result = 
         from a in taska
         from b in taskb
         from c in taskc(b) where c.Contains("blah")
       select c + a;

Re: Kotlin 1.0 Released: Pragmatic Language for JVM and Android

#77
post #76
post #74

Earlier quoted context omitted.

It's not a small subset, it's the most popular subset that .NET developers use LINQ for everyday as identified by C#'s 101 LINQ Examples and compares them against the equivalent code in Kotlin. The C# examples does use the LINQ SQL-like DSL whereas other languages get by with a more readable and less indirection version using functional API's available on collections. It's up to the developer which they prefer howeve…

>languages get by with a more readable I'd love to see how you think the kotlin (or java) version of the following would be more 'readable' var result = from a in taska from b in taskb from c in taskc(b) where c.Contains("blah") select c + a;

Again you're just cherry picking a rarely used niche example that benefits from a SQL-like cross join, that you couldn't even map to a real-world example. What's the point, to show it has terse syntax for rare use-cases?

Whilst the code is terse it's also deceptive as it's not obvious it's performing a cross-join over multiple collections - so even in this case I'd prefer using a nested maps which IMO is more readable as it's clearer what's actually happening. Readability != terseness, it's clarity of intent.

Re: Kotlin 1.0 Released: Pragmatic Language for JVM and Android

#79
post #77
post #76

Earlier quoted context omitted.

>languages get by with a more readable I'd love to see how you think the kotlin (or java) version of the following would be more 'readable' var result = from a in taska from b in taskb from c in taskc(b) where c.Contains("blah") select c + a;

Again you're just cherry picking a rarely used niche example that benefits from a SQL-like cross join, that you couldn't even map to a real-world example. What's the point, to show it has terse syntax for rare use-cases? Whilst the code is terse it's also deceptive as it's not obvious it's performing a cross-join over multiple collections - so even in this case I'd prefer using a nested maps which IMO is more readabl…

>Whilst the code is terse it's also deceptive as it's not obvious it's performing a cross-join over multiple collections - so even in this case I'd prefer using a nested maps which IMO is more readable as it's clearer what's actually happening. Readability != terseness, it's clarity of intent.

It has nothing to do with SQL cross joins across multiple collections.

LINQ is useful for things that aren't even collections! In my example I was using them on a Task to represent an asynchronous computation. This is common code we would write in a large C# application I was on at my previous job.

Re: Kotlin 1.0 Released: Pragmatic Language for JVM and Android

#80
post #46

Kotlin is currently my favorite alternative JVM language. Kudos to all collaborators for the great work. After 5 years of hard work, you finally made it! Here's a little starter project for Kotlin webapps using Spring Boot and React.js, I made a while ago: https://github.com/winterbe/spring-kotlin-react-demo

My humble contribution to the hipster-stack-starter-pack: https://github.com/herval/gradle-kotlin-docker-multiproject-... :-)

>Building a JVM container with Docker. So you can put your interpreter inside your JVM inside your Docker container inside your Kubernetes inside your VPS inside your OS and be happy.

I want to cry.

Post reply on HN