Hacker News Reader

Comment by icedchai | Hacker News Reader

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.

View on HN

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.

You might have actually convinced people to not consider Scala. You are saying, Scala is great, except for these small things:

1. Modify your codebase to use microservices

2. Modify your IDE habits to be more REPL friendly

3. Modify your team coding habits even if it makes it hard for one person to work on the other person's codebase.

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?

Because there are other languages, which also provide the benefits, but without these downsides.

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 :)

Which ones?

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.

This was back in 2010-2011, so I am sure it has improved 6 years later.

Back then, most of the team was using Eclipse, which was awful! IntelliJ's support was better, even then... but still sluggish.

IDE support with IntelliJ IDEA is now excellent, on par with Java and Kotlin. Everything just works, including automated refactoring and extractions.

> We use microservices so my regular compile times are somewhere between 4s and 20s.

What framework or library are you using to write said services?

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.

Two million line scala codebase -> 2 hour clean and rebuild with a top of the line workstation. IDE support has improved, compile times not so much.

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.

Reply on news.ycombinator.com