5 ms·

Good points, as always. > None of those features (except sealed ADTs, which really aren't necessary) is missing from Kotlin. The set of Scala features Spark is

Good points, as always. > None of those features (except sealed ADTs, which really aren't necessary) is missing from Kotlin. The set of Scala features Spark is using is pretty much identical to Kotlin. I didn't mention implicit conversions, but that's one area where Scala has taken the high risk high reward path. If you look a bit further down on the linked Spark page you'll see the conversions defined [1]. I'd say Spark's style guide is more geared toward Scala consumers and not necessarily library authors (i.e. if you know what you're doing have at it; otherwise keep to a strict subset). Basically, in aggregate Scala's feature set is incredibly powerful; that power (despite the complexity, tooling challenges, and slow builds) is what draws dsl authors to Scala. When IBM throws down an absolute boatload of cash on a project written in Scala, by proxy Scala benefits. Right off the bat there are de facto 3,500 new Scala developers (since the initial IBM Spark team will of course be learning Scala). Furthermore, it's not like competitors aren't aware of this, Spark automically becomes more of a "big deal" as a result, which cannot help but be a boon for Scala. As for other JVM languages, agreed, Clojure has its own supply of awesome, though the lack of (built-in) static types are a no-op here. Groovy, meh, seems to be on a downtrend, I suspect non-immutable-by-default dynamic languages (except of course, javascript) will continue to fall out of favor. Now, Kotlin, it's a nice language. If they can deliver on near Java build times, might just be the Java killer that Scala will never be, or at least not in its current design (where, as you rightly say, there is often more than one way to do the same thing). Let's see how things play out over the next 3-5 years, JVM alternative language landscape is diverse and evolving quickly, good times now and great times ahead... [1] https://github.com/apache/spark/blob/master/sql/catalyst/src/main/scala/org/apache/spark/sql/catalyst/dsl/package.scala#L115 https://github.com/apache/spark/blob/master/sql/catalyst/src...

pron 11y ago
> I didn't mention implicit conversions, but that's one area where Scala has taken the high risk high reward path. We C++ veterans know that implicit conversions are one of the worst ideas to put in a language. They start simple enough and then they get clever, which is where trouble starts. > i.e. if you know what you're doing have at it; otherwise keep to a strict subset There are few things about programming language design we know, because getting empirical data is so hard. One of the few things we do know (from C++ in the nineties, of course) is that this kind of design doesn't work. The average codebase lifespan is about a decade, during which time people move around and team leads change. Everyone has their own discipline, and by year 5 (usually earlier), the codebase is unmaintainable. Of course, now that C++ has been re-branded and re-purposed as a specialized language for close-to-hardware software, and is used by specialists, it is doing quite well. I certainly wouldn't mind Scala marketing itself -- like C++ and Haskell do -- as a language for specialists (although even specialists would be better off opting for the excellent OCaml implementation on the JVM, or even Frege if Haskell is your cup of tea). There is absolutely no reason to be as multi-paradigm as Scala is on the most polyglot platform around, which brings me to: > that power... is what draws dsl authors to Scala. One of the great things about the JVM is its relatively easy inter-language interop. I would use a meta-language made for DSLs (like Clojure, MPS or Xtext) for my DSL, while I'll write the infrastructure in Java/Kotlin. Learning Java and Clojure, or Kotlin and MPS, is easier than learning Scala alone (well enough for DSLs), and the results are cleaner, produce more maintainable code and better error messages (well, I wouldn't say Clojure excels at error messages, but at least the DSL writer has full control over them, and can make them quite good with an extra bit of effort). Also, I'd like to see what those DSL codebases look like after five years of heavy usage (not to mention the error messages Scala spits out, which are completely unparsable to anyone who does not understand how the DSL is constructed).
- virtualwhys 11y ago
  > We C++ veterans know that implicit conversions are one of the worst ideas to put in a language Too late to yank them now, can be disastrous in the wrong (read: beginner) hands, but they're fantistically useful in the dsl department so... > The average codebase lifespan is about a decade maintainability is an issue for the long haul, sure, Scala won't win that battle until it stabilizes, which is at minimum 3 years away when Dotty (Scala 3) comes on the scene. > I certainly wouldn't mind Scala marketing itself -- like C++ and Haskell do -- as a language for specialists Typesafe does the marketing, and as a business they'll never sell their technology short, even if what you say is closer to the truth wrt to specialization. > better off opting for the excellent OCaml implementation on the JVM, or even Frege if Haskell is your cup of tea no users = no dice; doubt either will grab much mindshare in the near-term. Personally I would love to see SML cherry pick the non-crufty good parts of OCaml (including coming implicit parameters) and have that find a following outside of current tiny academic circle it languishes in. > Also, I'd like to see what those DSL codebases look like after five years of heavy usage They probably look a lot different than how they started out as...paraphrasing someone, "you're going to rewrite it [your application] at least 3X" ;-) Basically the entire Scala ecosystem is a moving target, including the language itself. Enterprise outfits looking for a static dependency graph that will work today and 10 years from now should look at Java as the host language. I doubt Kotlin will be able to deliver the same guarantees, but if it can, watch out Oracle.
  - pron 11y ago
    > Typesafe does the marketing, and as a business they'll never sell their technology short, even if what you say is closer to the truth wrt to specialization. I don't think that's selling it short. Accurately describing your product only prevents people who aren't really your target -- like me -- from being disappointed and telling the world about it, while it helps attract precisely those people who would be most excited about it. Also, I think Typesafe realize now that there is not much money to be made in developing and supporting a programming language (ironically, there is some to be made -- though not too much -- supporting specialist languages; see Ada and Matlab). That's why they want to change their name, right? > no users = no dice; doubt either will grab much mindshare in the near-term. That's splitting hairs a bit; Scala doesn't exactly have mass appeal either. We're talking about the difference between tiny and small. > I doubt Kotlin will be able to deliver the same guarantees, but if it can, watch out Oracle. I know they're trying to. Also, I know Oracle actively encourages alternative JVM languages. Their product is the Java platform, which currently -- to be honest -- is not too far from being the same as Java the language (all alternative JVM languages combined don't amount to 10%, or possibly even 5% of the JVM ecosystem). But they wouldn't mind if that changes. Their research team working on Graal, HotSpot's next-gen JIT, coming to OpenJDK in Java 9, spends as much time on making sure it runs Ruby, R, C, Python, and JavaScript well as it does on making sure it runs Java well. I know Oracle's Java team isn't all too happy about it, but I also know that that's what Oracle wants.

pron 11y ago

> I didn't mention implicit conversions, but that's one area where Scala has taken the high risk high reward path. We C++ veterans know that implicit conversions are one of the worst ideas to put in a language. They start simple enough and then they get clever, which is where trouble starts. > i.e. if you know what you're doing have at it; otherwise keep to a strict subset There are few things about programming language design we know, because getting empirical data is so hard. One of the few things we do know (from C++ in the nineties, of course) is that this kind of design doesn't work. The average codebase lifespan is about a decade, during which time people move around and team leads change. Everyone has their own discipline, and by year 5 (usually earlier), the codebase is unmaintainable. Of course, now that C++ has been re-branded and re-purposed as a specialized language for close-to-hardware software, and is used by specialists, it is doing quite well. I certainly wouldn't mind Scala marketing itself -- like C++ and Haskell do -- as a language for specialists (although even specialists would be better off opting for the excellent OCaml implementation on the JVM, or even Frege if Haskell is your cup of tea). There is absolutely no reason to be as multi-paradigm as Scala is on the most polyglot platform around, which brings me to: > that power... is what draws dsl authors to Scala. One of the great things about the JVM is its relatively easy inter-language interop. I would use a meta-language made for DSLs (like Clojure, MPS or Xtext) for my DSL, while I'll write the infrastructure in Java/Kotlin. Learning Java and Clojure, or Kotlin and MPS, is easier than learning Scala alone (well enough for DSLs), and the results are cleaner, produce more maintainable code and better error messages (well, I wouldn't say Clojure excels at error messages, but at least the DSL writer has full control over them, and can make them quite good with an extra bit of effort). Also, I'd like to see what those DSL codebases look like after five years of heavy usage (not to mention the error messages Scala spits out, which are completely unparsable to anyone who does not understand how the DSL is constructed).

virtualwhys 11y ago
> We C++ veterans know that implicit conversions are one of the worst ideas to put in a language Too late to yank them now, can be disastrous in the wrong (read: beginner) hands, but they're fantistically useful in the dsl department so... > The average codebase lifespan is about a decade maintainability is an issue for the long haul, sure, Scala won't win that battle until it stabilizes, which is at minimum 3 years away when Dotty (Scala 3) comes on the scene. > I certainly wouldn't mind Scala marketing itself -- like C++ and Haskell do -- as a language for specialists Typesafe does the marketing, and as a business they'll never sell their technology short, even if what you say is closer to the truth wrt to specialization. > better off opting for the excellent OCaml implementation on the JVM, or even Frege if Haskell is your cup of tea no users = no dice; doubt either will grab much mindshare in the near-term. Personally I would love to see SML cherry pick the non-crufty good parts of OCaml (including coming implicit parameters) and have that find a following outside of current tiny academic circle it languishes in. > Also, I'd like to see what those DSL codebases look like after five years of heavy usage They probably look a lot different than how they started out as...paraphrasing someone, "you're going to rewrite it [your application] at least 3X" ;-) Basically the entire Scala ecosystem is a moving target, including the language itself. Enterprise outfits looking for a static dependency graph that will work today and 10 years from now should look at Java as the host language. I doubt Kotlin will be able to deliver the same guarantees, but if it can, watch out Oracle.
- pron 11y ago
  > Typesafe does the marketing, and as a business they'll never sell their technology short, even if what you say is closer to the truth wrt to specialization. I don't think that's selling it short. Accurately describing your product only prevents people who aren't really your target -- like me -- from being disappointed and telling the world about it, while it helps attract precisely those people who would be most excited about it. Also, I think Typesafe realize now that there is not much money to be made in developing and supporting a programming language (ironically, there is some to be made -- though not too much -- supporting specialist languages; see Ada and Matlab). That's why they want to change their name, right? > no users = no dice; doubt either will grab much mindshare in the near-term. That's splitting hairs a bit; Scala doesn't exactly have mass appeal either. We're talking about the difference between tiny and small. > I doubt Kotlin will be able to deliver the same guarantees, but if it can, watch out Oracle. I know they're trying to. Also, I know Oracle actively encourages alternative JVM languages. Their product is the Java platform, which currently -- to be honest -- is not too far from being the same as Java the language (all alternative JVM languages combined don't amount to 10%, or possibly even 5% of the JVM ecosystem). But they wouldn't mind if that changes. Their research team working on Graal, HotSpot's next-gen JIT, coming to OpenJDK in Java 9, spends as much time on making sure it runs Ruby, R, C, Python, and JavaScript well as it does on making sure it runs Java well. I know Oracle's Java team isn't all too happy about it, but I also know that that's what Oracle wants.