3 ms·

I wrote Scala for three years or so professionally and agree with most of your points. A couple of comments though that haven’t been addressed by the sibling co

I wrote Scala for three years or so professionally and agree with most of your points. A couple of comments though that haven’t been addressed by the sibling commenter who also addressed some of your points: - JVM is JVM I guess. You either love it or you don’t. I personally really enjoyed the access to the ecosystem so that was a major boon for me. - Gradle is just so much better than SBT in almost every way aside from simplicity. I found building Scala projects with Gradle to be quite straightforward and nearly every project that supports SBT also supports Gradle. - I agree about VSCode tooling but I do want to establish that there are actually really nice tools for writing code in Scala - specifically Jetbrains is quite great. I am not saying your point is any less worthwhile, only that I don’t want someone to read your comment and take away that there are no good code assistance tools for writing Scala. - Agree with the Java NPE’s. This is annoying - Entirely agree with implicits. The Scala team either needs to better educate people on how to use them or just tell people not to use them unless it’s a very specific circumstance. I cannot tell you how many times I’ve dived into someone else’s code and spent literally hours trying to coax the compiler to do something that was bizarrely prevented by a poorly thought out usage of implicits. - it is definitely possible to write “Scava”, and I wouldn’t really recommend a team adopting it without someone having at least a decent background in functional programming. Otherwise you might as well write Java if you are going to write imperatively. - Yes, I find that the usage of symbols in Scala is a bit excessive, but once you learn what they do it does feel more terse and concise. It doesn’t stray into the illegibility of Perl IMO. Overall it’s a nice language, fun to write in, but a bit frustrating at times. I wouldn’t use it personally at home but it does fill a nice niche professionally and it’s absolutely great for writing Spark code.

tasuki 6y ago
We have recently switched from SBT to Gradle and I'm finding Gradle a lot more painful than SBT. For starters, SBT had a nice interactive shell, while Gradle takes quarter minute just to list the available tasks, after which it's another quarter minute to get anything else done...
- SOLAR_FIELDS 6y ago
  Gradle is undoubtedly slower. However it’s at least 10x more capable of doing various things around building your app like testing, building images, publishing, etc. Like if I needed to build, fat jar, test and publish a multiproject repository I would almost certainly want to use Gradle over SBT. But Gradle is probably a bit overkill for a single entry point small app that does one thing and has minimal testing needs (though it can certainly do that!). You wouldn’t bring in a dump truck whenever a pickup would work just fine.
Fiahil 6y ago
> Gradle is just so much better than SBT in almost every way aside from simplicity. I picking this up, because it was also mentioned in a sibling comment. Let's continue this discussion. It doesn't matter if we have multiple alternative to SBT, some more usable than other. Rust has one package manager (+build tool +distribution tool): Cargo. That's it. Whatever the project you just cloned and whatever the platform you're using, `cargo build` is going to compile it. Now, if every Scala project starts using a different package manager, that's going to be a problem. The best solution would have been to make SBT usable without a prescription from your doctor. It didn't happen. That's okay, programming languages are just tools anyway, and they get replaced too.
- SOLAR_FIELDS 6y ago
  The canonicalization does happen with Gradle like with Rust, only at a higher (JVM) level. If you work somewhere that has Java, Groovy, Scala and Clojure projects being able to canonically clone any of them and build them with ./gradlew clean build is amazing. That forces your org to completely adopt Gradle but that’s not terribly difficult for a technically minded leader to enforce. Of course, that only applies in certain circumstances, and as you imply using the right tool for the job is the most important thing.

tasuki 6y ago

We have recently switched from SBT to Gradle and I'm finding Gradle a lot more painful than SBT. For starters, SBT had a nice interactive shell, while Gradle takes quarter minute just to list the available tasks, after which it's another quarter minute to get anything else done...

SOLAR_FIELDS 6y ago
Gradle is undoubtedly slower. However it’s at least 10x more capable of doing various things around building your app like testing, building images, publishing, etc. Like if I needed to build, fat jar, test and publish a multiproject repository I would almost certainly want to use Gradle over SBT. But Gradle is probably a bit overkill for a single entry point small app that does one thing and has minimal testing needs (though it can certainly do that!). You wouldn’t bring in a dump truck whenever a pickup would work just fine.

Fiahil 6y ago

> Gradle is just so much better than SBT in almost every way aside from simplicity. I picking this up, because it was also mentioned in a sibling comment. Let's continue this discussion. It doesn't matter if we have multiple alternative to SBT, some more usable than other. Rust has one package manager (+build tool +distribution tool): Cargo. That's it. Whatever the project you just cloned and whatever the platform you're using, `cargo build` is going to compile it. Now, if every Scala project starts using a different package manager, that's going to be a problem. The best solution would have been to make SBT usable without a prescription from your doctor. It didn't happen. That's okay, programming languages are just tools anyway, and they get replaced too.

SOLAR_FIELDS 6y ago
The canonicalization does happen with Gradle like with Rust, only at a higher (JVM) level. If you work somewhere that has Java, Groovy, Scala and Clojure projects being able to canonically clone any of them and build them with ./gradlew clean build is amazing. That forces your org to completely adopt Gradle but that’s not terribly difficult for a technically minded leader to enforce. Of course, that only applies in certain circumstances, and as you imply using the right tool for the job is the most important thing.