15 ms·

I wouldn't use it again. While I appreciate the concision and the strong collections API I'm not pleased with the ecosystem: * Neither IDEA or Eclipse are pa

I wouldn't use it again. While I appreciate the concision and the strong collections API I'm not pleased with the ecosystem: * Neither IDEA or Eclipse are particularly great (I routinely get types that can't be introspected, and both require inordinate amounts of RAM to work well) * SBT is a productivity sink to do anything beyond the basics with * The compiler is slow (and yes, it does matter) * The compiler's error messages are poor * I find the code in many Scala libraries impenetrable (which matters a lot while debugging). Moreover, I notice a lot of "WTF" moments with the language. Often, this means that the effect of the code you're looking at isn't always obvious. The unexpected side-effects and the library situation frustrates me the most: I feel like I'm always dealing with "code in progress" written by people who're enamored with the features Scala provides over building something robust and easy to understand. Obviously, my opinion. There are plenty of people out there who love Scala.

cheshire_cat 10y ago
have you had prior experiences with other functional programming languages?
- allengeorge 10y ago
  Yes I have - some Haskell, which I found substantially less frustrating. And, I've been using Scala for a year and a half now, so, long enough to get over the initial pain.
idobai 10y ago
> Neither IDEA or Eclipse are particularly great (I routinely get types that can't be introspected, and both require inordinate amounts of RAM to work well) If you don't use an IDE than you don't know what you're missing 'for the sake of RAM'. > The compiler is slow (and yes, it does matter) Worth to note that with SBT you won't need `mvn clean install` at every compilation and it only recompiles the source which has changed. At the end, the compilation time won't be worse except at the first. > SBT is a productivity sink to do anything beyond the basics with What is your problem with SBT? What are the missing features? > The compiler's error messages are poor They're far more descriptive than in java - what are you expecting? Can you provide a sample? > I find the code in many Scala libraries impenetrable (which matters a lot while debugging) I think you need to learn the basic syntax of the language first before debugging anything, right?
merb 10y ago
Don't get me wrong I use Scala on my Day to Day job, but some of your things are just wrong. I.e when you get types that can't be introspected you definitly don't work with simple scala. I've been playing around with really big projects and even made some contributions to the Playframework project: (https://github.com/playframework/playframework https://github.com/playframework/playframework) and even that has barly/no types that won't work. (Oh while working on Multipart I had Java Code that didn't worked on IntelliJ 15 (works in 2016.X now)). I know there are certain libraries that are akward to work with in any ide but these libraries should be avoided. And they are mostly based on scalaz and I would even consider specs2 as harmful. But nothing applies to scalatest its imo way faster. While you see SBT as a productivity sink you can stick to gradle or maven, both are supporting Scala. Still even the slowness of sbt (which isn't so slow it just needs to do everything twice in IntelliJ when you use it inside the console and your ide) isn't so bad for me since it's really simple to make AutoPlugins (this isn't so simple in Maven/Gradle) What error message is poor for you? I barly had issues with them. My issue's were more some stack traces but on Java the same stack traces annoyed me aswell but that was on runtime crashes. Actually its true that some libraries are akward. But my ruling for libraries is anyway: use as few as possible. You prolly don't need a library for leftpad but that applies to all libraries I even was on the golang Ecosystem for a while predates even the 1.0 dates I even have a book for ~0.7 and there were some libraries that were pretty akward and messy, things evolved but there are still some code around which you shouldn't barly touch and even for http, you prolly don't need a library for most of your stuff and still people use them. P.S.: Nothing against the compiler slowness but from day-to-day you barly notices only a sbt clean compile could be slow but our app (which is quite big these days only takes a few seconds). Even play! compiles fast on my machine: sbt clean compile // ommitted everything in between [success] Total time: 95 s, completed 04.06.2016 23:54:53 Which isn't the compile time its the time the whole command i.e. clean + compile took. And I wouldn't consider that "slow". I mean slower than what? Go, of course. But its the only language that compiles so fast. Also Scala 2.12 will likely bring some improvements (soon tm).
- ffriend 10y ago
  > But my ruling for libraries is anyway: use as few as possible. And this is the point - if you want to be productive, you have to use _may_ libraries. Unfortunately, Scala's way is not to carry about compatibility, making it extremely hard to grow up large projects with a lot of dependencies. For example, we heavily use Apache Spark which targets Scala 2.10, but this makes impossible to plug in many libraries that only support Scala 2.11. The same applies to library dependencies: just yesterday we had to introduce a number of exclude rules into SBT file to reconcile Spark and HBase, because SBT was failing with cryptic messages. > I mean slower than what? Go, Java, Clojure, C#, Python (PyPy), Haskell? In my experience, only C++ and Scala make compilation so slow that users bother about it.
kahnpro 10y ago
I worked with Scala at my job for 2.5 years. In brief, if you really want (or need) to be on the JVM, then use Scala. It's everything that Java should have been, and after you get comfortable in Scala, you will never want to write a line of Java again. However I have to agree with many of the common criticisms. My last team had many WTF moments with the language. We also suffered from poor type inspection and IDE support, failed attempts at writing an SBT plugin, and slow compilation. Having access to Maven repos is great, but using Java libraries is often a frustrating experience where you end up having to write a whole wrapper library around the Java lib just to work with something idiomatic. The language is a great stepping stone to bring hardcore Java devs into the world of FP, but honestly, if you don't need the JVM, I would rather be using Haskell.
sportanova 10y ago
Surprisingly, reading and understanding haskell libraries is much easier than scala libraries

cheshire_cat 10y ago

have you had prior experiences with other functional programming languages?

allengeorge 10y ago
Yes I have - some Haskell, which I found substantially less frustrating. And, I've been using Scala for a year and a half now, so, long enough to get over the initial pain.

idobai 10y ago

> Neither IDEA or Eclipse are particularly great (I routinely get types that can't be introspected, and both require inordinate amounts of RAM to work well) If you don't use an IDE than you don't know what you're missing 'for the sake of RAM'. > The compiler is slow (and yes, it does matter) Worth to note that with SBT you won't need `mvn clean install` at every compilation and it only recompiles the source which has changed. At the end, the compilation time won't be worse except at the first. > SBT is a productivity sink to do anything beyond the basics with What is your problem with SBT? What are the missing features? > The compiler's error messages are poor They're far more descriptive than in java - what are you expecting? Can you provide a sample? > I find the code in many Scala libraries impenetrable (which matters a lot while debugging) I think you need to learn the basic syntax of the language first before debugging anything, right?

merb 10y ago

Don't get me wrong I use Scala on my Day to Day job, but some of your things are just wrong. I.e when you get types that can't be introspected you definitly don't work with simple scala. I've been playing around with really big projects and even made some contributions to the Playframework project: (https://github.com/playframework/playframework https://github.com/playframework/playframework) and even that has barly/no types that won't work. (Oh while working on Multipart I had Java Code that didn't worked on IntelliJ 15 (works in 2016.X now)). I know there are certain libraries that are akward to work with in any ide but these libraries should be avoided. And they are mostly based on scalaz and I would even consider specs2 as harmful. But nothing applies to scalatest its imo way faster. While you see SBT as a productivity sink you can stick to gradle or maven, both are supporting Scala. Still even the slowness of sbt (which isn't so slow it just needs to do everything twice in IntelliJ when you use it inside the console and your ide) isn't so bad for me since it's really simple to make AutoPlugins (this isn't so simple in Maven/Gradle) What error message is poor for you? I barly had issues with them. My issue's were more some stack traces but on Java the same stack traces annoyed me aswell but that was on runtime crashes. Actually its true that some libraries are akward. But my ruling for libraries is anyway: use as few as possible. You prolly don't need a library for leftpad but that applies to all libraries I even was on the golang Ecosystem for a while predates even the 1.0 dates I even have a book for ~0.7 and there were some libraries that were pretty akward and messy, things evolved but there are still some code around which you shouldn't barly touch and even for http, you prolly don't need a library for most of your stuff and still people use them. P.S.: Nothing against the compiler slowness but from day-to-day you barly notices only a sbt clean compile could be slow but our app (which is quite big these days only takes a few seconds). Even play! compiles fast on my machine: sbt clean compile // ommitted everything in between [success] Total time: 95 s, completed 04.06.2016 23:54:53 Which isn't the compile time its the time the whole command i.e. clean + compile took. And I wouldn't consider that "slow". I mean slower than what? Go, of course. But its the only language that compiles so fast. Also Scala 2.12 will likely bring some improvements (soon tm).

ffriend 10y ago
> But my ruling for libraries is anyway: use as few as possible. And this is the point - if you want to be productive, you have to use _may_ libraries. Unfortunately, Scala's way is not to carry about compatibility, making it extremely hard to grow up large projects with a lot of dependencies. For example, we heavily use Apache Spark which targets Scala 2.10, but this makes impossible to plug in many libraries that only support Scala 2.11. The same applies to library dependencies: just yesterday we had to introduce a number of exclude rules into SBT file to reconcile Spark and HBase, because SBT was failing with cryptic messages. > I mean slower than what? Go, Java, Clojure, C#, Python (PyPy), Haskell? In my experience, only C++ and Scala make compilation so slow that users bother about it.

kahnpro 10y ago

I worked with Scala at my job for 2.5 years. In brief, if you really want (or need) to be on the JVM, then use Scala. It's everything that Java should have been, and after you get comfortable in Scala, you will never want to write a line of Java again. However I have to agree with many of the common criticisms. My last team had many WTF moments with the language. We also suffered from poor type inspection and IDE support, failed attempts at writing an SBT plugin, and slow compilation. Having access to Maven repos is great, but using Java libraries is often a frustrating experience where you end up having to write a whole wrapper library around the Java lib just to work with something idiomatic. The language is a great stepping stone to bring hardcore Java devs into the world of FP, but honestly, if you don't need the JVM, I would rather be using Haskell.

sportanova 10y ago

Surprisingly, reading and understanding haskell libraries is much easier than scala libraries