4 ms·

For me Scala was never about using a Java++. If you want Java++, the best Java++ is still Java with a bunch of libraries. You don't need a new language for tha

For me Scala was never about using a Java++. If you want Java++, the best Java++ is still Java with a bunch of libraries. You don't need a new language for that. Kotlin's succes is effectively because Google was late to port Java 8 to Android. A fine language btw, but it will either become more like Scala, or it will wither away eventually. My bet is in it becoming more like Scala, as evidenced by arrow-kt.io Scala has a blend of features that makes it the most expressive mainstream functional programming language, most importantly ... implicits, by which you can model typeclasses and higher kinded types. And in Scala we've got an active community of FP libraries. Actual FP, emphasizing referential transparency, with abstractions built for suspending effects. It's a little known fact but the kind of FP programming we do in Scala tends to be more pure than what happens in OCaml, F#, Erlang, Clojure and others. Also, we have a Scala to Javascript compiler, all the tooling works with it and we've got an ecosystem of libraries cross-compiled to Javascript. As for Scala Native, it has its place. The problem has been lack of manpower to bring it to the maturity that Scala.js is at.

idnefju 7y ago
> It's a little known fact but the kind of FP programming we do in Scala tends to be more pure than what happens in OCaml, F#, Erlang, Clojure and others. What do you mean by pure exactly? IO Monad? Simply no side effects?
- bad_user 7y ago
  Yes. Many libraries in the FP Scala community are concerned with modeling effects in a pure way.
  - idnefju 7y ago
    Oh interesting view. It's funny since Scala's author himself doesn't consider the IO monad to be "pure". > “The IO monad does not make a function pure. It just makes it obvious that it’s impure.” https://groups.google.com/forum/#!topic/scala-debate/xYlUlQAnkmE%5B251-275%5D https://groups.google.com/forum/#!topic/scala-debate/xYlUlQA...
    - willtim 7y ago
      It's a pure function because it doesn't do any IO. It returns an action that, when run, performs the IO. Because it's a pure function, we have referential transparency, we can safely replace the function call with its computed value (the action) anywhere in the program.
      - victorNicollet 7y ago
        In a typical IO function, the first 10% of the code returns a monad-bind that holds the remaining 90% of the code in a closure. The pieces are pure, but the whole isn't meaningfully pure.
        deleted 7y ago
        [deleted]
        bad_user 7y ago
        A function returning IO preserves referential transparency. fn() + fn() // ---- val a = fn() a + a Are the two programs above equivalent? For a function returning IO, they are. For a function that's side effectful, they are not. (As an exercise for the reader, think of our function here returning Future/Promise instead of an IO, how would that change the program?) This is a definition of purity that you can work with. The trap that people fall in is to talk about fiction essentially. What is "meaningful" anyway? If you don't give it a definition, is it meaningful to talk about what's meaningful? I agree that a function returning IO is opaque. You can't reinterpret it, it's no longer a plan that you can change the interpreter for, but something concrete. There are of course better abstractions for dealing with effects in a way as to make them less opaque ... like the Free Monad, or Eff. Many of them have been expressed in Scala as well.
        victorNicollet 7y ago
        Purity is not a goal in itself, its purpose (its meaning) is to help me answer useful questions about the behaviour of the program. In a typical IO function, `fn()` only gives me 10% of the code in `fn`: the part up to the first bind. To get the rest, I need to `do` it, and this is where purity is no longer meaningful: a <- fn "a" b <- fn "b" Can I swap these two lines ? The IO monad tells me there might be consequences, but what are they ? Another example: foo fn Will `foo` trigger the IO effects of `fn` zero, one or more times ? I believe these are meaningful questions, and yet, a program built from pure functions can answer them no better than an imperative program.
willtim 7y ago
> It's a little known fact but the kind of FP programming we do in Scala tends to be more pure than what happens in OCaml, F#, Erlang, Clojure and others. I have only dabbled in Scala, but IMHO it's more suited as an OCaml with first-class modules. Why not use Haskell, if you don't need the JVM?
- bad_user 7y ago
  Compared with OCaml, Scala can express type classes and has higher-kinded types. Many abstractions that are easy to express in Scala are in fact hard to express in OCaml. For-comprehensions are worse than Haskell's do-notation or compared with F#'s computation expressions, but the list ends there. In practice they work well and at least Scala has monadic for-comprehensions. How many other languages can claim that? As for performance, I encourage you to take a look at the state of the art. Working with our IO Monads has better performance than many abstractions that people now take for granted, like most Future/Promise implementations. I build systems that are super stressed by incoming traffic and Scala's performance is awesome. Worse than bare metal Java of course, but when you compare it with high level Java frameworks or with Python/Ruby/Javascript/what have you, you'd actually be surprised by how better Scala FP is ;-) As for Haskell, I like the language, but it's super fragmented, everyone has its own Prelude and favorite language extensions, extensions that are sometimes in conflict with other extensions and the tooling is a mess. Also laziness is cool, but performance gets hard to predict. We have the same problem in Scala when we are using lazy abstractions actually, the difference being that Scala is opt-in instead of opt-out. With Scala, even if you're targeting JS instead of the JVM, you still use the same tools. And I even like the language better. Scala 3 will fix many annoyances I have, including adding untagged unions and GADTs that are based on ADTs, in other words nicer than Haskell. PureScript I would like though, as it fixes some of Haskell's problems, maybe one day it won't be limited to JS.
  - willtim 7y ago
    Thanks for the detailed reply!
  - dm3 7y ago
    > As for Haskell, I like the language, but it's super fragmented, everyone has its own Prelude and favorite language extensions, extensions that are sometimes in conflict with other extensions and the tooling is a mess. Also laziness is cool, but performance gets hard to predict. We have the same problem in Scala when we are using lazy abstractions actually, the difference being that Scala is opt-in instead of opt-out. Not an expert in Haskell, nor Scala - only dabbling. However, the above could be repeated verbatim after replacing Haskell with Scala, couldn't it? You can write Java++, Haskell-- or any combination in between. Use one of the several FP stacks or build tools. I think both Scala, Haskell and C++ can compete for the name of the most complicated, fragmented and diverse language and ecosystem in existence.
jjtheblunt 7y ago
"implicits" seems a polarizing feature

idnefju 7y ago

> It's a little known fact but the kind of FP programming we do in Scala tends to be more pure than what happens in OCaml, F#, Erlang, Clojure and others. What do you mean by pure exactly? IO Monad? Simply no side effects?

bad_user 7y ago
Yes. Many libraries in the FP Scala community are concerned with modeling effects in a pure way.
- idnefju 7y ago
  Oh interesting view. It's funny since Scala's author himself doesn't consider the IO monad to be "pure". > “The IO monad does not make a function pure. It just makes it obvious that it’s impure.” https://groups.google.com/forum/#!topic/scala-debate/xYlUlQAnkmE%5B251-275%5D https://groups.google.com/forum/#!topic/scala-debate/xYlUlQA...
  - willtim 7y ago
    It's a pure function because it doesn't do any IO. It returns an action that, when run, performs the IO. Because it's a pure function, we have referential transparency, we can safely replace the function call with its computed value (the action) anywhere in the program.
    - victorNicollet 7y ago
      In a typical IO function, the first 10% of the code returns a monad-bind that holds the remaining 90% of the code in a closure. The pieces are pure, but the whole isn't meaningfully pure.
      - deleted 7y ago
        [deleted]
      - bad_user 7y ago
        A function returning IO preserves referential transparency. fn() + fn() // ---- val a = fn() a + a Are the two programs above equivalent? For a function returning IO, they are. For a function that's side effectful, they are not. (As an exercise for the reader, think of our function here returning Future/Promise instead of an IO, how would that change the program?) This is a definition of purity that you can work with. The trap that people fall in is to talk about fiction essentially. What is "meaningful" anyway? If you don't give it a definition, is it meaningful to talk about what's meaningful? I agree that a function returning IO is opaque. You can't reinterpret it, it's no longer a plan that you can change the interpreter for, but something concrete. There are of course better abstractions for dealing with effects in a way as to make them less opaque ... like the Free Monad, or Eff. Many of them have been expressed in Scala as well.
        victorNicollet 7y ago
        Purity is not a goal in itself, its purpose (its meaning) is to help me answer useful questions about the behaviour of the program. In a typical IO function, `fn()` only gives me 10% of the code in `fn`: the part up to the first bind. To get the rest, I need to `do` it, and this is where purity is no longer meaningful: a <- fn "a" b <- fn "b" Can I swap these two lines ? The IO monad tells me there might be consequences, but what are they ? Another example: foo fn Will `foo` trigger the IO effects of `fn` zero, one or more times ? I believe these are meaningful questions, and yet, a program built from pure functions can answer them no better than an imperative program.

willtim 7y ago

> It's a little known fact but the kind of FP programming we do in Scala tends to be more pure than what happens in OCaml, F#, Erlang, Clojure and others. I have only dabbled in Scala, but IMHO it's more suited as an OCaml with first-class modules. Why not use Haskell, if you don't need the JVM?

bad_user 7y ago
Compared with OCaml, Scala can express type classes and has higher-kinded types. Many abstractions that are easy to express in Scala are in fact hard to express in OCaml. For-comprehensions are worse than Haskell's do-notation or compared with F#'s computation expressions, but the list ends there. In practice they work well and at least Scala has monadic for-comprehensions. How many other languages can claim that? As for performance, I encourage you to take a look at the state of the art. Working with our IO Monads has better performance than many abstractions that people now take for granted, like most Future/Promise implementations. I build systems that are super stressed by incoming traffic and Scala's performance is awesome. Worse than bare metal Java of course, but when you compare it with high level Java frameworks or with Python/Ruby/Javascript/what have you, you'd actually be surprised by how better Scala FP is ;-) As for Haskell, I like the language, but it's super fragmented, everyone has its own Prelude and favorite language extensions, extensions that are sometimes in conflict with other extensions and the tooling is a mess. Also laziness is cool, but performance gets hard to predict. We have the same problem in Scala when we are using lazy abstractions actually, the difference being that Scala is opt-in instead of opt-out. With Scala, even if you're targeting JS instead of the JVM, you still use the same tools. And I even like the language better. Scala 3 will fix many annoyances I have, including adding untagged unions and GADTs that are based on ADTs, in other words nicer than Haskell. PureScript I would like though, as it fixes some of Haskell's problems, maybe one day it won't be limited to JS.
- willtim 7y ago
  Thanks for the detailed reply!
- dm3 7y ago
  > As for Haskell, I like the language, but it's super fragmented, everyone has its own Prelude and favorite language extensions, extensions that are sometimes in conflict with other extensions and the tooling is a mess. Also laziness is cool, but performance gets hard to predict. We have the same problem in Scala when we are using lazy abstractions actually, the difference being that Scala is opt-in instead of opt-out. Not an expert in Haskell, nor Scala - only dabbling. However, the above could be repeated verbatim after replacing Haskell with Scala, couldn't it? You can write Java++, Haskell-- or any combination in between. Use one of the several FP stacks or build tools. I think both Scala, Haskell and C++ can compete for the name of the most complicated, fragmented and diverse language and ecosystem in existence.

jjtheblunt 7y ago

"implicits" seems a polarizing feature