5 ms·

> then why would you adopt it when it's missing important features compared to Scala Such as?

kodablah 8y ago
There are a lot of things I miss. Case objects, macros, string contexts, (built-in) options as single-element collections, tuples, built-in either, abstract/self types, implicits, etc. We can argue about "importance" or even if those are good things, but we can't pretend that there aren't many missing features. Granted these days I appreciate Kotlin more than Scala, but that is more about tooling and backing.
- kllrnohj 8y ago
  > We can argue about "importance" or even if those are good things, but we can't pretend that there aren't many missing features. I don't think anyone would deny that Scala has the most features of anything, it's purely a question of importance. Important missing features is more interesting to discuss than purely missing features. I've found myself more missing features from C++ when working in kotlin - specifically constexpr & static_assert.
  - kodablah 8y ago
    Meh, importance of language features becomes just too subjective. I consider several of the things I mentioned as important, but not important enough for me to choose the language.
lmm 8y ago
At the concrete/immediate level, a nice way to do error handling when you want errors to include a detail message (i.e. a Result/Either-like) - most languages that offer Option-like types let you use a type like that the same way, but in Kotlin the nice ?. syntax only works for "null". Even Java checked exceptions are a better answer for that use case than anything in Kotlin. Proper immutable types for e.g. collections. If you're writing in a functional style as Kotlin encourages, you want to be able to write functions that accept lists that are required to be immutable, not just lists that the function isn't going to mutate itself. (Scala's collections get a lot wrong but a thing they get right is that e.g. scala.collection.List is a mutable-or-immutable interface that offers only read methods, and then scala.collection.mutable.List and scala.collection.immutable.List are subtypes for mutable and immutable. Kotlin offers the equivalent of scala.collection.List but not the equivalent of scala.collection.immutable.List) Better support for operations that need to happen in particular contexts - i.e. custom command-like objects. Kotlin has a bunch of syntaxes that could be reused for this - .?, async/await, and plain old collection iteration all need similar syntax, but there's no way to overload a syntax like that for your custom type. (Scala gets this right: for/yield works for options, for async, for plain old collections and more, but also works for user-defined types). And ultimately, higher-kinded types. (More concretely: the ability to write utility functions like "traverse" that will work the same for various different context-like types).
- kllrnohj 8y ago
  Re immutable: If you're doing functional why does this matter? "true" immutable vs. just an immutable view should only matter if the object is retained by the function it's passed to, but now we're talking object state rather than pure functions. Re "command-like" objects: I'm not following, can you give an example of something you can do in Scala here that you can't in Kotlin?
  - lmm 8y ago
    > Re immutable: If you're doing functional why does this matter? "true" immutable vs. just an immutable view should only matter if the object is retained by the function it's passed to, but now we're talking object state rather than pure functions. For the same reason that being able to write val rather than var matters. With perfect discipline you can write pure functional code in any language, but in practice (and in codebases that likely have some non-functional sections, particularly if you're interoperating with Java) being able to be 100% sure that a given value is really immutable rather than 99.9% sure makes a huge difference. > Re "command-like" objects: I'm not following, can you give an example of something you can do in Scala here that you can't in Kotlin? There are lots of different use cases for this stuff, but one I was working with today was database transactions. I have operations that should only happen inside a database transaction, and want to enforce that at the type level, but I want to be able to compose several of those functions in a single database transaction, so I don't want to just have each one run its own transaction. So what I do is have a custom type, something like MustHappenInTransaction[A], which is actually just an alias for an existing library type (Free), and I automatically get the ability to use the for/yield syntax to compose these, and can use existing library functions to operate on it almost as if it were a plain value, but still safely (e.g. traverse rather than map on a sequence). I have no way to "get the A out" except for my doTransaction() function (what's why I say it's a command-like object), so the function will definitely happen in a transaction, but I can still do normal function composition, extract out common subfunctions, and all that. You can't do that in Kotlin because there's no equivalent to "do notation" or "for comprehension" that you can use for user-defined types, and there are no higher-kinded types so you can't implement generic helper functions like traverse (there's no way to write the type signature it should have).

There are a lot of things I miss. Case objects, macros, string contexts, (built-in) options as single-element collections, tuples, built-in either, abstract/self types, implicits, etc. We can argue about "importance" or even if those are good things, but we can't pretend that there aren't many missing features. Granted these days I appreciate Kotlin more than Scala, but that is more about tooling and backing.

kllrnohj 8y ago
> We can argue about "importance" or even if those are good things, but we can't pretend that there aren't many missing features. I don't think anyone would deny that Scala has the most features of anything, it's purely a question of importance. Important missing features is more interesting to discuss than purely missing features. I've found myself more missing features from C++ when working in kotlin - specifically constexpr & static_assert.
- kodablah 8y ago
  Meh, importance of language features becomes just too subjective. I consider several of the things I mentioned as important, but not important enough for me to choose the language.

lmm 8y ago

At the concrete/immediate level, a nice way to do error handling when you want errors to include a detail message (i.e. a Result/Either-like) - most languages that offer Option-like types let you use a type like that the same way, but in Kotlin the nice ?. syntax only works for "null". Even Java checked exceptions are a better answer for that use case than anything in Kotlin. Proper immutable types for e.g. collections. If you're writing in a functional style as Kotlin encourages, you want to be able to write functions that accept lists that are required to be immutable, not just lists that the function isn't going to mutate itself. (Scala's collections get a lot wrong but a thing they get right is that e.g. scala.collection.List is a mutable-or-immutable interface that offers only read methods, and then scala.collection.mutable.List and scala.collection.immutable.List are subtypes for mutable and immutable. Kotlin offers the equivalent of scala.collection.List but not the equivalent of scala.collection.immutable.List) Better support for operations that need to happen in particular contexts - i.e. custom command-like objects. Kotlin has a bunch of syntaxes that could be reused for this - .?, async/await, and plain old collection iteration all need similar syntax, but there's no way to overload a syntax like that for your custom type. (Scala gets this right: for/yield works for options, for async, for plain old collections and more, but also works for user-defined types). And ultimately, higher-kinded types. (More concretely: the ability to write utility functions like "traverse" that will work the same for various different context-like types).

kllrnohj 8y ago
Re immutable: If you're doing functional why does this matter? "true" immutable vs. just an immutable view should only matter if the object is retained by the function it's passed to, but now we're talking object state rather than pure functions. Re "command-like" objects: I'm not following, can you give an example of something you can do in Scala here that you can't in Kotlin?
- lmm 8y ago
  > Re immutable: If you're doing functional why does this matter? "true" immutable vs. just an immutable view should only matter if the object is retained by the function it's passed to, but now we're talking object state rather than pure functions. For the same reason that being able to write val rather than var matters. With perfect discipline you can write pure functional code in any language, but in practice (and in codebases that likely have some non-functional sections, particularly if you're interoperating with Java) being able to be 100% sure that a given value is really immutable rather than 99.9% sure makes a huge difference. > Re "command-like" objects: I'm not following, can you give an example of something you can do in Scala here that you can't in Kotlin? There are lots of different use cases for this stuff, but one I was working with today was database transactions. I have operations that should only happen inside a database transaction, and want to enforce that at the type level, but I want to be able to compose several of those functions in a single database transaction, so I don't want to just have each one run its own transaction. So what I do is have a custom type, something like MustHappenInTransaction[A], which is actually just an alias for an existing library type (Free), and I automatically get the ability to use the for/yield syntax to compose these, and can use existing library functions to operate on it almost as if it were a plain value, but still safely (e.g. traverse rather than map on a sequence). I have no way to "get the A out" except for my doTransaction() function (what's why I say it's a command-like object), so the function will definitely happen in a transaction, but I can still do normal function composition, extract out common subfunctions, and all that. You can't do that in Kotlin because there's no equivalent to "do notation" or "for comprehension" that you can use for user-defined types, and there are no higher-kinded types so you can't implement generic helper functions like traverse (there's no way to write the type signature it should have).