5 ms·

That is a very narrow view of Scala. It's a great and powerful language.

the_af 10y ago
No-one denies Scala is a fine language, but I don't think that's a narrow view of it. It's actually a pretty good question. A lot of Scala's design is full of compromises made for Java inter-op. A huge motivation for using Scala is "I want a modern language which allows me to use all these existing Java libraries and tools". If you remove the ecosystem and the inter-op, what is there left for Scala? Why not use a better language?
- dsabanin 10y ago
  I don't think the amount of compromises in Scala is more than the amount of compromises in any other language. No matter how clean the language starts up to be, after a certain time it always has to accumulate compromises with it's own previous design decisions, unless it's being kept in the never-ending alpha release state. Can you provide an example of what you think is a better language?
- hibikir 10y ago
  Because all the other languages mentioned are better only from very specific perspectives. Scala's strength is precisely that it's a mutt: Want to write imperative code? Sure. Functional? No problem. How about a type system that far more featureful than Go? That works too. Scala gets a bad rap precisely because people are big fans of their own way of writing code, call it better, and think that anyone that wants something else is deluded. The Scala way is to say 'sure, you can do that too, to hell with purity'. I'd rather have power over purity any day.
  - the_af 10y ago
    Note: I use Scala in my day job. I consider it better than Java, but worse than other languages. I definitely agree that all languages accumulate compromises and inelegant hacks as they evolve. It's unavoidable. That said, in my opinion Scala's blunders are many. You can find out about many of them from Paul Philips, ex committer of Scala, but if he sounds too bitter to you (he does to me; at this point he sounds like there is bad blood between him and Odersky), here are some of mine: - Null. Null will come back to bite you in Scala code, whenever you call Java libraries, and the occasional Scala library that didn't get the memo. Sure, you can wrap every suspect value with Option(...), but why should you do this? - Type inference is not as powerful as in a language with a cleaner type system such as Haskell. I'm told this is because Scala tries to be both OOP (inheritance) and FP at the same time. Here is a clear case of Scala's attempt at being a "jack of all trades" resulting in it being inferior than the sum of its parts. - Type signatures in Scala collections and core types are extremely hard to read. You do not need to read them, but if you try, you are in for a world of hurt. This in itself is not a mortal sin, but of course if you're willing to forgive Scala this much complexity, surely you're willing to forgive other languages as well? - Tooling is bad. It's getting better, but it's still bad. SBT is painful to use. As for IDEs, IntelliJ is now the recommended choice; I've tried both Scala IDE and IntelliJ, and they both suck. Slow, spurious compilation errors, uncomfortable to use. - And finally, telling bit of personal experience: I do NOT use Haskell professionally, yet whenever I want to try a quick idea and see if it typechecks, I find it easier to open ghci (the Haskell REPL) and try my idea than do the same with the Scala REPL. What does this say about Scala?
    - airless_bar 10y ago
      > all languages accumulate compromises and inelegant hacks as they evolve. It's unavoidable. Scala devs deprecate and remove things that haven't worked out well. They have an established track record of making these migrations easier with each release. > Null Upcoming versions will make references non-nullable by default. If you want things to be nullable, you will have to opt-in explicitly with T|Null. > - Type inference Type inference is not a huge priority, because people think that it's a good thing that declarations require type annotations (just like it's recommended in Haskell, too). One of the last pain-points, higher-kinded unification of type constructors, has been fixed recently which will make type inference "just work" in exactly those cases where the lack of type inference was most annoying. > - Tooling I think tooling is pretty amazing. Sure, Java has still some advantages in some places. But the tooling is superior to almost all other languages out there. SBT is amazing. IDE support is getting vastly better, not only have Eclipse and IntelliJ improved vastly, but also IDE support for Emacs, Vim, Sublime, etc. is coming along at a rapid rate, and it's just amazing to use. There are so many tools in the Scala ecosystem which just don't exist in this combination anywhere else.
      - the_af 10y ago
        > If you want things to be nullable, you will have to opt-in explicitly with T|Null I can see how the opt-in null references might help prevent you from writing Scala code that uses null, but how does it help when interacting with Java code?
        airless_bar 10y ago
        Thanks for the downvote. Let's close this discussion.
        the_af 10y ago
        I didn't downvote you. In fact, I consider your post interesting, because (for example) I didn't know about the opt-in nullable references. Here's a +1 to counter the downvote.
  - duaneb 10y ago
    > Scala's strength is precisely that it's a mutt: Want to write imperative code? Sure. Functional? No problem. How about a type system that far more featureful than Go? That works too. This also essentially describes C++. This is also why both languages can be so terrible to use: every library has its own dialect.
    - airless_bar 10y ago
      The C++ comparison is great because it tells readers that that the person making it has no idea about C++, Scala or both.
- joostdevries 10y ago
  I remember Martin Odersky explaining how the Scala compiler has to do a lot of work to compile FP code to a JVM that is mostly geared for the Java language only. Because of that the compiler is well positioned to compile to other targets as well. Like Javascript or LLVM. Are you talking about compromises in the language or the standard library? In the language itself I can only think of type erasure for generics having to follow the JVM choice.
  - joostdevries 10y ago
    Snif. sbt demoNative/compile seems to work. But sbt demoNative/run produces a scala.scalanative.linker.LinkingError Unresolved dependencies: `#scala.Serializable`

No-one denies Scala is a fine language, but I don't think that's a narrow view of it. It's actually a pretty good question. A lot of Scala's design is full of compromises made for Java inter-op. A huge motivation for using Scala is "I want a modern language which allows me to use all these existing Java libraries and tools". If you remove the ecosystem and the inter-op, what is there left for Scala? Why not use a better language?

dsabanin 10y ago
I don't think the amount of compromises in Scala is more than the amount of compromises in any other language. No matter how clean the language starts up to be, after a certain time it always has to accumulate compromises with it's own previous design decisions, unless it's being kept in the never-ending alpha release state. Can you provide an example of what you think is a better language?
hibikir 10y ago
Because all the other languages mentioned are better only from very specific perspectives. Scala's strength is precisely that it's a mutt: Want to write imperative code? Sure. Functional? No problem. How about a type system that far more featureful than Go? That works too. Scala gets a bad rap precisely because people are big fans of their own way of writing code, call it better, and think that anyone that wants something else is deluded. The Scala way is to say 'sure, you can do that too, to hell with purity'. I'd rather have power over purity any day.
- the_af 10y ago
  Note: I use Scala in my day job. I consider it better than Java, but worse than other languages. I definitely agree that all languages accumulate compromises and inelegant hacks as they evolve. It's unavoidable. That said, in my opinion Scala's blunders are many. You can find out about many of them from Paul Philips, ex committer of Scala, but if he sounds too bitter to you (he does to me; at this point he sounds like there is bad blood between him and Odersky), here are some of mine: - Null. Null will come back to bite you in Scala code, whenever you call Java libraries, and the occasional Scala library that didn't get the memo. Sure, you can wrap every suspect value with Option(...), but why should you do this? - Type inference is not as powerful as in a language with a cleaner type system such as Haskell. I'm told this is because Scala tries to be both OOP (inheritance) and FP at the same time. Here is a clear case of Scala's attempt at being a "jack of all trades" resulting in it being inferior than the sum of its parts. - Type signatures in Scala collections and core types are extremely hard to read. You do not need to read them, but if you try, you are in for a world of hurt. This in itself is not a mortal sin, but of course if you're willing to forgive Scala this much complexity, surely you're willing to forgive other languages as well? - Tooling is bad. It's getting better, but it's still bad. SBT is painful to use. As for IDEs, IntelliJ is now the recommended choice; I've tried both Scala IDE and IntelliJ, and they both suck. Slow, spurious compilation errors, uncomfortable to use. - And finally, telling bit of personal experience: I do NOT use Haskell professionally, yet whenever I want to try a quick idea and see if it typechecks, I find it easier to open ghci (the Haskell REPL) and try my idea than do the same with the Scala REPL. What does this say about Scala?
  - airless_bar 10y ago
    > all languages accumulate compromises and inelegant hacks as they evolve. It's unavoidable. Scala devs deprecate and remove things that haven't worked out well. They have an established track record of making these migrations easier with each release. > Null Upcoming versions will make references non-nullable by default. If you want things to be nullable, you will have to opt-in explicitly with T|Null. > - Type inference Type inference is not a huge priority, because people think that it's a good thing that declarations require type annotations (just like it's recommended in Haskell, too). One of the last pain-points, higher-kinded unification of type constructors, has been fixed recently which will make type inference "just work" in exactly those cases where the lack of type inference was most annoying. > - Tooling I think tooling is pretty amazing. Sure, Java has still some advantages in some places. But the tooling is superior to almost all other languages out there. SBT is amazing. IDE support is getting vastly better, not only have Eclipse and IntelliJ improved vastly, but also IDE support for Emacs, Vim, Sublime, etc. is coming along at a rapid rate, and it's just amazing to use. There are so many tools in the Scala ecosystem which just don't exist in this combination anywhere else.
    - the_af 10y ago
      > If you want things to be nullable, you will have to opt-in explicitly with T|Null I can see how the opt-in null references might help prevent you from writing Scala code that uses null, but how does it help when interacting with Java code?
      - airless_bar 10y ago
        Thanks for the downvote. Let's close this discussion.
        the_af 10y ago
        I didn't downvote you. In fact, I consider your post interesting, because (for example) I didn't know about the opt-in nullable references. Here's a +1 to counter the downvote.
- duaneb 10y ago
  > Scala's strength is precisely that it's a mutt: Want to write imperative code? Sure. Functional? No problem. How about a type system that far more featureful than Go? That works too. This also essentially describes C++. This is also why both languages can be so terrible to use: every library has its own dialect.
  - airless_bar 10y ago
    The C++ comparison is great because it tells readers that that the person making it has no idea about C++, Scala or both.
joostdevries 10y ago
I remember Martin Odersky explaining how the Scala compiler has to do a lot of work to compile FP code to a JVM that is mostly geared for the Java language only. Because of that the compiler is well positioned to compile to other targets as well. Like Javascript or LLVM. Are you talking about compromises in the language or the standard library? In the language itself I can only think of type erasure for generics having to follow the JVM choice.
- joostdevries 10y ago
  Snif. sbt demoNative/compile seems to work. But sbt demoNative/run produces a scala.scalanative.linker.LinkingError Unresolved dependencies: `#scala.Serializable`