https://trends.google.com/trends/explore?geo=US&q=%2Fm%2F091...

(Scala wins by a large margin!)

Awhile ago I chose Scala for a multi-year side project. I love writing Scala. I think the Scala community is quietly productive and mostly talks to themselves.

I'm not a Scala expert by any means, but I have have been programming for awhile and appreciate the power and terseness that comes out of my Scala code. It feels like I have more time to design well because I needn't write so much code :P.

Going to attempt a good/bad/ugly for Scala...

Good: - Scala ecosystem very much under active development. Scala 3.0, compilation speed improvements, popular libraries updated regularly, IDE integration (VSC is recommended right now I think) - Powerful. Scala's type system is relatively advanced. If used properly I think this can reduce bugs and cost of maintenance and new features. - Fast and portable. jvm!

Bad: - Scala's relatively slow compilation reduces cycle time, but I find often this is mitigated by confidence in the code I'm writing, so I don't often need to stop and run it to ensure correctness. - Very high learning curve to wield the power effectively. Scala is an ecosystem that demands commitment. For example, sometimes I feel like I'm missing the requisite PhD to get the sbt build tool working properly.

Ugly: - Due to Scala's power and high learning curve, a few failure modes may occur that make Scala impractical for many real-world software teams: Scala/functional experts can write a "Russian doll" of abstractions that's hard for someone less experienced to decipher, code review, or maintain; new team members who are also new to Scala/functional may have to ramp up with both business/codebase and functional concepts; and Scala gives you so many different "ways" to solve the same problem that code styles may diverge even in a small team, increasing cost and risk.

Overall I really love Scala, am looking forward to Scala 3.0, and intend to use it for many years, especially for projects with small, experienced teams where Scala's power and learning curve is an asset and not a liability.

I’m forced to use sbt and I don’t like it. And from my reading of my Scala book, the scala compiler is running in some kind of daemon or server instead of a stand-alone compile?

I hate it when so much stuff happens in the background and you can’t figure out what it is.

You don't have to use SBT. Maven works fine with Scala and is quite mainstream.

The scala compiler is stand-alone, all deamon/server implementations are just workaround to speed up build for any build systems other than sbt.

https://trends.google.com/trends/explore?geo=US&q=%2Fm%2F091...

I'd like to learn Scala too. At the moment it's definitely not as prevalent as other languages, but it's higher than emerging languages, which I think was @spir's goal.

I didn't add this to invalidate the parent comment; just to add another view.

Big wins were being able to leverage the much larger ecosystem, and containerization.

We played with Scala but it didn’t work for our team, the expressivity is a two edged sword. Runtime is absolutely fine though it was all about complexity, and poor developer tooling. And since we are in a smaller market, not SV, sticking to platforms where we can find hires was probably a better call for our company.

Scala also forces you to think differently.

Independent of the question around Scala: If you want to get into the JVM ecosystem, you should also be able to understand and write Java. Some dependencies will not be available natively in a secondary language like Scala. And it will also give a better understanding about the limitations of the underlying platform.

It opens our mind to new ways to architecture our software.

I specifically optimize the limited amount of free time I have to devote to career self improvement to what is going to help me be more competitive in the job market.

On top of that, if there is a standard way to structure a program in a given language, you’re not doing future developers and maintainers any favors by not following the paradigms of that language or “you can write COBOL in any language”.

When I’m writing on Python, I try to do things in the “Pythonic” way. The same with JS or C#.

async/await only came to it after the success it had on .NET.

So one could have toyed with async/await in C#, and now already understand some best practices to apply in Python.

Or read the Osaki's book on persistent data structures and implement similar ones in a Python library for concurrent code in Python.

Or maybe one has spent a couple of days learning about OCaml and Haskell, and is in a better position to understand how to make better use of list and generator comprehensions or itertools package.

Of course one also has the choice of only eating what is on the plate, without understanding the variations that the same ingredients allow for.

I already have a two to three year agenda to improve up the stack ($cool_kids_front_end framework of the week), down the stack (AWS cloud infrastructure from a developer, infrastructure, devops viewpoint), more breadth at certain levels (get better at Python, big data, ElasticSearch and Kibana) and staying fluent when it comes to architecture (scalability, high availability, security, etc). Why would I take the time that doesn’t help in that goal?

I don’t need to be an expert in all of those areas, but I at least need to be good at some, average at some, and be conversant in other areas to at least know the what if I don’t know the how to be able to command higher than market salaries as either “adult supervision” at smaller companies or an overpriced consultant - and I am not talking about Silicon Valley/West coast salaries.

I wouldn’t expect them to let me spend time on the clock to learn Haskell or Rust when we are a C#/JavaScript/Python shop or to learn the ins and outs of Azure since we are an AWS shop.

So lets not generalize if it is a waste of time to the OP to learn Scala.

Besides if you already a .Net developer, you’re probably already using JetBrains R#. They are behind Kotlin and the best IDE for it.

I’m also not a Java fan for a lot of reasons but the syntax of Java is not that far from C# that I could see liking one and hating the other.

If you want to improve your own thought process rather than your skill in just one programming language, then clojure(script) would be a better choice. Once you've been through the learning and practice curve, the benefits of having decomplected your mind will spill to other languages.

More importantly, why do you want to branch into Java specifically? Is there a company/job you have your eye on? Or do you want to get into web dev backend?

Because there are so many, many languages/technologies out there, asking "should I learn X?", the answer is always "if you like it or it'll get you a job you want, yes"

- Functional Programming in Scala

- Akka In Action

You may want to check out F# if you're looking for a .Net functional language. Or try out Haskell.

In regards to new projects, I do believe people are using it for new stuff. Both Spark and Akka are very powerful libraries that have little parallel in other languages.

Imo, Scala is the most advanced language on the jvm, far outclassing Kotlin, Clojure, and Java in terms of expressiveness.

I would recommend learning it and playing around with Spark. I think the combination is very employable.

Also, Scala is so much fun! I love it!

Exactly why I don’t want any new scala code on my team. We don’t need engineers spending three days arguing about pedantic differences in the language because something can be done 8 different ways. And who wants to maintain something in scala that they didn’t write? It’s a nightmare.

The problem is when you have a Java guy on the team who writes crap OO code. That’s when it becomes impossible to reason about. We had a rule on my last scala dev team that if you wanted to use a var or a structure from collection.mutable, you had to give a presentation on why it was necessary.

When to choose what? Probably leave the choice to library-implementors mostly. Still, should the bar to implement a library be set so high? The middle ground seems to be what e.g. Rust is doing. No explicit categorical types, use functions where functions make sense, i.e. for most stuff that isn't I/O.

But there is a big benefit to using these category structure: you don’t have to think as hard about the underlying implementation because you know it must obey certain laws. Also category theory interfaces tend to be pretty simple and easy to learn: most of are defined by a couple functions and a couple laws.

Everyone knows how to map or flatMap, and that’s really all you need in a lot of code!

I do, just joined a Scala team and i am maintaining multiple services and writing my own.