I worked on a commercial project that used Scala. Never again. Compiles were slow, IDE support was terrible, everyone had their own subset they used. I'm sure it's improved since 2010.
I work on a large Scala team. We use microservices so my regular compile times are somewhere between 4s and 20s. I rarely have to do a full rebuild.
IDE support is bad, that's a good criticism but a good chunk of us don't use IDEs, and instead write it like a dynamic language. Live inside the REPL, copy paste back and fourth.
As for 'subsets' everyone uses, I find this advantageous. Our team strongly encourages a pure functional style, but we realize not everyone is going to start out that way, and it doesn't get in the way of shipping software.
I work with some larger Scala codebases too and the compile times are not that bad either. Maybe 30 seconds is more common for the large ones. Certainly not worse than C++, only a bit slower than Java.
>2. Modify your IDE habits to be more REPL friendly
Plenty of people use IDEs, I just think if that's what your main sticking point when picking a language, go with C#. It has the best IDE of any language.
>3. Modify your team coding habits even if it makes it hard for one person to work on the other person's codebase.
Nope, not a problem. I can work on any code base in the company. It's spooky how fast we can jump into others teams projects and contribute, and a lot of that is due to the power of the language.
Also, re: 1...you don't have to use microservices. You just need non-monolithic compilation units. This just means breaking up your application into library code that doesn't need re-compilation.
GF mentioned microservices because they end up forcing this by design, but nowhere does it say "you must use microservices or else get horrible compile times"
But the thing is if you modify your habits, it's so much more efficient than most other languages. It's reasonable to have to learn knew coding style when paradigm-shifting languages. Why isn't it reasonable for there to be other new behaviors as well?
Hah no there aren't. I work in Haskell (one of the few languages that is as or more efficient as Scala) and these things still arise with it. And they're not a problem because you do them and you end up programming better than in a language without these things :)
Scala IDE support is bad? What IDE are you using?
I find IDE support in IDEA almost on par with that of Java. It is very fast, has accurate error highlighting, very good smart autocomplete, understands advanced Scala features, supports most refactoring I care of, but most importantly works reliably.
I've used IntelliJ for Scala some time and did encounter way more IDE bugs than in Java. I think JetBrains did a good job, but Scala is not engineered towards tool support. That is one big flaw of the language.
Kotlin is much more pagmatic (not only) in this regard, what is no surprise coming from a tool vendor.
I also encountered way more IDE bugs in Scala than in Java. Actually during the full last year of development of a real-world commercial Scala project I encountered 0 bugs in Java and 2 bugs in Scala.
What about more objective measures?
Scala plugin issue tracker: 11667 issues.
Kotlin plugin issue tracker: 17664 issues.
And this difference is despite Scala being longer on the market and being more popular than Kotlin.
It looks like Scala IDE support is actually better than that of Kotlin.
How on earth is this an objective measure for plugin quality? There's so much you can interpret into these numbers that they are borderline meaningless.
It is objective measure - it may not be a perfect metric, but definitely objective. If there are more issues relative to the number of programmers this means there are either more bugs, users have more questions, and/or just more feature requests (which means - the plugin is lacking features). Also both plugins share the exactly same bug tracker and the same issue filing process, so you can't argue it is easier to report errors for one over another.
Scalaz, Http4 for web stuff, Netty/scalaz-stream otherwise. We really don't need "frameworks" to be insanely productive in Scala, just a few tried and true libraries. This also really helps when jumping into new projects, there's never "magic" beyond just the features the language provides.
Agreed as far as it goes. But can one person really understand a 2 million line codebase? Can a team large enough to use a 2 million line codebase stay in close enough communication that they all know what each other are doing? IME to stay sane on a codebase that large you need separated components with strict separation between interface and implementation and independent versioning of each, at which point you might as well make that split at the module/VCS level and take advantage of what your tools can do for you.
I think it has changed for good. There are also initiatives to simplify Scala (e.g: dotty), and initiatives to go native (e.g: Scala native via LLVM). I think Scala has some good potential.
IDE support is bad, that's a good criticism but a good chunk of us don't use IDEs, and instead write it like a dynamic language. Live inside the REPL, copy paste back and fourth.
As for 'subsets' everyone uses, I find this advantageous. Our team strongly encourages a pure functional style, but we realize not everyone is going to start out that way, and it doesn't get in the way of shipping software.