Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Kotlin 1.0 Released: Pragmatic Language for JVM and Android

blog.jetbrains.com

Post reply on HN
Print view View original

21–30 of 112 posts

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

#21

Post by lmm »

pswenson wrote: post #15
lmm wrote: post #11

Earlier quoted context omitted.

Maven is fantastic in my book. Literally the best build system I've seen. But even if you disagree with me on the specifics, if there's something you want to change about one of those tools, surely you'd want to make the same change when building Java? I don't see any value in rewriting one of those tools in Kotlin to make it Kotlin. (And if some particular idea is easier to express in Kotlin, I've written Maven plug…

how do you do conditionals or loops in maven?

You don't. If you need to run custom code in the build you have to encapsulate that as a plugin (which will be a first-class maven module in its own right, which naturally nudges you to writing unit tests, having a proper release process with semver and so on for your build step). But mostly you keep your build simple and declarative and you put any business logic in the actual code. It's wonderful.

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

#22

Post by lmm »

pswenson wrote: post #18
lmm wrote: post #13

Earlier quoted context omitted.

There's no clear separation between build config and random Groovy expressions. There's not even a spec for what a .gradle file looks like. That's fine for "get this done quickly", but ultimately it encourages people to put one-off hacks in the build file that become a maintainability nightmare. (And because its "config" files are arbitrary turing-complete code, its IDE integration is never going to be as good as Mav…

So I think gradle has a lot of problems, but having access to Groovy anywhere is a good thing. You can always make your builds do what you want. And as in all things if your code gets too complicated you need to refactor, extract logic into methods/classes, etc.

You can always make your builds do what you want, but the flipside is you can never understand what someone else is doing with their build. I don't think the build system is the place for turing-complete code. Business logic certainly doesn't belong there. Keep the build simple and standardized, and keep code in code.

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

#23

Post by _xenonx_ »

merb wrote: post #5

actually I'm still unsure about kotlin. some things are really great some things are not. I mean i will still use kotlin, especially for libraries since it is great for that. however somehow I still missed something on top of Executors and CompletionStage. And I'm totally unhappy about "So, why doesn’t Kotlin have its own package manager, or its own build system? Because there’s already Maven and Gradle, and re-using…

> however people who worked with maven, gradle, ant or even sbt (which isn't offically supported) could be unhappy.

Well yes they could be - but this isnt a project to build a general purpose build tool so this is not really relevant

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

#24

Post by rabenblut »

Alphasite_ wrote: post #9
claudiug wrote: post #4

kotlin looks like swift for java. I hope google will remove java and start adding kotlin as a first citizen :)

The trouble between google and oracle wasn't about Java, it was about the Java Standard Library and Harmony. Which wouldn't really be solved by Kotlin.

Irrelevant, Kotlin is still better than Java

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

#25

Post by mike_hearn »

norswap wrote: post #19

I've been using Kotlin for work (I'm a PhD student, so work is to be understood in a peculiar fashion) and I'm really liking it. It's a much needed upgrade to Java whose fundamental advantage is what I'd call "crispness": you can write terse code that is actually understandable. In particular, the notion of inlining closures allows for efficient functional programming and great DSLs. In comparison to Scala, Kotlin is…

By typeclasses, do you mean structural typing a.k.a. duck typing a.k.a. Go-style interfaces?

I don't personally understand why people care about that: a simple structural match on names/parameter types doesn't seem like a strong enough signal that someone actually intended to implement such an interface.

But ... type classes can be implemented on the JVM relatively efficiently these days. I threw together a simple Kotlin version a few weeks ago that let you write something like:

   val foo = Foo()
   val bar = foo.dynamicCast()
where Bar was an interface that Foo could have implemented but didn't. It worked, but I didn't see any value in it for myself, and it didn't use the latest JVM reflection APIs so it was slower than a normal interface call.

If there's some big population of people who really want this in Kotlin and would be much happier if they had it, then I might sit down and reimplement it on top of Remi Forax's proxy2 framework, which should give 1:1 native performance.

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

#26

Post by lmm »

mike_hearn wrote: post #25
norswap wrote: post #19

I've been using Kotlin for work (I'm a PhD student, so work is to be understood in a peculiar fashion) and I'm really liking it. It's a much needed upgrade to Java whose fundamental advantage is what I'd call "crispness": you can write terse code that is actually understandable. In particular, the notion of inlining closures allows for efficient functional programming and great DSLs. In comparison to Scala, Kotlin is…

By typeclasses, do you mean structural typing a.k.a. duck typing a.k.a. Go-style interfaces? I don't personally understand why people care about that: a simple structural match on names/parameter types doesn't seem like a strong enough signal that someone actually intended to implement such an interface. But ... type classes can be implemented on the JVM relatively efficiently these days. I threw together a simple Ko…

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 there already (i.e. you can have an automatically resolved adapter). You might be able to hack an implementation by combining extension methods with structural types (though given the internals of how extension methods are usually implemented on the JVM I doubt it). They also allow a way to do "static virtual methods" i.e. polymorphic methods that you don't need an instance to invoke, which are used for things like Monoid#zero. Finally they provide a nicer way to express F-bounded polymorphism (i.e. the constraint on Enum or Comparable that we try to express in Java as Enum> or Comparable>, which is clunky and doesn't actually fully constrain implementations the way it's intended to).

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

#27

Post by [deleted] »

merb wrote: post #5

actually I'm still unsure about kotlin. some things are really great some things are not. I mean i will still use kotlin, especially for libraries since it is great for that. however somehow I still missed something on top of Executors and CompletionStage. And I'm totally unhappy about "So, why doesn’t Kotlin have its own package manager, or its own build system? Because there’s already Maven and Gradle, and re-using…

[deleted]

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

#28

Post by pdpi »

mike_hearn wrote: post #25
norswap wrote: post #19

I've been using Kotlin for work (I'm a PhD student, so work is to be understood in a peculiar fashion) and I'm really liking it. It's a much needed upgrade to Java whose fundamental advantage is what I'd call "crispness": you can write terse code that is actually understandable. In particular, the notion of inlining closures allows for efficient functional programming and great DSLs. In comparison to Scala, Kotlin is…

By typeclasses, do you mean structural typing a.k.a. duck typing a.k.a. Go-style interfaces? I don't personally understand why people care about that: a simple structural match on names/parameter types doesn't seem like a strong enough signal that someone actually intended to implement such an interface. But ... type classes can be implemented on the JVM relatively efficiently these days. I threw together a simple Ko…

It's nothing like duck typing -- type classes are a major thing in Haskell, which should tell you how far from duck typing it is ;) They're also present in Scala (as the OP mentioned), in Rust as Traits, and C++11 had a proposal for Concepts, which are quite similar as well.

The short but slightly inaccurate description is that type classes are a way to allow interfaces to be implemented separately from the way you define types.

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

#29

Post by mike_hearn »

lmm wrote: post #26
mike_hearn wrote: post #25

Earlier quoted context omitted.

By typeclasses, do you mean structural typing a.k.a. duck typing a.k.a. Go-style interfaces? I don't personally understand why people care about that: a simple structural match on names/parameter types doesn't seem like a strong enough signal that someone actually intended to implement such an interface. But ... type classes can be implemented on the JVM relatively efficiently these days. I threw together a simple Ko…

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…

But both Java and Kotlin interfaces can provide default implementations. So when I say "make a class implement an interface even if it doesn't declare it as so", that included interface default methods coming along for the ride.

The best explanation of Scala type classes IMO is here:

  http://danielwestheide.com/blog/2013/02/06/the-neophytes-guide-to-scala-part-12-type-classes.html
But as you say, what Scala calls type classes are more of a pattern with some language support - you just define what is essentially an adapter, but one which is constructed/used implicitly.

Being able to write:

  interface Foo {
      val prop: String
      fun someMethod() = "we are set to $prop"
  }
and then being able to treat any Bar as Foo as long as it has some property "prop" but without regard for whether it has someMethod, sounds pretty much the same thing as Haskell/Scala's idea of type classes to me.

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

#30

Post by lmm »

mike_hearn wrote: post #29
lmm wrote: 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…

But both Java and Kotlin interfaces can provide default implementations. So when I say "make a class implement an interface even if it doesn't declare it as so", that included interface default methods coming along for the ride. The best explanation of Scala type classes IMO is here: http://danielwestheide.com/blog/2013/02/06/the-neophytes-guide-to-scala-part-12-type-classes.html But as you say, what Scala calls type…

It's not just a default, you can provide an adapter specific to the type:

    implicit object IntMonoid extends Monoid[Int] {
      def zero = 0
      def plus(a: Int, b: Int) = a + b
    }
    implicit def endoMonoid[A] = new Monoid[A => A] {
      def zero = identity
      def plus(a: A => A, b: A => A) = a andThen b
    }
You can't do that with a default method.
Post reply on HN