5 ms·

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 do

by 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.
- idobai 10y ago
  > Go, Java, Clojure, C#, Python (PyPy), Haskell? In my experience, only C++ and Scala make compilation so slow that users bother about it. Haskell for faster compilation? No. Its compilation time is volatile but it used to be slower. And for java - `mvn clean install` vs `compile`.
kahnpro 10y ago
I used the language professionally for 2.5 years and I have to agree with the parent comment. We weren't doing anything overly complex in Play and once in a while we would come across types that IDEA wouldn't inspect. Even worse, IDEA highlights a section of code as an error, even though it compiles fine with SBT. SBT is fine if you're not doing anything complicated. But the moment we tried looking into building a plugin, even just to add a step in the asset compilation pipeline, it's a land of mystery. Instead of wasting time trying to decipher SBT plugins, we just used npm for our front-end assets. I also found working with Java libraries to be overly frustrating. We generally ended up having to write Scala wrappers around Java libraries in order to give ourselves an idiomatic interface. I will grant you that compilation time is usually exaggerated. Incremental compilation means you normally only wait a few seconds at a time. Now I do a lot of work in Haskell and find compilation significantly faster.
allengeorge 10y ago
We definitely don't use any crazy Scala libraries; neither shapeless or scalaz are allowed in the codebase, and there's a strong bias towards pragmatism in the company. That said, I've definitely had code that IDEA just barfs on - especially for-comprehensions. You may not want to use libraries, but that's not always feasible. I definitely don't want to write my own DB library, or FTP library, or logging or... and, if you have to do that, you'll find that the Scala options aren't easy to reason about. For example, I had to look inside the slick codebase recently and I found it...obtuse. OTOH, I've looked into a number of Java and C DB libraries and found them way more straightforward. This is my biggest frustration about Scala: that the community appears to stress "neat" and "cool tricks" over pragmatism. This IMO, makes it a bad choice as a language for a startup.
photon_off 10y ago
This is the typical Scala apologists' reply. It's not a problem with Scala, it's a problem with you. When it takes several dense paragraphs to explain simple problems, it means that problem is not solved easily. For some programmers easiness is very important -- this seems like something Scala supporters refuse to understand.
- merb 10y ago
  It's still wrong. Actually he said > I appreciate the concision and the strong collections API Everybody who said that, didn't worked with it. The Collections API is the Weak Point of Scala. You ever tried to make your own? Fine work with CanBuildFrom Blabla stuff. It's nearly impossible to understand it. And IntelliJ made a real progress in the last years. I mean sometimes IntelliJ fucked up pretty badly. SAM support is one example it messed scalac's "-experimental". But as already said even Java didn't worked correctly all the time. When you work with a lot of generics you stumble across some types that just won't work in IntelliJ but compile. And types that won't work in Scala, I've seen them, but mostly that was a problem of the Library. And another thing. If you don't upgrade IntelliJ you will mostly won't get bug fixes for the Scala Plugin. I've started with IntelliJ 12 and from that point I always needed to upgrade the whole IDE when there was a new version since they didn't backport most bugfixes. And when you use a lot of Macro's the implementation of them definitly has some non introspectable code. And as said if you did them wrong their usage will be red, too.

by merb 10y ago

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.

idobai 10y ago
> Go, Java, Clojure, C#, Python (PyPy), Haskell? In my experience, only C++ and Scala make compilation so slow that users bother about it. Haskell for faster compilation? No. Its compilation time is volatile but it used to be slower. And for java - `mvn clean install` vs `compile`.

kahnpro 10y ago

I used the language professionally for 2.5 years and I have to agree with the parent comment. We weren't doing anything overly complex in Play and once in a while we would come across types that IDEA wouldn't inspect. Even worse, IDEA highlights a section of code as an error, even though it compiles fine with SBT. SBT is fine if you're not doing anything complicated. But the moment we tried looking into building a plugin, even just to add a step in the asset compilation pipeline, it's a land of mystery. Instead of wasting time trying to decipher SBT plugins, we just used npm for our front-end assets. I also found working with Java libraries to be overly frustrating. We generally ended up having to write Scala wrappers around Java libraries in order to give ourselves an idiomatic interface. I will grant you that compilation time is usually exaggerated. Incremental compilation means you normally only wait a few seconds at a time. Now I do a lot of work in Haskell and find compilation significantly faster.

allengeorge 10y ago

We definitely don't use any crazy Scala libraries; neither shapeless or scalaz are allowed in the codebase, and there's a strong bias towards pragmatism in the company. That said, I've definitely had code that IDEA just barfs on - especially for-comprehensions. You may not want to use libraries, but that's not always feasible. I definitely don't want to write my own DB library, or FTP library, or logging or... and, if you have to do that, you'll find that the Scala options aren't easy to reason about. For example, I had to look inside the slick codebase recently and I found it...obtuse. OTOH, I've looked into a number of Java and C DB libraries and found them way more straightforward. This is my biggest frustration about Scala: that the community appears to stress "neat" and "cool tricks" over pragmatism. This IMO, makes it a bad choice as a language for a startup.

photon_off 10y ago

This is the typical Scala apologists' reply. It's not a problem with Scala, it's a problem with you. When it takes several dense paragraphs to explain simple problems, it means that problem is not solved easily. For some programmers easiness is very important -- this seems like something Scala supporters refuse to understand.

merb 10y ago
It's still wrong. Actually he said > I appreciate the concision and the strong collections API Everybody who said that, didn't worked with it. The Collections API is the Weak Point of Scala. You ever tried to make your own? Fine work with CanBuildFrom Blabla stuff. It's nearly impossible to understand it. And IntelliJ made a real progress in the last years. I mean sometimes IntelliJ fucked up pretty badly. SAM support is one example it messed scalac's "-experimental". But as already said even Java didn't worked correctly all the time. When you work with a lot of generics you stumble across some types that just won't work in IntelliJ but compile. And types that won't work in Scala, I've seen them, but mostly that was a problem of the Library. And another thing. If you don't upgrade IntelliJ you will mostly won't get bug fixes for the Scala Plugin. I've started with IntelliJ 12 and from that point I always needed to upgrade the whole IDE when there was a new version since they didn't backport most bugfixes. And when you use a lot of Macro's the implementation of them definitly has some non introspectable code. And as said if you did them wrong their usage will be red, too.