5 ms·

Despite being a new language, what little I have seen of it looks pretty old school, i.e functional features seemed like an afterthought and also perhaps featur

Despite being a new language, what little I have seen of it looks pretty old school, i.e functional features seemed like an afterthought and also perhaps features like pattern destructuring and immutable data structures.

lmm 9y ago
In principle it's not that bad a language; compared to Swift or Typescript or even Rust it's at a similar level of conservatively adopting a few features that have become very mainstream. Every language design has to adopt a balance between making use of improvements that are coming down the pipeline and not adopting ideas that will later turn out to be bad. In a language built for the same platform where Scala has already been available for a decade it's very disappointing though.
- cookiecaper 9y ago
  I've had nothing but trouble trying to get Scala bootstrapped (sbt is a wreck), and while it's ostensibly interoperable with Java, there are many caveats. Kotlin's biggest strength is that it brings near-perfect Java interoperability. Almost any code that runs on a JVM released in the last 10 years will interoperate with Kotlin with minimal hassle. Boutique languages on the JVM are old hat by now, and they're neato and everything, but most people do not have the luxury of getting to choose to base their company on one of them. Kotlin is so compatible with Java that you can mix Java and Kotlin code freely in the same project, allowing people to move to adopt Kotlin gradually, without throwing away their extant business logic or requiring the wholesale sign-off of everyone in the org all at once. Kotlin may not be the most theoretically pure language, but it lets you hit the ground running while shedding many of the crusty, obnoxious parts of the Java language. We've badly needed a semi-modern JVM language for the working man, something that doesn't get in the way and makes the business of doing software simpler. That's why Kotlin has had such an ecstatic reception.
  - lmm 9y ago
    > I've had nothing but trouble trying to get Scala bootstrapped (sbt is a wreck), and while it's ostensibly interoperable with Java, there are many caveats. SBT is indeed a wreck, just ignore it (at least to start with) and keep using whatever you were using (Maven or Gradle or what-have-you). In maven and eclipse/scala-ide with the m2eclipse-scala plugin installed I always found it "just worked": add the scala plugin to the pom, let eclipse notice that it's Scala, create a Scala class in the project and keep going. The IntelliJ experience is only very slightly more involved (have to manually tell IntelliJ to update the project config with Scala nature). > while it's ostensibly interoperable with Java, there are many caveats. > Kotlin's biggest strength is that it brings a reasonable amount of modernity with near-perfect Java interoperability. Almost any code that runs on a JVM released in the last 10 years will interoperate with Kotlin with minimal hassle. This is the Kotlin narrative but I don't think it's actually supported by the facts. In the early days Scala looked perfectly interoperable with Java, but as we started writing more substantial things in Scala and a native-to-Scala library ecosystem developed it became clear that there was more to interop than being able to call methods directly, as nice as the latter is. As Scala became a full-fledged language with its own idioms we started needing idiomatic wrappers or native-to-Scala libraries. This is happening in Kotlin too, e.g. look at how http://arturdryomov.online/posts/kotlin-the-problem-with-null/ http://arturdryomov.online/posts/kotlin-the-problem-with-nul... talks about having to consider whether calls are into Java libraries or not and treat them differently if they are. And if anything I'd say this is getting worse for Kotlin with "modern" Java code: Java 8 is seeing more use of Optionals (particularly in streams) which correspond directly to Scala but are more difficult to interoperate with in Kotlin with its null-oriented design.
    - royjacobs 9y ago
      Why do you see options vs nulls as the same kind of interoperability issue as, say, Scala's completely incompatible collections library? That seems a little disingenuous.
      - lmm 9y ago
        Taken in isolation they're exactly the same kind of interoperability issue; the difference is that Scala has the language facilities (typeclasses and implicit conversions) to solve that kind of interoperability problem and Kotlin does not. In Scala it's straightforward to write methods that work with both Java and Scala collections (either at a syntactic level by using implicit conversions or in a "true" way by using typeclasses); in Kotlin it's simply impossible to write a method that will work with both options and nullables.
- eropple 9y ago
  > In a language built for the same platform where Scala has already been available for a decade it's very disappointing though. Given that after literally years of Scala experience I could easily write code I couldn't read three months later, this is not a big negative. Kotlin takes a lot of the good from Scala, leaves most of the bad, and gets the hell out of my way (while giving me literally-perfect Java interop--the only problem I ever had was how to annotate only the getter part of a property, and it was unintuitive but I figured it out). I'm a big fan.
  - lmm 9y ago
    To me it feels like they took the sugar from Scala but not the meat. All the simple examples of monads like Future work but with their own ad-hoc solutions (e.g. async/await) so there's no way to implement the reusable library functions that give them their real power. Direct pattern matching is there but the generic tree traversals that give you the real power of ADTs are impossible. All the one-page examples of "Scala power" are there but if you look closely they all fall apart once you try to expand them into the things you do in a full-size codebase.
    - eropple 9y ago
      Sure--but every time I do those things in a full-size codebase, I regret it later. ;) Scala is cool. I like a lot of the people involved (especially since Tony Morris was shown the door). But trying to get something out the door that doesn't turn into a mess of code I have to sit down and chew through, slo-oo-owly, is a heck of a fight. And it's worse when other people's preferred bits-and-bobs of Scala start sneaking in (kind of like C++, in a way!). The complexity I end up carrying in my head is way, way too high.
      - lmm 9y ago
        > Sure--but every time I do those things in a full-size codebase, I regret it later. Hmm, that's backwards from my experience. Like, I actually regret it when I use the Future-specific operations on Futures, because I don't use those often enough to remember what they are, whereas I use the generic Monad operations all the time on pretty much everything. > trying to get something out the door that doesn't turn into a mess of code I have to sit down and chew through, slo-oo-owly, is a heck of a fight I find often something that would be 10 lines of Java or Kotlin can be 1 line of Scala - but still 8 lines' worth of reading time. It can be difficult to remember that this is an improvement when you're thinking "why is it taking me all morning to read 10 lines?", but when you take a step back you realise that those 10 lines are actually doing the work of many more.
oblio 9y ago
https://kotlinlang.org/docs/reference/lambdas.html https://kotlinlang.org/docs/reference/lambdas.html https://kotlinlang.org/docs/reference/multi-declarations.html https://kotlinlang.org/docs/reference/multi-declarations.htm... https://kotlinlang.org/docs/reference/collections.html https://kotlinlang.org/docs/reference/collections.html ?
- Scarbutt 9y ago
  I don't know kotlin but if you read your collections link well, it does look like immutability was an afterthought, for starters, you can't create immutable persistent versions.
  - oblio 9y ago
    It's not an afterthought, it's just that Kotlin is meant to interoperate with Java. Which is mutable. However, if you look just at Kotlin's syntax, the default is meant to be immutable while the mutable version is longer: listOf versus mutableListOf. That looks very much like design and not like an afterthought.
    - lmm 9y ago
      There are no built-in immutable collection types; what Kotlin calls "immutable" is closer to C "const" i.e. it could be a view onto a list that's mutated elsewhere. This means you can't safely write a method that requires an immutable list; if you want to e.g. check the size of the list and then iterate over it, while maintaining the invariant that the number you got is the same as the number of iterations you're going to do, then you have to make a defensive copy, because there's no argument type you can ask for that means "actually immutable".
      - relics443 9y ago
        `List<T>` is technically immutable. You can make it mutable by casting to `MutableList<T>`, but that's something you have to explicitly do.
k__ 9y ago
Yes, I was hoping Ceylon would make it, but whelp :)
peheje 9y ago
Could you elaborate on exactly what you dislike about these features? Or why they seem like an afterthought?
- billfruit 9y ago
  I am not disliking these features, only was commenting that in my limited knowledge of Kotlin, functional features like these ( which I have come to like from using them in clojure) did not appear like the core design elements of the language. Like another commenter said below, in this regard Kotlin seems rather conservative in design.
  - cageface 9y ago
    Kotlin is a conservative design, but very pleasant to use with best-in-class tooling. I'd love to have a reason to use it on a real project. They hit the sweet spot on a lot of metrics with this design IMO.
geodel 9y ago
> Despite being a new language, It is a new language on JVM. It also suppose to work with Java libraries. So it won't radically different from Java.
pdpi 9y ago
It's important to note that Kotlin defines itself as a blue-collar language, and if the feel you get from it is "this is as if Java had been designed today", then they accomplished their goal. There's exactly one unusual/novel feature in the language (AIUI), and it's a feature that I personally find inspired: anonymous receiver functions, as it makes EDSLs trivial to write.
- roflc0ptic 9y ago
  Are you familiar with Scala's implicits? Reading about them here (https://kotlinlang.org/docs/reference/lambdas.html https://kotlinlang.org/docs/reference/lambdas.html), they seem very similar. If you happen to know, what affordances do anonymous receiver functions provide that implicits don't? It looks like they make it marginally easier to add functions to some existing type, but at the cost of making the typeclass pattern less palatable.
- lmm 9y ago
  Delegation as implemented in Kotlin is very novel; AFAIK it's the first remotely mainstream language with that feature (not counting Go since it doesn't have traditional inheritance at all). (I think it's a very good idea, but it's as innovative as anything you'll see in e.g. Scala, so it makes a mockery of the "blue collar" narrative) Non-representable types are also decidedly "novel" (in the sense of "wtf?"), as are some of the details of their preferred way of doing await/async (assuming they haven't radically changed again in a minor version as they did in the past). The only sense in which Kotlin is blue-collar is that it prioritizes immediate use cases over consistency and theoretical coherence. That's not "Java as if it had been designed today", that's "Perl as if it had been designed today".
  - pdpi 9y ago
    Several features have a clear "this is annoying in Java" background: Type inference is table stakes for a modern language, data classes make beans painless, receiver methods are explicitly designed to ease the pain of FooUtils classes, inline+reified open up generics to a tonne more use cases, and variance annotations helps with several others.

lmm 9y ago

In principle it's not that bad a language; compared to Swift or Typescript or even Rust it's at a similar level of conservatively adopting a few features that have become very mainstream. Every language design has to adopt a balance between making use of improvements that are coming down the pipeline and not adopting ideas that will later turn out to be bad. In a language built for the same platform where Scala has already been available for a decade it's very disappointing though.

cookiecaper 9y ago
I've had nothing but trouble trying to get Scala bootstrapped (sbt is a wreck), and while it's ostensibly interoperable with Java, there are many caveats. Kotlin's biggest strength is that it brings near-perfect Java interoperability. Almost any code that runs on a JVM released in the last 10 years will interoperate with Kotlin with minimal hassle. Boutique languages on the JVM are old hat by now, and they're neato and everything, but most people do not have the luxury of getting to choose to base their company on one of them. Kotlin is so compatible with Java that you can mix Java and Kotlin code freely in the same project, allowing people to move to adopt Kotlin gradually, without throwing away their extant business logic or requiring the wholesale sign-off of everyone in the org all at once. Kotlin may not be the most theoretically pure language, but it lets you hit the ground running while shedding many of the crusty, obnoxious parts of the Java language. We've badly needed a semi-modern JVM language for the working man, something that doesn't get in the way and makes the business of doing software simpler. That's why Kotlin has had such an ecstatic reception.
- lmm 9y ago
  > I've had nothing but trouble trying to get Scala bootstrapped (sbt is a wreck), and while it's ostensibly interoperable with Java, there are many caveats. SBT is indeed a wreck, just ignore it (at least to start with) and keep using whatever you were using (Maven or Gradle or what-have-you). In maven and eclipse/scala-ide with the m2eclipse-scala plugin installed I always found it "just worked": add the scala plugin to the pom, let eclipse notice that it's Scala, create a Scala class in the project and keep going. The IntelliJ experience is only very slightly more involved (have to manually tell IntelliJ to update the project config with Scala nature). > while it's ostensibly interoperable with Java, there are many caveats. > Kotlin's biggest strength is that it brings a reasonable amount of modernity with near-perfect Java interoperability. Almost any code that runs on a JVM released in the last 10 years will interoperate with Kotlin with minimal hassle. This is the Kotlin narrative but I don't think it's actually supported by the facts. In the early days Scala looked perfectly interoperable with Java, but as we started writing more substantial things in Scala and a native-to-Scala library ecosystem developed it became clear that there was more to interop than being able to call methods directly, as nice as the latter is. As Scala became a full-fledged language with its own idioms we started needing idiomatic wrappers or native-to-Scala libraries. This is happening in Kotlin too, e.g. look at how http://arturdryomov.online/posts/kotlin-the-problem-with-null/ http://arturdryomov.online/posts/kotlin-the-problem-with-nul... talks about having to consider whether calls are into Java libraries or not and treat them differently if they are. And if anything I'd say this is getting worse for Kotlin with "modern" Java code: Java 8 is seeing more use of Optionals (particularly in streams) which correspond directly to Scala but are more difficult to interoperate with in Kotlin with its null-oriented design.
  - royjacobs 9y ago
    Why do you see options vs nulls as the same kind of interoperability issue as, say, Scala's completely incompatible collections library? That seems a little disingenuous.
    - lmm 9y ago
      Taken in isolation they're exactly the same kind of interoperability issue; the difference is that Scala has the language facilities (typeclasses and implicit conversions) to solve that kind of interoperability problem and Kotlin does not. In Scala it's straightforward to write methods that work with both Java and Scala collections (either at a syntactic level by using implicit conversions or in a "true" way by using typeclasses); in Kotlin it's simply impossible to write a method that will work with both options and nullables.
eropple 9y ago
> In a language built for the same platform where Scala has already been available for a decade it's very disappointing though. Given that after literally years of Scala experience I could easily write code I couldn't read three months later, this is not a big negative. Kotlin takes a lot of the good from Scala, leaves most of the bad, and gets the hell out of my way (while giving me literally-perfect Java interop--the only problem I ever had was how to annotate only the getter part of a property, and it was unintuitive but I figured it out). I'm a big fan.
- lmm 9y ago
  To me it feels like they took the sugar from Scala but not the meat. All the simple examples of monads like Future work but with their own ad-hoc solutions (e.g. async/await) so there's no way to implement the reusable library functions that give them their real power. Direct pattern matching is there but the generic tree traversals that give you the real power of ADTs are impossible. All the one-page examples of "Scala power" are there but if you look closely they all fall apart once you try to expand them into the things you do in a full-size codebase.
  - eropple 9y ago
    Sure--but every time I do those things in a full-size codebase, I regret it later. ;) Scala is cool. I like a lot of the people involved (especially since Tony Morris was shown the door). But trying to get something out the door that doesn't turn into a mess of code I have to sit down and chew through, slo-oo-owly, is a heck of a fight. And it's worse when other people's preferred bits-and-bobs of Scala start sneaking in (kind of like C++, in a way!). The complexity I end up carrying in my head is way, way too high.
    - lmm 9y ago
      > Sure--but every time I do those things in a full-size codebase, I regret it later. Hmm, that's backwards from my experience. Like, I actually regret it when I use the Future-specific operations on Futures, because I don't use those often enough to remember what they are, whereas I use the generic Monad operations all the time on pretty much everything. > trying to get something out the door that doesn't turn into a mess of code I have to sit down and chew through, slo-oo-owly, is a heck of a fight I find often something that would be 10 lines of Java or Kotlin can be 1 line of Scala - but still 8 lines' worth of reading time. It can be difficult to remember that this is an improvement when you're thinking "why is it taking me all morning to read 10 lines?", but when you take a step back you realise that those 10 lines are actually doing the work of many more.

oblio 9y ago

https://kotlinlang.org/docs/reference/lambdas.html https://kotlinlang.org/docs/reference/lambdas.html https://kotlinlang.org/docs/reference/multi-declarations.html https://kotlinlang.org/docs/reference/multi-declarations.htm... https://kotlinlang.org/docs/reference/collections.html https://kotlinlang.org/docs/reference/collections.html ?

Scarbutt 9y ago
I don't know kotlin but if you read your collections link well, it does look like immutability was an afterthought, for starters, you can't create immutable persistent versions.
- oblio 9y ago
  It's not an afterthought, it's just that Kotlin is meant to interoperate with Java. Which is mutable. However, if you look just at Kotlin's syntax, the default is meant to be immutable while the mutable version is longer: listOf versus mutableListOf. That looks very much like design and not like an afterthought.
  - lmm 9y ago
    There are no built-in immutable collection types; what Kotlin calls "immutable" is closer to C "const" i.e. it could be a view onto a list that's mutated elsewhere. This means you can't safely write a method that requires an immutable list; if you want to e.g. check the size of the list and then iterate over it, while maintaining the invariant that the number you got is the same as the number of iterations you're going to do, then you have to make a defensive copy, because there's no argument type you can ask for that means "actually immutable".
    - relics443 9y ago
      `List<T>` is technically immutable. You can make it mutable by casting to `MutableList<T>`, but that's something you have to explicitly do.

k__ 9y ago

Yes, I was hoping Ceylon would make it, but whelp :)

peheje 9y ago

Could you elaborate on exactly what you dislike about these features? Or why they seem like an afterthought?

billfruit 9y ago
I am not disliking these features, only was commenting that in my limited knowledge of Kotlin, functional features like these ( which I have come to like from using them in clojure) did not appear like the core design elements of the language. Like another commenter said below, in this regard Kotlin seems rather conservative in design.
- cageface 9y ago
  Kotlin is a conservative design, but very pleasant to use with best-in-class tooling. I'd love to have a reason to use it on a real project. They hit the sweet spot on a lot of metrics with this design IMO.

geodel 9y ago

> Despite being a new language, It is a new language on JVM. It also suppose to work with Java libraries. So it won't radically different from Java.

pdpi 9y ago

It's important to note that Kotlin defines itself as a blue-collar language, and if the feel you get from it is "this is as if Java had been designed today", then they accomplished their goal. There's exactly one unusual/novel feature in the language (AIUI), and it's a feature that I personally find inspired: anonymous receiver functions, as it makes EDSLs trivial to write.

roflc0ptic 9y ago
Are you familiar with Scala's implicits? Reading about them here (https://kotlinlang.org/docs/reference/lambdas.html https://kotlinlang.org/docs/reference/lambdas.html), they seem very similar. If you happen to know, what affordances do anonymous receiver functions provide that implicits don't? It looks like they make it marginally easier to add functions to some existing type, but at the cost of making the typeclass pattern less palatable.
lmm 9y ago
Delegation as implemented in Kotlin is very novel; AFAIK it's the first remotely mainstream language with that feature (not counting Go since it doesn't have traditional inheritance at all). (I think it's a very good idea, but it's as innovative as anything you'll see in e.g. Scala, so it makes a mockery of the "blue collar" narrative) Non-representable types are also decidedly "novel" (in the sense of "wtf?"), as are some of the details of their preferred way of doing await/async (assuming they haven't radically changed again in a minor version as they did in the past). The only sense in which Kotlin is blue-collar is that it prioritizes immediate use cases over consistency and theoretical coherence. That's not "Java as if it had been designed today", that's "Perl as if it had been designed today".
- pdpi 9y ago
  Several features have a clear "this is annoying in Java" background: Type inference is table stakes for a modern language, data classes make beans painless, receiver methods are explicitly designed to ease the pain of FooUtils classes, inline+reified open up generics to a tonne more use cases, and variance annotations helps with several others.