6 ms·

I'm not going to try to explain why developing and maintaining tooling takes resources. However, a few things: - Lightbend isn't involved in Scala 3. - Marti

I'm not going to try to explain why developing and maintaining tooling takes resources. However, a few things: - Lightbend isn't involved in Scala 3. - Martin Odersky has taught students for decades and knows how to make Scala more accessible. He wasn't afraid of stirring controversy with new keywords and the brace-free syntax. He also has enough industry experience and connections to realize what matters for the ecosystem in the long run. Server middleware and big data frameworks are the perfect fit for Scala on the JVM. There's no evidence for some kind of missed opportunity between Android and Scala. - Scala's standard library is rich, heavy, focused on immutability, and not always interoperable with Java's. Kotlin's standard library is very small and heavily inlined in comparison. On a mobile platform, this matters.

klibertp 4y ago
> why developing and maintaining tooling takes resources. Developing and maintaining anything takes resources, tooling is not special at all. Yet, you still didn't say what exactly does Kotlin do that's so resource-intensive that it's impossible to replicate for Scala for the reason of lack of resources only. Do you know Kotlin's tooling? > Lightbend isn't involved in Scala 3. I don't get what you mean? I mean, so what? I just opened scala-lang.org - which seems to be an official Scala web page - and the information that Scala 3.2.0 was just released is at the very top of the page. It's not like PERL and Raku. And what does it matter who is involved in what if we're talking about the tooling for the language as a whole? > Martin Odersky has taught students for decades and knows how to make Scala more accessible. Apparently not via investing in tooling, though? If you ask Matthias Felleisen[1], who happens to also have been teaching students for 40 years at this point, he'd tell you that tooling is important for accessibility[2]. > He wasn't afraid of stirring controversy with new keywords and the brace-free syntax. I don't know who would, actually. I'm sorry, I don't understand this sentence, could you please explain what you mean by this? > There's no evidence for some kind of missed opportunity between Android and Scala. I'm sorry, but that's just you being in denial. I don't intend to dispute Martin Odersky's credentials, that's completely beside the point. The point is this: in June 2019 Scala was 28th and Kotlin was 43rd on the TIOBE Index. Now, Scala is still ahead: 33rd place vs. 34th for Kotlin. And you have to account for the fact that Kotlin is almost 7 years younger. Sorry to break it you, but that's not how a healthy language's growth looks like. Clearly, there's something wrong somewhere. My interpretation is that Scala missed many chances, and disastrously so - one of them being Android development. It's a bummer, really. I read Odersky's book in 2005, I still have the PDF. I really liked the concept of a scalable language, expressive at all levels of complexity. I learned Scala in 2009, then brushed it off in 2017. I see Kotlin for what it is: a pragmatic knock-off of Scala and Groovy. Groovy did not, but Scala had a chance to win over millions of Android developers (in addition to thousands in data centers), but blew it. I'm not happy with that. (The other great language that could have done better but largely blew it is of course Clojure (currently 47th), but then again, they had it way harder given the language's features) > Scala's standard library is > rich, I don't have a quick way of checking, could you maybe check how many classes/(other relevant entities) are there in Java and Scala respective standard libraries? I strongly suspect Java's bigger. And even that is nothing in front of Python or VW Smalltalk. > heavy, Why is it heavy and in what way? Too much code generated? Too big a JAR to include? > focused on immutability, All default (ie. used most often in idiomatic code) collections in Kotlin are immutable; the practice of favoring val over var is identical in both languages. > not always interoperable with Java's. What do you mean? These are all classes compiled to the same bytecode, how could they ever not be interoperable? Do you mean that you need to convert (for example) collections before you can call methods provided by Scala/Java-specific class? That's perfectly normal and counts as interoperability, and quite a high-class one at that (I mean, try to convert BEAM's list into Python's via C extension and you'll see what "not always interoperable" means...) > Kotlin's standard library is very small Again, can't check it easily, but yes, I get the impression that Kotlin's stdlib is a bit smaller than Scala's. Not by much though. They're both just tiny. Well, not JS-level tiny. Probably somewhere around Scheme's R7RS or OCaml. > and heavily inlined in comparison. Again, Scala compiler is supposed to be "intelligent enough" to produce code faster than hand-written Java in some cases! How come such a compiler has problems inlining the code of stdlib, arguably the most optimized code of all in any language? What weird things are happening in that stdlib that the compiler has such a hard time inlining them? > On a mobile platform, this matters. Sure. But you just said it doesn't matter for Scala, because it's happy powering server middlewares and big data frameworks, even if it means loosing out on a lot of mindshare, contributors and all that. [1] https://en.wikipedia.org/wiki/Matthias_Felleisen https://en.wikipedia.org/wiki/Matthias_Felleisen [2] https://racket-lang.org/ https://racket-lang.org/ and https://docs.racket-lang.org/drracket/interface-essentials.html https://docs.racket-lang.org/drracket/interface-essentials.h...
- Tainnor 4y ago
  > All default (ie. used most often in idiomatic code) collections in Kotlin are immutable That's not true. List, for example, is a read-only interface, but given that MutableList is a subtype of List, you have no actual guarantee that some other piece of code isn't modifying a list you think is immutable. I haven't seen this leading to trouble so far because clearly the intent is to treat collections as immutable wherever possible, and because it's a tradeoff that makes Java interop easier, but it's not the same thing as true immutable collections in Scala. Also, your comment about interoperability makes me think you haven't actually used Kotlin. Its Java interoperability is way better than Scala's (you don't have to cast collection types, for example), for better or worse (because it also inherits some of Java's flaws). I think that Kotlin is more pragmatic and Scala is more elegant and idealistic, and both are valid goals.
  - klibertp 4y ago
    I think it's more of me not remembering how it was with Scala - it's been some 5 years since I did any Scala development. > I think that Kotlin is more pragmatic and Scala is more elegant and idealistic, and both are valid goals. Yes, I have the same impression. However, I don't believe this was an initial goal of Scala. I remember reading the Scala book by Odersky in 2005 (or around that time) and my impression was that Scala was meant to be pragmatic as well. The OO+FP mix was innovative at the time (it's not anymore), but neither side was made to be dominant. That changed, with - and I'm guessing again - Haskell expats who abused implicits and the type system almost to the point of breaking to pursue their brand of "generic programming". I don't know what happened exactly and why, but when I learned Scala in 2009 it was because I didn't want to touch Java but I had to work on the JVM with lots of Java libraries. And Scala back then was ok for that purpose, like Kotlin is today. When I revisited it in 2017, it was still kind of ok for that and for me, but the community and ecosystem seemed to have drifted away from the "better Java" use case significantly. On the other hand, Scala 2 is now anything but elegant. Scala 3 made Scala elegant again. You can see how many changes were needed to recover from more than a decade of giving in to people interested in a particular style of programming by simply skimming the Scala 3 tour. My background is kind of unusual: most programmers my age have worked with 5-6 languages professionally and a few more as a hobby. I used 9 languages professionally and more than 20 as a hobby. Scala was one of the most interesting languages I learned. It was C++ done right and without the design-by-comitee stigma. It was meant to be expressive at all levels of complexity, from oneliners to massive systems: Scala, a scalable language. My impression is that the initial goal was to use FP idioms to make the language expressive "in the small", and OOP to make it expressive "in the large". Then some part of the community started wielding FP hammer and striking every problem with it, without even trying to use the other part of the toolbox. I might be wrong in all of the above, I'm just guessing based on hazy memories of long ago. Still, that's my impression as someone who is interested in programming langauges in general and who was around since the beginning, although only reading up with Scala development occasionally. Another language that suffers similar fate is OCaml. Actually, object oriented part of OCaml is a beautiful and elegant, prototype-based and (statically) structurally-typed object system. Yet no one seems to be using it. However, OCaml is better at FP than Scala. The H-M type system and inference along with polymorphic variants cover a lot more than Scala's FP can (without abusing the language features; and also of course H-M comes with downside, ie. + and +. thing). OCaml also provides real modules and higher-order modules (dubbed functors) which Scala doesn't have, and which also improve FP style to cover more of the programming "in the large" more easily. Again, I might be totally wrong, but I think Scala was never meant to be "Haskell on the JVM". Scala 3 highlight the pragmatic, elegant side of Scala, which I think makes my assumption plausible. (I also like Haskell, Lisps, Erlang, Prolog, and another 20 languages, so I personally could live with that direction of Scala's development. Other than the compile times. But there's no way to argue that it resulted in higher adoption rate, larger community, more packages in the ecosystem, and so on. So while I'm personally still ok with Scala, my employer is not. And comments like that of your sibling poster don't help, to put it mildly - it's Smug Lisp Weenies again, just with ( replaced with { ...) (BTW, if I'm wrong, please tell me. I'm capable of changing my mind, really.)

klibertp 4y ago

> why developing and maintaining tooling takes resources. Developing and maintaining anything takes resources, tooling is not special at all. Yet, you still didn't say what exactly does Kotlin do that's so resource-intensive that it's impossible to replicate for Scala for the reason of lack of resources only. Do you know Kotlin's tooling? > Lightbend isn't involved in Scala 3. I don't get what you mean? I mean, so what? I just opened scala-lang.org - which seems to be an official Scala web page - and the information that Scala 3.2.0 was just released is at the very top of the page. It's not like PERL and Raku. And what does it matter who is involved in what if we're talking about the tooling for the language as a whole? > Martin Odersky has taught students for decades and knows how to make Scala more accessible. Apparently not via investing in tooling, though? If you ask Matthias Felleisen[1], who happens to also have been teaching students for 40 years at this point, he'd tell you that tooling is important for accessibility[2]. > He wasn't afraid of stirring controversy with new keywords and the brace-free syntax. I don't know who would, actually. I'm sorry, I don't understand this sentence, could you please explain what you mean by this? > There's no evidence for some kind of missed opportunity between Android and Scala. I'm sorry, but that's just you being in denial. I don't intend to dispute Martin Odersky's credentials, that's completely beside the point. The point is this: in June 2019 Scala was 28th and Kotlin was 43rd on the TIOBE Index. Now, Scala is still ahead: 33rd place vs. 34th for Kotlin. And you have to account for the fact that Kotlin is almost 7 years younger. Sorry to break it you, but that's not how a healthy language's growth looks like. Clearly, there's something wrong somewhere. My interpretation is that Scala missed many chances, and disastrously so - one of them being Android development. It's a bummer, really. I read Odersky's book in 2005, I still have the PDF. I really liked the concept of a scalable language, expressive at all levels of complexity. I learned Scala in 2009, then brushed it off in 2017. I see Kotlin for what it is: a pragmatic knock-off of Scala and Groovy. Groovy did not, but Scala had a chance to win over millions of Android developers (in addition to thousands in data centers), but blew it. I'm not happy with that. (The other great language that could have done better but largely blew it is of course Clojure (currently 47th), but then again, they had it way harder given the language's features) > Scala's standard library is > rich, I don't have a quick way of checking, could you maybe check how many classes/(other relevant entities) are there in Java and Scala respective standard libraries? I strongly suspect Java's bigger. And even that is nothing in front of Python or VW Smalltalk. > heavy, Why is it heavy and in what way? Too much code generated? Too big a JAR to include? > focused on immutability, All default (ie. used most often in idiomatic code) collections in Kotlin are immutable; the practice of favoring val over var is identical in both languages. > not always interoperable with Java's. What do you mean? These are all classes compiled to the same bytecode, how could they ever not be interoperable? Do you mean that you need to convert (for example) collections before you can call methods provided by Scala/Java-specific class? That's perfectly normal and counts as interoperability, and quite a high-class one at that (I mean, try to convert BEAM's list into Python's via C extension and you'll see what "not always interoperable" means...) > Kotlin's standard library is very small Again, can't check it easily, but yes, I get the impression that Kotlin's stdlib is a bit smaller than Scala's. Not by much though. They're both just tiny. Well, not JS-level tiny. Probably somewhere around Scheme's R7RS or OCaml. > and heavily inlined in comparison. Again, Scala compiler is supposed to be "intelligent enough" to produce code faster than hand-written Java in some cases! How come such a compiler has problems inlining the code of stdlib, arguably the most optimized code of all in any language? What weird things are happening in that stdlib that the compiler has such a hard time inlining them? > On a mobile platform, this matters. Sure. But you just said it doesn't matter for Scala, because it's happy powering server middlewares and big data frameworks, even if it means loosing out on a lot of mindshare, contributors and all that. [1] https://en.wikipedia.org/wiki/Matthias_Felleisen https://en.wikipedia.org/wiki/Matthias_Felleisen [2] https://racket-lang.org/ https://racket-lang.org/ and https://docs.racket-lang.org/drracket/interface-essentials.html https://docs.racket-lang.org/drracket/interface-essentials.h...

Tainnor 4y ago
> All default (ie. used most often in idiomatic code) collections in Kotlin are immutable That's not true. List, for example, is a read-only interface, but given that MutableList is a subtype of List, you have no actual guarantee that some other piece of code isn't modifying a list you think is immutable. I haven't seen this leading to trouble so far because clearly the intent is to treat collections as immutable wherever possible, and because it's a tradeoff that makes Java interop easier, but it's not the same thing as true immutable collections in Scala. Also, your comment about interoperability makes me think you haven't actually used Kotlin. Its Java interoperability is way better than Scala's (you don't have to cast collection types, for example), for better or worse (because it also inherits some of Java's flaws). I think that Kotlin is more pragmatic and Scala is more elegant and idealistic, and both are valid goals.
- klibertp 4y ago
  I think it's more of me not remembering how it was with Scala - it's been some 5 years since I did any Scala development. > I think that Kotlin is more pragmatic and Scala is more elegant and idealistic, and both are valid goals. Yes, I have the same impression. However, I don't believe this was an initial goal of Scala. I remember reading the Scala book by Odersky in 2005 (or around that time) and my impression was that Scala was meant to be pragmatic as well. The OO+FP mix was innovative at the time (it's not anymore), but neither side was made to be dominant. That changed, with - and I'm guessing again - Haskell expats who abused implicits and the type system almost to the point of breaking to pursue their brand of "generic programming". I don't know what happened exactly and why, but when I learned Scala in 2009 it was because I didn't want to touch Java but I had to work on the JVM with lots of Java libraries. And Scala back then was ok for that purpose, like Kotlin is today. When I revisited it in 2017, it was still kind of ok for that and for me, but the community and ecosystem seemed to have drifted away from the "better Java" use case significantly. On the other hand, Scala 2 is now anything but elegant. Scala 3 made Scala elegant again. You can see how many changes were needed to recover from more than a decade of giving in to people interested in a particular style of programming by simply skimming the Scala 3 tour. My background is kind of unusual: most programmers my age have worked with 5-6 languages professionally and a few more as a hobby. I used 9 languages professionally and more than 20 as a hobby. Scala was one of the most interesting languages I learned. It was C++ done right and without the design-by-comitee stigma. It was meant to be expressive at all levels of complexity, from oneliners to massive systems: Scala, a scalable language. My impression is that the initial goal was to use FP idioms to make the language expressive "in the small", and OOP to make it expressive "in the large". Then some part of the community started wielding FP hammer and striking every problem with it, without even trying to use the other part of the toolbox. I might be wrong in all of the above, I'm just guessing based on hazy memories of long ago. Still, that's my impression as someone who is interested in programming langauges in general and who was around since the beginning, although only reading up with Scala development occasionally. Another language that suffers similar fate is OCaml. Actually, object oriented part of OCaml is a beautiful and elegant, prototype-based and (statically) structurally-typed object system. Yet no one seems to be using it. However, OCaml is better at FP than Scala. The H-M type system and inference along with polymorphic variants cover a lot more than Scala's FP can (without abusing the language features; and also of course H-M comes with downside, ie. + and +. thing). OCaml also provides real modules and higher-order modules (dubbed functors) which Scala doesn't have, and which also improve FP style to cover more of the programming "in the large" more easily. Again, I might be totally wrong, but I think Scala was never meant to be "Haskell on the JVM". Scala 3 highlight the pragmatic, elegant side of Scala, which I think makes my assumption plausible. (I also like Haskell, Lisps, Erlang, Prolog, and another 20 languages, so I personally could live with that direction of Scala's development. Other than the compile times. But there's no way to argue that it resulted in higher adoption rate, larger community, more packages in the ecosystem, and so on. So while I'm personally still ok with Scala, my employer is not. And comments like that of your sibling poster don't help, to put it mildly - it's Smug Lisp Weenies again, just with ( replaced with { ...) (BTW, if I'm wrong, please tell me. I'm capable of changing my mind, really.)