4 ms·

OP here. I don't know Scala or Haskell well enough to make a "correct choice" either now or then, but basically I had some experience with ML type systems (from

OP here. I don't know Scala or Haskell well enough to make a "correct choice" either now or then, but basically I had some experience with ML type systems (from Elm and Haskell) and thought sum types were great. Scala seemed like a mess at the time (from a distance - no idea whether I'm right). My attempts at Haskell had honestly not gone all that well, the lazyness and pure functional-ness I felt were not great. Basically, I wanted server-side Elm, and OCaml was pretty close. Tried it, didn't hate it, figured could always do a rewrite later. And here we are.

to11mtm 6y ago
> Scala seemed like a mess at the time (from a distance - no idea whether I'm right). I work on and use the .NET Port of Akka from the Scala/JVM world. In those travels it has included reading a pretty decent amount of Scala code. I wouldn't call it a mess so much as a very -expressive- language. But the cost of that is there are a lot of different ways to do things, and some parts of Scala that are very powerful can be very confusing until you understand them. My favorite analogy for .NET developers; if they remember their confusion the first time they had to comprehend => delegate syntax, there's lots of little things in the same vein in Scala; ways for the compiler to generate sugar. There's just so -many- of them it can be overwhelming, doubly so when in some cases the wrong choice can in fact have pretty big performance implications.
dwohnitmok 6y ago
It sounds like you've already made a choice, but on the off chance you haven't I would suggest Kotlin. I would recommend Scala in second, but you really need at least one person who knows Scala well to navigate the wildly divergent styles of Scala programs out there. Kotlin gives you sum types via sealed classes. In fact it's basically the bare minimum of Java + sum types + some syntactic sugar. It has rock solid tooling due to Jetbrains support. It has access to the entire JVM ecosystem. It has a huge amount of learning materials out there. And it's got all the resources on how to deal with web CRUD problems you could ever imagine. It's not server-side Elm by a long shot, but to be fair, Elm would suffer from all the same problems you listed.
- yawaramin 6y ago
  Eh, for someone who likes OCaml and sum types, I don't think they would be wild about Kotlin. It doesn't have any generalized pattern matching, for example.
  - dwohnitmok 6y ago
    Yeah, and its ecosystem loves mutability, but with discipline in your own codebase you can get 80% of OCaml with access to an amazing ecosystem and tooling. After all nested when expressions aren't the end of the world...
    - lostcolony 6y ago
      'but with discipline in your own codebase' If I had that (and, more importantly, trusted every other developer I work with to also have that) I wouldn't value immutability enough to look for it in my language choice.
      - dwohnitmok 6y ago
        It's a bit more subtle than that. Almost every language has a sliding scale of discipline rather than a binary one. E.g. you could decide to write extremely mutable code in OCaml, but it's highly discouraged and the happy path is generally to default to immutability. So you need comparatively little, although not none, discipline to have a pervasively immutable codebase, since there's nothing preventing you at a language level from introducing crazy mutation everywhere. Haskell goes further, where you have to use functions named "unsafe*" to introduce mutability. Something like Elm goes further still, where, barring bugs in low-level libraries or heavy abuse of the JavaScript runtime (e.g. redefining prototypes of basic types), you essentially have to fork the compiler to introduce mutability (Dark moved away from Elm because, as I understand it, it actually became too restrictive on this front). On the other hand, in something like Java, you need a lot of discipline to have pervasive immutability and you have to go out of your way to avoid using otherwise common constructs (e.g. if statements since those are statements rather than expressions) that require very kludgey workarounds (encoding an algebraic data type as a fold and using that in place of if statements). Kotlin is in the middle. If you don't use certain parts of the standard library and don't use things like var, you have pervasive immutability. At a language level this is quite similar to Scala (Scala has a more immutably focused standard library than Kotlin does).
ebruchez 6y ago
> Scala seemed like a mess at the time (from a distance - no idea whether I'm right). I love Scala, and it's getting better year over year from all angles. It's also getting a little more opinionated. The upcoming version 3 removes long-standing warts and adds great features including sum types, intersection types, enums, and more. A huge thing is that it addresses binary compatibility issues, by allowing Scala 2 and 3 to use each other's libraries. Also, Scala has wonderful, super stable JavaScript support with Scala.js, and under development native support Scala Native.
cheriot 6y ago
I'd be curious what you think about Scala 3. Interoperability with Scala 2 and Java solves the library problem. And the language itself seems to really take on learnings from its own history and other modern languages.

to11mtm 6y ago

> Scala seemed like a mess at the time (from a distance - no idea whether I'm right). I work on and use the .NET Port of Akka from the Scala/JVM world. In those travels it has included reading a pretty decent amount of Scala code. I wouldn't call it a mess so much as a very -expressive- language. But the cost of that is there are a lot of different ways to do things, and some parts of Scala that are very powerful can be very confusing until you understand them. My favorite analogy for .NET developers; if they remember their confusion the first time they had to comprehend => delegate syntax, there's lots of little things in the same vein in Scala; ways for the compiler to generate sugar. There's just so -many- of them it can be overwhelming, doubly so when in some cases the wrong choice can in fact have pretty big performance implications.

dwohnitmok 6y ago

It sounds like you've already made a choice, but on the off chance you haven't I would suggest Kotlin. I would recommend Scala in second, but you really need at least one person who knows Scala well to navigate the wildly divergent styles of Scala programs out there. Kotlin gives you sum types via sealed classes. In fact it's basically the bare minimum of Java + sum types + some syntactic sugar. It has rock solid tooling due to Jetbrains support. It has access to the entire JVM ecosystem. It has a huge amount of learning materials out there. And it's got all the resources on how to deal with web CRUD problems you could ever imagine. It's not server-side Elm by a long shot, but to be fair, Elm would suffer from all the same problems you listed.

yawaramin 6y ago
Eh, for someone who likes OCaml and sum types, I don't think they would be wild about Kotlin. It doesn't have any generalized pattern matching, for example.
- dwohnitmok 6y ago
  Yeah, and its ecosystem loves mutability, but with discipline in your own codebase you can get 80% of OCaml with access to an amazing ecosystem and tooling. After all nested when expressions aren't the end of the world...
  - lostcolony 6y ago
    'but with discipline in your own codebase' If I had that (and, more importantly, trusted every other developer I work with to also have that) I wouldn't value immutability enough to look for it in my language choice.
    - dwohnitmok 6y ago
      It's a bit more subtle than that. Almost every language has a sliding scale of discipline rather than a binary one. E.g. you could decide to write extremely mutable code in OCaml, but it's highly discouraged and the happy path is generally to default to immutability. So you need comparatively little, although not none, discipline to have a pervasively immutable codebase, since there's nothing preventing you at a language level from introducing crazy mutation everywhere. Haskell goes further, where you have to use functions named "unsafe*" to introduce mutability. Something like Elm goes further still, where, barring bugs in low-level libraries or heavy abuse of the JavaScript runtime (e.g. redefining prototypes of basic types), you essentially have to fork the compiler to introduce mutability (Dark moved away from Elm because, as I understand it, it actually became too restrictive on this front). On the other hand, in something like Java, you need a lot of discipline to have pervasive immutability and you have to go out of your way to avoid using otherwise common constructs (e.g. if statements since those are statements rather than expressions) that require very kludgey workarounds (encoding an algebraic data type as a fold and using that in place of if statements). Kotlin is in the middle. If you don't use certain parts of the standard library and don't use things like var, you have pervasive immutability. At a language level this is quite similar to Scala (Scala has a more immutably focused standard library than Kotlin does).

ebruchez 6y ago

> Scala seemed like a mess at the time (from a distance - no idea whether I'm right). I love Scala, and it's getting better year over year from all angles. It's also getting a little more opinionated. The upcoming version 3 removes long-standing warts and adds great features including sum types, intersection types, enums, and more. A huge thing is that it addresses binary compatibility issues, by allowing Scala 2 and 3 to use each other's libraries. Also, Scala has wonderful, super stable JavaScript support with Scala.js, and under development native support Scala Native.

cheriot 6y ago

I'd be curious what you think about Scala 3. Interoperability with Scala 2 and Java solves the library problem. And the language itself seems to really take on learnings from its own history and other modern languages.