I love scala, and am very much looking forward to scala 3.
For all the complaints about the language that always pop up in these threads: yes, the language lets you shoot yourself in the foot (with great power comes people who don’t apply it responsibly), but it’s precisely that power that makes it so useful and exceptional when judiciously applied.
I like to say that scala is as if java and ruby had a love child and it all worked out. Unfortunately, that does mean that java people will feel it’s too fast & loose, and the ruby people will feel stymied by its static typing. But I just love that where other statically typed languages generally say “no”, scala says “well, I trust you know what you’re doing...”.
The only substantive tool complaint I have these days isn’t with compiler speed - it chugs through the codebase plenty fast - but with tool startup time. Hopefully the more recent java versions and maybe some native packaging will eventually help with that.
I appreciate you taking the courage to share your honest thoughts despite how they may conflict with the views of others here. My heart goes out to the people I overhear at work, the ones who are struggling the most, lamenting and complaining that tool X (In this case scala) is “so” embarrassingly awful and, with the implication that it’s to blame for their poor performance. That sentiment resembles some of the comments that I’ve written here and my heart really bleeds for them, because I know these people at work and I know that they’re struggling and I also know that they’re good, smart people, who have just fell into a trap of justification.
For what it’s worth, in my own journey learning Scala, I simply didn’t have the luxury to blame, and I just forced myself to try and figure out how other people, like the finagle team for example, could be so productive with such an obviously newfangled invention, until I realized… I was wrong.
Scala is actually a wonderful language! People move companies to continue working in Scala! In fact the ideas and lessons that I’ve learned from rethinking how I used to do things are so unfathomably valuable to me that I don’t think I will ever look at code the same way again.
And before you downvote me please don’t mistake my words for criticism. I truly empathize with how some of the people here may feel and I’m very happy to go into specifics if anyone requests that. I don’t write on HN a lot because a lot of times I think there is just this therapy - or a version of therapy - that amounts to people reinforcing their need to blame things in order to continue excusing the poor performance, and I don’t want to get caught up in it or be made to feel bad for encouraging others to reconsider their virtues.
And by the way we all, at times, have poor performance. (Anyway, I dictated this into my phone, so also excuse any weird words or punctuation. I love you all. Some typos were subsequently edited)
Not every language has to be for every person. It's perfectly fine that people enjoy Scala. I think a lot of the negativity about Scala is because lots of companies went in hard on Scala less because of the merits of Scala, and more because Java had such a long period of stagnation.
> My heart goes out to the people I overhear at work, the ones who are struggling the most, lamenting and complaining that tool X (In this case scala) is “so” embarrassingly awful and, with the implication that it’s to blame
Yah, I have noticed lately a division between two types of programmers.
The first is the "infrastructure oriented" programmer. They assume that the rank and file programmers will be expected to write bad code. They look at problems in the codebase as a sign that there is a missing piece of infrastructure. They 1) wait for the pain level to get high enough on the team, 2) identify a class of problems that is not getting solved well, 3) install or implement a new service/middleware/library that solves that class of problem elegantly, and 4) port all of the crappy code over to the new reality.
The second is the "pattern oriented" programmer. They assume that sloppy code will create areas of rot around it that become cost centers, and that "low hanging fruit" cleanup tasks will generally pay for themselves. When there are problems in the codebase, they go back and refactor. They advocate for team discussions of patterns, establish precedent for the team to follow, and expect other members of the team to learn and apply those patterns correctly.
I'm not really sure whether these two types of programmers should work together. Each group's primary assumption:
1) Programmers will inevitably do sloppy things, and'
2) "Low-hanging cleanup" pays for itself
... is correct in practice. The problem is they are somewhat at odds in terms of pointing to a high level strategy.
If you are committed to ripping out and replacing large parts of the codebase when they become unworkable, there's not really any point to trying to keep up with tidying.
And if you tidy, you won't really need to rip out large parts of the codebase.
So maybe we should just each try to find a team that fits with our values, rather than argue about it.
Kotlin is more like if Java and Python had a love child. It's clean, simple, quick to pick up, and pretty much retains the behavior of the underlying language.
The way I look at modern Scala is a mix of Python and Java.
Do it badly, and you end up with the unmaintainability of Python and the clunkiness of Java. Awful.
Do it well, and you end up with the convenience and interactivity of Python and the typesafety, performance, and toolability of Java.
This lets you implement your code quickly the first time, and have it run blazing fast on a hot JVM, with the compiler having your back as you grow your codebase in size and complexity. Sure beats trying to prototype in Java, or porting half your Python prototype to C when you realize it’s too slow.
Scala has a bad reputation, well-earned due to an early culture of crazy experiments, crazy operators, and crazy tools. But those days are behind us.
You can no longer get stuff into the standard library “just because”, and a lot of the early experiments in that category (xml, parallel collections, parser combinators) has been consciously moved out.
Operator-heavy tools like SBT have largely replaced the crazy operators, while operator-heavy libraries like Dispatch have been largely replaced by less-operator-heavy equivalents.
SBT used to be awful, but it’s improved a lot. And you don’t need to use it: I haven’t touched an SBT build in years by now, in both OSS and proprietary contexts.
There remains a lot of different ways to write Scala, more than most languages, but you don’t need to write Haskell-in-Scala unless you really want to.
I’m personally very happy with my Python-like language with Python-like libraries, with static typing for maintainability, orders of magnitude better runtime performance, excellent parallelism and concurrency, one of the best compile-to-JS experiences in the world, and the best tooling (IDEs, profilers, monitoring, etc.) on the market.
As someone who maintains optimized programming language interpreters, distributed backend clusters, three-tier web apps, command-line tools, and many other things on a daily basis, I appreciate being able to do all this in one language rather than juggling 5 different languages (and 5 different sets of libraries, and 5 different sets of tools, ...) to satisfy each use case.
Scala may be diverse and fragmented, but it’s not as diverse or fragmented as the polyglot Python/Ruby/C/Go/Javascript codebase it would likely take to replace Scala for my daily work
That's about my experience. The language is maturing very well and the library ecosystem is just amazing. (Looking at you, lihaoyi!).
I really appreciate that I can walk the full gradient from immutable-functional to impure-imperative with one language, depending on the context and the requirements. It takes some discipline for a team (code reviews, regular feedback, discussion on approaches) but I'd say that's true for any language to some degree.
Then there is the ecosystem that's getting better and better with every year, with more and more libraries building on and onto each other.
SBT has been a sore point in the past, that has been ameliorated quite a bit in the past three years. SBT 1.3.x together with GraalVM native is a game changer! And then there are lots of other build tools that less ambitious and more approachable than SBT, if SBT simply isn't your cuppa.
Scala.js is also quite amazing. Scala is definitively underrated in that area. Being able to stay in one tool for a full stack application and being able to shift code seamlessly up and down the stack, depending on the current requirements has been an eye opener for me.
Biggest Scala pros
- Terse expressive syntax with a strong type system
- Welcoming community and creators
- Amazing libraries and rich ecosystem
- World-class tooling!
I the future I hope that Odersky and the core team will continue to identify "implicits" use cases and provide dedicated syntax for them, just like they did with extension methods in Scala 3.
> Scala.js and Scala Native will support Scala 3 eventually.
I'm looking forward to it! Now that the Dotty experiments come to an end and development of the Scala language shifts away from Scala 2.x to Scala 3 I think this becomes feasible!
> I’m personally very happy with my Python-like language with Python-like libraries, with static typing for maintainability, orders of magnitude better runtime performance, excellent parallelism and concurrency, one of the best compile-to-JS experiences in the world, and the best tooling (IDEs, profilers, monitoring, etc.) on the market.
Hey lihaoyi, completely agree with you on this. (Coming from someone who recently stopped writing scala).
That said, in my opinion, if you got to write “python-like scala” with static typing and hof on a regular basis, you should count yourself as one of the lucky ones. In the context of a diverse team, with interests and experiences ranging from Java to Js to python To all the way to Idris, how would you reconcile how different team members want to write Scala?
What I’ve seen this lead to is just because you understand one portion of the codebase, doesn’t mean you can understand another one (both on similar levels of domain complexity), and just because intellij works great on one module, doesn’t mean it’s going to work at all in another one.
EDIT: and I have to say, I love your contributions to Scala library ecosystem, and have used many of them. :) they really do reflect the simplicity of python-like scala.
I’d say you deal with it the same as in any other language(s): with consensus, coordination, and code review.
After all, if you are a Go shop, what’s stopping someone implementing their code in Haskell? Or someone in a Python shop deciding they want to use Clojurescript on Node.js for scripting? Or even within a language, if you are a Spring shop and someone wanted to implement their service on WebLogic?
Scala definitely had a culture of crazy experiments and bifurcation in the past, but it’s always been a matter of team culture rather than of the language itself: something that applies to all languages, especially as polyglot codebases become more common
Without Scala, but with the same lack of coordination, quite likely you would end up with 4 separate silos in your polyglot codebase, written in JS, Java, Python, and Haskell/Idris. Would that really be a better state?
use several of your libs in production code for this reason - simple, type safe stuff. perfect example of scala's flexibility. you can write simple/clean stuff in Scala it just takes discipline.
scala is a lot like perl, a powerful tool in the right hands, but gives you more rope to hang yourself if you dont know what youre doing
I often see comparisons to Go, Kotlin, Rust, etc, and I agree that it's unlikely for Scala to have a second renaissance and have an steep upward trajectory like those languages, but is that really a death of a language? I'm actually fine with Scala narrowing its scope and focus at being really good at just a couple of things. Such as embracing its FP-side more so than its OO-side. Not to say there is no value in its OO-side (I still see some value there mostly pertaining to modules). But I just mean that not every language needs to aim to be a top 5 language. FP and advanced type systems still seems to alienate a significant percentage of programmers for various reasons. That's fine. It's not like that sentiment is going to change overnight.
Scala missed its opportunity with Android. I think you just have to concede that to Kotlin at this point and just focus on moving in a direction that is not occupied. Which is why I mention FP with a strong focus on types. There's not much competition there besides Haskell. And since Haskell for the JVM will likely never be a thing (a few have tried, but none have gained traction), Scala is still there. And with the direction Scala 3 is going and all the improvements it brings, it's actually looking quite positive. At least in my eyes.
And besides, I don't think Scala has to be a "worse Haskell" in everything that it does. I think ZIO is a good example of a great Scala library that actually resulted in something really special by embracing what Scala can do:
https://zio.dev
I agree with almost everything you're saying. I'll just add that while Scala missed it's opportunity with Android, the big problem has always been a borderline dogmatic approach to pure FP by the community at the cost of simplicity. Scala libraries are generally complex and difficult to use (sometimes even for Scala engineers with several years experience).
Also, core FP principles are not that hard (immutability, expressions, HOF, functional error handling, pattern matching), but when you go full / pure FP, that is a steep cliff and an end goal in itself that has serious time /monetary/ complexity costs. The real goals should always be a healthy balance of reasonably fast business functionality delivery and a good code base.
There is that, yeah. There was a lot of translating things from Haskell to Scala 1:1, and that didn't always work out so well. Well, actually it does mostly work on a technical level, but with heavy costs when it comes to ergonomics. The implicit imports and poor type inference was enough to cause frustration within our team.
That's why I specifically mentioned ZIO. Things improved greatly after migrating to it. It feels like it plays to Scala's strength. It infers well and we don't have a single implicit import to make it work. Well, with the 1 exception of the optional Duration syntax so that we can write "5 seconds" instead of "Duration(5, TimeUnit.SECONDS)".
> But I just mean that not every language needs to aim to be a top 5 language.
I wonder about the extent to which this is true. One of my primary considerations in picking the language for a product is economic fit. Once you get outside of the top 10 or so, I think you need an especially strong set of niche-specific positives to offset the negatives of a small community.
As an example, for fun I've been working on a mobile app using Dart and Flutter. They are clearly targeting the niche of "mobile app developers who want to be cross platform and don't really care about it being a perfect iOS experience". Which is a pretty big niche, and Google has invested a lot in the platform, so I'm enjoying it. But library support is about 10% of what I'd want, so for things where in Python I'd have a few decent packages to pick from, in Flutter I'm often deciding between an under-maintained 0.0.7 and rolling my own.
If I were doing this for real and with funding, this would at least be a risky bet. Maybe we save 20-40% on our mobile dev costs and , maybe we get screwed by Google's fickleness and have to rewrite everything. Does that offset the extra recruiting and ramp-up time costs? Are good mobile devs willing to work in a less marketable language? Will Google dessert-topping-and-floor-wax it to death in service of internal political goals? Etc, etc.
Scala's in a similar bucket for me. I tried it out and liked it well enough. It's certainly reliable; I wrote my home lighting system in it and the only failure I've had in 3+ years was when Kubernetes shat the bed. But I'm of a similar mindset to Eckel on this: when it's good it's good, but it has a lot of cliffs that I found it very easy to stumble over. [1] Add on top of the hiring problems, and I'm wondering in what niches the economic case is strong enough. Especially so if it's going to keep dropping in popularity.
> > But I just mean that not every language needs to aim to be a top 5 language.
> I wonder about the extent to which this is true. One of my primary considerations in picking the language for a product is economic fit. Once you get outside of the top 10 or so, I think you need an especially strong set of niche-specific positives to offset the negatives of a small community.
I think you have to take into account the ecosystem in that equation. Scala may have less than 5%
programmer mindshare but it has access to the massive Java ecosystem underneath. So languages
like that I think get to be viable at a significantly lower threshold than languages that
require the whole ecosystem to be built from the ground up (even if that is mostly by
writing wrappers that FFI to C libraries). The risk is heavily mitigated by that as well,
as a retreat back to Java from Scala is far more doable than from say, Go or Rust
to Java if things turn sour.
Scala is disadvantaged by the fact it philosophically departs from the
Java ecosystem (in terms of FP, HOF, etc), because
that pretty much ruins the interop story backwards into Java (that is, without effort,
your idiomatic Scala code / library is not going to be accessible idiomatically to Java
programmers). This is unlike Kotlin and Groovy both of which are built
intentionally to fit smoothly into the bigger Java ecosystem (although Groovy is more
so than Kotlin).
Good point on the ecosystem. That definitely makes Scala more viable. I know I never would have tried it without that. Although I think that applies more to runtimes and (some) libraries than what I think the real drivers of cost are, like hiring and a community of practice (e.g., forums, mailing lists, and the likelihood of having the SO answer you need in your first few Google hits). And I think there's still a tax there; if you're doing a lot of Java interop you'll still have to know Java and the quirks of dealing with it from Scala.
Of course, there could be special-purpose stuff that's very nice not to have to rewrite. PDF generation comes to mind, as it's an enormous pain in the ass, and there are some good Java libraries for it. But it's often not much more work to encapsulate something like that as a service or a CLI tool.
Not to say people shouldn't do it, of course. But I'm not sure what Scala's niche should be as it shrinks. I originally saw it as a better Java, but I think Kotlin did a better job of is winning there. I get the impression that Clojure is doing better at "functional language on the JVM". Which is already a niche inside the FP niche. And given how much other languages have been learning from functional approaches, I don't know whether that niche is growing. I look forward to seeing if they find one.
Yes, I agree with you, I think it's niche is probably going to shrink away from the "better java" and enterprise space but will probably hold up in the data science space as the only real counterpoint to Python for large scale distributed data processing. For people who for whatever reason want to use the JVM, or who need language performance that can't be achieved with Python, there isn't really anything else in the data science space to compete with it.
The killer problem for me is that you can't write a good library in Scala and have Java users adopt it. Because it uses its own collections etc, unless you build highly non-idiomatic Scala code, you will always end up with a huge impedence mismatch there. So while you can use libraries from java, you can't contribute to them, and your audience is always limited. Contrast with Kotlin or Groovy where you can write idiomatic Java-consumable libraries much more easily (esp. Groovy).
What is the story with Scala on Android? Years ago I thought it was a matter of using too much memory. There’s not much talk about it but it does seem to be possible:
As the person who was involved in Scala on Android (and particular in creating the website), I'll chime in with this:
What sunk Scala on Android was largely the completely lack of interest from the core team.
Everything that Scala on Android achieved was pretty much _despite_ the actions of Scala's upper echelon.
- It's hard to get a good message out, when core members spread FUD by bringing up problems that were solved year ago (like the big std lib issue).
- The core team's perception of Scala was always inward – new platforms existed such that Scala developers could run their code in more places, not because it could attract new developers from these existing ecosystems to Scala.
(Scala.js partially overcame this by herculean efforts of individual members of the Scala.js community that got the word out to the JavaScript world about Scala.js.)
- Core Scala pulled the plug from Android support in the backend. So Scala on Android was pretty much left to die on an outdated Scala version.
- Something like TASTY (an interchange format that can be recompiled on the fly to target new backends), which could have dealt with the problem above – was promised for years, but still hasn't shipped.
- The core team was against even acknowledging the existence of Scala on Android on the website – good luck in convincing that Scala on Android works, if the official website/documentation doesn't mention it with a single word.
- Core Scala treated the main contributor with so much public disrespect, that I'm still surprised he didn't outright quit back then. It takes balls to publicly blame the main contributor of Scala-on-Android for not working on the project full-time, but also conveniently managing not to tell him this crucial "requirement" for half a decade. And with "full-time" I mean "unpaid full-time".
It's a sad story, because Scala-on-Android shipped with some amazing features like hot-code-replacement years before Google managed to ship it. The typed resources stuff was also pretty impressive.
I don't know the whole story. Perhaps somebody who knows can chime in. But my impression is that Android being stuck basically on pre-Java 8 at the time while Scala relying heavily on Java 8 features was one complication. Scala generating a bunch of class files for lambdas and so on with no SAM types + invokedynamic to reduce all that plus strange DEX limitations might have caused issues. Plus memory limitations like you said.
I'm not sure there are any real blockers for Scala on Android anymore. I imagine it's mostly a resource problem now. With Kotlin's momentum in that space though, I'm not sure too many people are calling for it anymore. Who knows though, maybe after Scala 3 is finally out the door priorities could shift.
From a few years ago, with Scala 2, but the fundamentals may not have changed much.
Scala had, and has, a large bespoke standard library, which is big enough that if you tried to ship it with even a trivial app, it exceeded limits not just on memory, but on numbers of classes, methods, and so forth. (And even if those limits have been raised on newer phones, older ones are still a nontrivial market segment.)
So the way people got around that was by using "tree shakers", which would grovel through the app and its libraries, and chuck out portions of the library which weren't actually used. This works, but significantly complicates the development toolchain.
Between that and the official support for Kotlin as the "better Java" dialect of choice, you have to really like Scala to make it worth the effort...
> And since Haskell for the JVM will likely never be a thing (a few have tried, but none have gained traction)
It's more than social reasons. The JVM has technical limitations that ruin idiomatic Haskell. Lack of a mechanism for efficiently and modularly compiling general tail-call elimination.
For instance, if you traverse too long of a list, you'll blow your stack. You can try it and fail yourself with Eta.
FP in Scala has the same issues, but they have some extra utilities to work around it, but it's something you gotta be aware of.
One of the biggest complaints that I've had about Scala is it's community. They've made huge strides to make political statements and gatekeep who contributes. (The core team makes it worse for John De Goes (He's the guy that was either the creator or a big contributer with scalaz and zio) at every turn and it's really annoying)
F# is quite nice. I used it a long time ago for a couple of libraries when I was working in a team that mostly used C#. Fable looks really cool too.
I remember getting the feeling that C# is holding it back though. F# can't have any feature that it wants because interop in both directions seems to be a priority. If I recall correctly, that's what is holding back higher-kinded types in F#.
That, and the last time I tried F# on .NET Core things were still very rough. This was when .NET Core was still fairly new though. It might be fine now.
not as much C# the language, as CLR, the runtime. Because of reified generics, which is the way things are done in the .NET world, and which the runtime needs to support, it would also require explicit support in the runtime for Higher-kinded types or Type classes. And that won't happen without C# having these features (and having them first).
F# is really really great, but it is like an unwanted child of Microsoft :(
When I gave up on Scala in 2016, I did so because its future looked fragmented and uncertain. Fast forward more than three years, and the first release of Scala 3 won’t be out until another year from now. Compare this with the pace of development of Go or Rust: those languages are driven by a vision, and have a dedicated team behind them. Scala is declining because no one could figure out for the longest time what was next and how to work on it.
It’s too bad, as Scala did the most of any language to bring me into the fold of statically typed programming. I miss it sometimes, but then I remember all the times Scala wasted my time, and get back to writing Go like a happy little camper.
Go is just barely statically typed though, with its lack of generics. Some day soon, it will tacked onto the language; a language that wasn't designed with that in mind.
I don't know about pace, but in absolute terms, Go is far behind even the oldest versions of Scala.
That would be missing the point of Go. It’s not as though the Go team is incapable of introducing genetics they just took a hard line on not putting anything into the language that wasn’t absolutely needed. This built a simpler language and because of that a stronger community, which is why Go has all but entirely eaten scalas lunch
I've never found a more sophisticated type system anything but helpful. It's easy for beginners to start, but when you don't have a good type system and you have a complicated project things quickly become a nightmare.
I'll give an example of the Scala type system: let's define combining 2 integers as adding them together, then combining 2 lists of integers will give a new list where an element is the result of combining of 2 elements in the given 2 lists. Now we can make it a bit more generic: if a type A has a method combine, then 2 lists of elements of type A can be combined together to give a new list of which each element is from combining 2 elements in the 2 given lists.
How do you implement it in Go? It can be done in Java with generics, but if I make the problem a little bit more generic, a little bit more complicated, then I don't think Java can do it.
It would depend on how generics are implemented in Go, with the current proposed implementation that would be possible. Without generics today you could use an interface, wouldn't be as pretty but would get the job done.
I've seen nothing but chaos in every org thats adopted it and they all moved to java/kotlin/go, only place I've seen it successful is around Spark. Usage stats back this up
The marketing is very impressive indeed, I won't argue against that. I can only think of Angular 1.0 as an equally impressive feat of advertising (I totally bought into that - for a while).
But logically, what you suggest implies that either generics aren't absolutely needed, and shouldn't be in Go, or it's absolutely needed, and Go has been lacking them for a long time.
I’m sorry, I don’t think you can state absolutes like this with respect to languages.
After 5 years of programming in Scala, professionally, writing and debugging a cli tool in Go-Lang felt like a breath of fresh air. I agree with about go marketing, in that I think the creators of go found a larger “market” of devs and understood them better.
no it just implies the don't willy nilly throw in any feature into the language like Scala, and I am incredibly grateful for it after writing Scala for a couple years, what a mess
Scala tends to be more of a kitchen sink, kind of an academic experiment brought to industry, whereas Go is way too far down the path of having only “absolutely needed” features - they promoted it as a “pragmatic, boring” language to focus on your business and write consistent code. As a result, this approach makes the language less expressive, really boring for many engineers, and also, unfortunately, it brought some bad practices - repetitions, error handling from last century, etc.
Languages are in a big part matter of tastes, and it does not make sense to criticize their chosen approaches beyond objective technical merits for your tasks.
Sure there are use cases for Scala, they are just few and far between nowadays. If your looking to experiment with crazy functional stuff have fun, just don't write actual software in it, which was unfortunately the outcome, and a bunch of companies paid the price
This line of reasoning never made sense to me because there's plenty of stuff in the language that isn't absolutely needed, such as the various special syntax for certain concurrency constructs.
They look at how their software is being used and the problems people are encountering using it and then decide what is the best path. To roughly quote Rob Pike 'every feature is useful, but they all have a cost, and its about weighing the outcomes'
Its actually not designed to meet Googles requirements, that just something people who don't know Go say. They have a survey they put out every year and take feedback from customers on issues that arise. They try and fix those issues with as little code as possible, because code and features have a cost.
Caught me, Go was developed for Google only because it fits between C++ and Java meaning its worthless to everyone else ;)
Generics and dep management were on the top of that survey last year. They are the primary focus of the Go team right now. Russ wrote Go Modules for dep managment, the implementation specifically addresses pain points from the community. Generics are a hot topic and looks like we're close to a finalized design.
I mean I'm sure if Google specifically wanted something they could get it, but honestly I don't get the impression from any of the Go authors they are there to serve Google. They seem genuinely interested in just building the best language they know how. The fact that the features being worked on are the ones that are requested by the community tells me thats authentic.
Don't get me wrong the Go authors have overridden the community a couple of times and there was some serious outrage. Don't think that was a Google thing though, more of an "We know better" from the authors.
IMO this would be a bet that the Go team does not implement generics in the vague near future. There's a difference between the Go team making a fundamental design judgment against generics vs the Go team feeling that no super-obvious proposition which balances all the values of Go has been put forth. I think it's a matter of time and resource.
They are just against features with a high cost to the community, generics are pricey as they can go quite wrong. They are now entertaining ways of adding them while limiting their downsides.
Is it declining? Citation needed? I agree that Scala is not the new kid on the block anymore but I don't see it decline. When you look at the language rankings of the last few years, Scala seems to have settled at about ~12th place currently.
Depends on the criteria and the group of companies you survey. In our customer survey done mostly among top 100 enterprises it comes at #3 very close to Python (which is #2), and it is much stronger in absolute numbers than C# or JS. And the trend is growing.
Of course, this is not representative to the whole market and heavily biased towards big companies with big backends that need to scale, but neither are Tiobe, GitHub or SO rankings.
Kotlin is not the future of anything. They got the Android boost and still, two years later, all they have to offer is a molasses-slow improvement pace and a shitty dev experience in their signature IDE (which also happens to be made by the same company).
Last time I tried to create a Kotlin project in IDEA, it couldn't provide type information on hover. The Kotlin dialect of Gradle was barely supported enough to be called a "third-class citizen". It's super embarrassing.
Yeah, Jetbrains marketing wants you to think it is the other way round, but actually tooling support for Scala is ahead of Kotlin by far, except maybe Android.
Scala is not tied to a single IDE, it works great in VScode, Eclipse and Intellij and anything else that supports LSP, which is an open standard. And it works really well - including type inference and very advanced implicits stuff.
And recently Scala got excellent incremental compilation support by Bloop from ScalaCenter, which not only blows Kotlin out of the water but even Java with Gradle. The last year I develop purely in Java and I use Scala bloop for day-to-day development, because I couldn't stand multi-minute Gradle compile times. Getting incremental compile times counted in milliseconds (!) or single seconds at worst is something very hard to give up on.
We're writing new apps in Kotlin instead of Java, works fine for us. shrug Vert.x , Ktor apps, Kafka streaming apps. IDEA handles it absolutely fine these days, I suspect you last tried it sometime ago.
Can't comment on the Gradle stuff though, I vastly prefer Maven.
Vert.x is doing us well for high volume apps, Ktor is early stages but looks alright also. That said, haven't benchmarked identically feature compete implementations of the same app in both, so don't really have the metrics to properly compare, but so far at least, it seems comparable.
I would have said that a year ago but I'm not so sure now. I actually think
Kotlin is at risk of suffering the same fate as Ruby and perhaps Swift:
so stereotyped into being viewed as a single domain language to the extent
it gets ignored by the mainstream. To some extent Groovy suffers it as well -
as soon as you say it people think either Jenkins or Gradle and recall their
last nightmare debugging session trying to reason about its crazy dynamic
behavior, all the while blind to the fact that it has huge general applicability
to all kinds of application development. I even think this is starting
to hurt Python where now everyone thinks it is for data science.
I'm not so sure. I don't see it being used on the server side a whole lot, it seems to be more or less synonymous with Android dev -- and Dart/Flutter is taking big chunks of that space now and growing rapidly.
I won’t even mention the anecdata from my own workplace. I’ll only say that within my extended network people are frantically rewriting Scala bits in other languages. Those who are stuck with it (because of, say, extensive prior investment into Spark) are scrambling to come up with alternate solutions.
Put your ear to the ground, and you too will hear it.
Will take years to get there, if they even get there at all. This is a single-man side project now. Also benchmarking something that has 1/100 of the original functionality and is not production ready is very unfair. It is much easier to get a specialized use case faster than a general purpose system.
He is not the first, Andy Grove worked on a similar thing last years, but he worked mostly alone, and without community you cannot take off such ambitious project: https://andygrove.io/2018/11/datafusion-2019/
I'll speak for myself. I just jumped ship from a Scala team and took a pay hit to get out because it was so horrible. No one on the team had a strong command of the language, which made it worse. The application was a ball of mud. The week I left, proposals to rewrite everything in Java were heard. I took a position on a Go team and am much happier.
I wouldn't jump ship to a Go project, but I am currently in the situation you fled from. Even the core team who started the project doesn't have command of the language. I have some experience with rust and Haskell (hobby) and JVM experience with Java and clojure so I can get by but it is not pleasant.
I think the situation is similar to c++ where too many features have been added over time.
While with c++ there is a body of compiled recommendations on what not to use and how to write c++, for scala that doesn't really exist.
This has nothing to do with languages. I saw the same happening in a company writing pure Java, JS or Python. Doing a project with people who don't have command of whatever stack they are using is asking for trouble.
On the flip side, Scala can be a very pleasant stack to work with if you have right people on the team.
> While with c++ there is a body of compiled recommendations on what not to use and how to write c++, for scala that doesn't really exist.
I switched to clojure for a new job from doing scala for 5 years. I just feel a weight has been lifted off of my head. Weight of syntax, slow compilation, weight of implicits ( some of them are so bad even editors like idea couldn't figure out what is going on). And most importantly the weight of the constant feeling of not being able to fully understand the meaning of endless math terms thrown at me casually like monads, freemonads, applicatives , categories, Kleisli ect.
I spent so much time learning what all these math concepts apply in programming but now I don't remember what any of these mean anymore and I am still shipping production applications ( in clojure). Sigh, what a waste of my life doing scala :( .
This touches on a difference between the Go and Scala communities and courses from my very brief experience learning scala for work the past couple months.
The older I get the more I want things that are explicit and easy to understand. Tons of sites and videos and blogs exist that break down the features of Go without a ton of math lingo. I never see Scala materials free of that. Even when I agree that I need to understand the terms of art I haven’t been in a math class in 16 years and it’s slow going. With Go I was productive in two days and proficient in less than two weeks. Yes I still shoot myself in the foot with channels and race conditions when I’m rushing but at least it’s a super fast compile cycle to iterate and my IDE doesn’t require over 2gb ram like scala / idea does.
Yup being easy to understand without lacking functionality is definitely superior to supporting every insane programming concept. It builds stronger communities and better software
The flip-side here is that a language that doesn’t support basic programming language theory concepts dooms its users to repeat the mistakes of those who discovered them.
I also would personally disagree that any statically types language without generic types and without non-nullability (e.g. `Option`/`Maybe` and `Result`/`Either`) is severely lacking in the ability to express programs that are easy to understand.
proof is in the pudding on that one, sorry don't think there are academics studying this but it's an obvious outcome from the war that was Go/Scala/Node. Go is eating Scalas lunch because its easy to understand and communities are stronger than individuals. Sure Scala has more 'features' but Rob Pike would say every feature has a cost and you need to weigh that, didn't see that ever happen in Scala. Go is taking the time to get each piece right and I'm glad for it.
Another commenter points out that Go has Google backing it, which is a significant confounding factor in terms of figuring out how good it is on its own merits.
I’ll add to this and say that Go is a language that is very well-suited for Google’s issues. Namely, take a bunch of engineers with a particular area of familiarity (e.g. familiarity with C and/or Java) and throw them at code, scaling up by number-of-engineers where necessary.
My issue with pointing to this and calling it “practical” and “easy to understand” is twofold:
(1) Go implicitly makes its ease of understanding dependent on an having existing background knowledge of concepts that the HN crowd is likely to have, themselves, which biases people but isn’t particularly easy to learn on its own merits (versus, say, Python)
(2) Most companies cannot afford to solve engineering problems by throwing more bodies at it, but with Go your option is either that or leveraging external code generation
As far as “taking the time to get each piece right”, this stuff isn’t cutting edge technology development! Go isn’t doing dependent typing or borrow checking or scoped effects!
Everything that people lambast the language over not having is old hat, it’s like defending a car manufacturer who chose to use carburetors over fuel injection by saying that they’re trying to figure out how to do it right.
Practically everything you mentioned is already done better by Java or C#. Not to mention them having advantages that golang isn't even close to solving.
Sorry those just aren't legitimate analogies. As I mention before every feature has a cost, Go is highly concerned with how those costs impact the community. In doing so they have created a language thats highly maintainable and efficient. Even at small companies there is turnover and you being 'really smart' with some abstraction has an impact, I've seen this plenty first hand.
Counterpoint, regarding community: the Rust programming language has a much more vocal, cohesive, and engaged community than Go does in my experience, even though it has a fraction of the corporate backing.
Counterpoint, regarding “reducing the cost of features”: Go is spreading a simplified understanding of what garbage collection performance means to a generation of programmers by providing almost no configuration over their GC settings. I’ve had people say that Go’s GC is obviously the best, without any point of reference with which to compare it.
What Go has done here is pick a reasonable set of trade-offs to make in their garbage collector, hard-code most of these settings into the runtime system, and package that into the philosophy of “configuration is bad”.
Rust has a pretty great community, and I don't think you need corporate backing for a community. I'm just stressing it's one of the most (if not the most) important aspects of a language.
I will say Rust it isn't nearly as easy to enter as Go, that should be somewhat expected by their desired feature set. Likewise, they aren't as concerned with the cost of features as Go is.
I would somewhat agree with the GC stuff, I think having a couple more levers there with sensible defaults is probably ideal.
Adoption isn't everything and google has incredible marketing sway.
Tensorflow almost won the ML framework wars despite being clearly outclassed by Torch and it took until recently for Torch to overcome the Google brand name
Marketing and they understand how to build communities, this is actually the most important thing. TF isn't a great product so thats showing through now, Go and K8s are and you don't see the backtick there.
Go is one of the worst things to happen to the programming community in recent times, truly a 20 year step back that ignores practically everything we have learned about programming.
> Go is taking the time to get each piece right and I'm glad for it.
Have you ever taken a look at the error handling in Go standard libraries? Rob Pike is constantly badly reinventing monadic error handling patterns and doing it wrong; He even admitted to this himself.
O here we go with more canned Go insults. It's actually written by a bunch of old guys that have seen the evolution of programming and made the design for very specific reasons that you apparently can't understand.
Error handling is an active topic of consideration, but I kinda like how it is now.
Have you ever maintained production Scala code? I have and it was an absolute nightmare compared to Go.
A while back i was happily writing clojure, but after a while its dynamic typing got problematic and that's when I learned scala. I really liked it, I think functional but statically typed is the way to go.
Although I still think that it is a lot of fun to write clojure, it's a breeze with its focus on stateless, functional code.
I tried to get into writing a GraphQL API in scala once, and the library made excessive use of the implicit parameters. That was too much for me, there was always something missing and it wasn't immediately apparent where things are taken from or why something doesn't work in one place but does in another.
Define idiomatic. As an example, I find myself using the java.time package quite frequently. An example:
(ns dev.scratch.time-ex
(:import
(java.time Duration)
(java.util Date)))
(let [from (Date.)
until (-> from (.toInstant) (.plus (Duration/ofHours 12)) (Date/from))]
[from until])
Returns a 2-element vector containing two java.util.Date objects, the second twelve hours in the future of the first. Here I'm using Date, Instant, and Duration classes. It's consistent with Clojure syntax (methods being first items in a list), and remembering to use . or / (roughly for instance or static methods) for calling Java methods. Using something like the thread-first macro (->) is idiomatic Clojure, and it's not my goal to convince you that Clojure syntax and style is better, just that Java is immediately and idiomatically available (from a Clojure point of view).
I find very little friction in using Java directly from Clojure code. I can't speak to comparisons with Kotlin as I have no experience using it.
Not sure what you mean. It is idiomatic to not rebuild things Java offers in Clojure and to instead just use interop with Java.
Using Java from Clojure I'd say is as good as Kotlin. Using Clojure from Java isn't as good as Kotlin, but it is still pretty good. Only certain things get messy, like in frameworks where you need to extend a class and override methods to set some behavior. Or frameworks that make heavy use of annotations. Since Clojure isn't OO, doing those are a bit trickier.
Nowhere near as good or as seamless as Kotlin interop, Kotlin made interop a priority/first class feature.
When using a Java library in Clojure, many times its just better to just write some Java for your Clojure program specifically for the purpose of calling it from Clojure.
That hasn't been my experience. I've always been able to make use of Java libraries directly from Clojure in a straightforward way. In fact, sometimes I joke it's easier to do Java in Clojure than in Java
Can you describe the kind of situations that you faced issues in?
P.S.: Also, Clojure has first class interop... It's a part of its fudamental design.
In what sort of situations have you needed to write more Java to use a Java library from Clojure? I've never felt the need to do this. It's sometimes helpful to write a Clojure wrapper for a Java library on order to use it in a more Clojure-y way.
> When using a Java library in Clojure, many times its just better to just write some Java for your Clojure program specifically for the purpose of calling it from Clojure.
What? Calling Java from Clojure couldn't be any easier. The same as calling JavasScript from ClojureScript
This is fantastic. Scala 3 is a huge improvement, doing away with main of the pain points of Scala 2 and making using Scala effectively much more straightforward. I'm looking forward to getting to work with Dotty / Scala 3.
Personally I am making top money on Scala gigs, and I don't see that changing anytime soon. The people I meet on these gigs share my opinion. Most people wouldn't take a Java job even if it paid more, same for Go or Node ( both of which I have used in production in the last month, and wouldn't take over Scala, with the exception of serverless)
Teams in Media, Government and Finance are leveraging Scala to do things that take Google and Netflix twice as many devs because they use less expressive languages.
Yes, Go is great because you can scale a team from 1 to 10 to 100 with little effort. With Scala you get the same stuff done with 20 people.
The people that hate Scala are either Java devs that didn't get it because they wanted to write inheritance based OOP code and would still be bad devs in any other lang, or are hiring managers that struggled to get the right people.
This is actually an advantage when you have the right hiring process as you end up with better developers - they don't need to know Scala, but need to be open minded to new ideas and motivated to learn.
With all that said, the church of FP and the hascalator community is a problem for Scala. Overly dogmatic & academic functional programming styles don't have a place in production systems.
Leverage the type system, immutability and the Future/Option monads and you eliminate huge swathes of bugs. If you are looking to write "Java on steroids" or would rather be writing Haskell then you are probably contributing to Scala's perceived problems.
If you are a startup or small business then Scala isn't a good fit - you're probably better off starting with JS or Python and moving to Scala when you have more users and need to deliver something solid. FAANG don't need to use Scala because they can throw money & devs at problems and therefore favour languages that fit that modus operandi.
For all the companies in between, Scala is great fit because when you get the right people you can outmanoeuvre any competition.
One of the earlier comments described Scala as a love child between Java and Ruby that turned out great. Despite not having used Ruby in anger I agree with the sentiment as I believe the best way to write Scala is as a statically typed Ruby for the jvm. It's supposed to be simple and elegant, and the best Scala devs realise this. To re-iterate my earlier statement, if you are trying to write something "oop" or "pure fp" then you are getting it wrong.
We're a Ruby/Python/JS/Scala shop and once people are up to speed the productivity of Scala blows the other three out of the water. It's insanely hard to beat the productivity-performance ratio of Scala.
FWIW, I'm in a FAANG and finding Scala devs is even a problem within my own org and team. We've resorted to teaching largely Java devs Scala on the job with mixed results. A former senior manager who made the decision supposedly viewed going all in on Scala as a mistake in large part due to the huge time loss in ramping people up & problems hiring.
I like what I've used of the language at work, although I tend to write a lot of JavaScript on a day to day basis, but to say the right hiring process makes Scala an advantage is not quite right in my own experience.
I'm not trying to guess where you work, or saying this applies to your company or team, but as usual, FAANG is not a very helpful acronym here.
From what I know there are very successful teams that use mostly Scala, at least at Apple and Netflix.
Now Amazon... I've had some AWS recruiter approach me specifically because I was looking for a new Scala job, who assured me they had a few products 100% in Scala. He then directed me to a team that didn't give a damn and was looking for a generalist. Not the first time I experienced the broken recruiting process at Amazon.
Hiring Java devs is the problem. It's a lowest common denominator language.
Try looking for Ruby or JS devs. It's a lot easier to teach someone from a dynamic background how to leverage a type system than it is to teach an imperative developer to write side effect free code. State is a crutch.
They just happen to be people who has done Java - we hire the best devs we can, regardless of language experience (my own team has interviewed/hired people who have done primarily Python, Ruby, JavaScript, Clojure, and/or Java). A couple turned out pretty well, but several turned out to be much more junior than we expected. I should add that I have no love for Java myself, I rather not be writing Java at all if I can help it.
If there is one thing this profession has taught me about hiring, it is that it is very difficult to predict who the top performers will be. Blanket assumptions will often prove to be not true when searching for the cream of the crop.
I really don't see how people have trouble finding Scala jobs. All the respectable newish companies around me use Scala on the backend (old and large companies are unfortunately still stuck with Java and similar abominations). If someone wanted to hire me for a NodeJS, Python, Ruby or Java backend I would laugh at them.
>With all that said, the church of FP and the hascalator community is a problem for Scala. Overly dogmatic & academic functional programming styles don't have a place in production systems.
Isn't Scala minus the problems you mentioned just Kotlin?
Personally, being able to solve problems with the abstractions you can achieve within the language over adding very specific language features to solve them appeals to me more.
The more I read about Scala it makes me wonder why (1) I am not using it (or my team) (2) Java teams across the world are not at least seriously considering changing to Scala. It seems likes it's miles ahead of both Java and even Kotlin.
Having led engineering at a startup that developed ~95% of our code in Scala and then moving to a FANG team that developed most of its services in Java (still using Spark Scala to a large degree and beginning to introduce Kotlin), these are the reasons I can use to justify using Java over either: 1) it is already there, 2) most engineers know Java well [enough], 3) other teams predominantly use Java and it makes certain types of code sharing more streamlined. I'm assuming most Java shops have existing tooling that will lock them into the JVM no matter what. That's fine, the JVM is incredible.
Kotlin can be introduced very easily into most Java codebases as interoperability is a tenet. Scala not so much. Holistic interop between Scala and Java can fill an entire intermediate-level book.
At the startup, we had a difficult time hiring for Scala. A number of candidates we moved forward with who were well-versed in it wanted to explore the language and embrace the FP aspects, which led to incomprehensible code for the engineers used to procedural OOO. In full retrospect, this was an issue with our hiring standard; Scala should not have been a specific part of our bar. It was a startup, we had crushing customer demands, there was no time to teach every engineer what an IO Monad was. It was a constant battle and perhaps the most frustrating aspect to me leading all the way up to acquisition. None of these issues would have existed if we chose e.g. Go; we would have quickly found a team of engineers who wanted to build applications instead of tinkering with the language. To me, that's the best part about Go -- it's boring.
Java is another boring language, but it's also a very verbose one, even when fully utilizing Lombok/G-libraries/etc.. Kotlin fixes the verbosity issue to a large enough degree for my needs without introducing enough interesting features to attract those darn academic types. To me, Kotlin is about as good as a language can get while remaining on the current iteration of the JVM. We have been slowly introducing Kotlin and plan to use it for most new non-Spark-related projects. I would only consider Scala for the same purpose if 1) interop was trivial to the degree that Kotlin's is, and 2) it was reduced to a reasonable subset of its full complexity. I believe the right steps are being taken with the language, but it still has a ways to go in those regards.
> Java is another boring language, but it's also a very verbose one, even when fully utilizing Lombok/G-libraries/etc..
Incidentally, I find golang to be more verbose than Java. The amount of one-off functions you have to write to get around the lack of generics and/or map/filter calls on collections makes the code longer and harder to follow, and harder to debug. Not to mention error handling.
I generally agree with the gist of your post though.
What ended up happening with the startup you worked at out of curiosity?
> What ended up happening with the startup you worked at out of curiosity?
We made two poorly judged business decisions: 1) build a marketplace without enough proof of demand, 2) treat certain types of financial instruments as securities ahead of a fed decision that never materialized (I call this the bizzaro-Uber play). Outside of the things we could have controlled, the sector we operated in did not meet its expected growth projections in the aftermath of certain participants not playing nicely. We were acquihired as part of the typical VC risk sharing.
The ultimate failure had very little to do with Scala as a tech decision. I was extremely proud of the products we built from an engineering perspective, but I don't credit Scala with that either. The high-performers on the team could have repeated the same technical success with any of the languages I discussed above. Perhaps our hiring was slower than our funding level would have allowed. Perhaps our worse-performing engineers could have contributed more if it was Go or Python. Neither of the alternative realities would have gotten us past the two aforementioned business decisions.
> Java teams across the world are not at least seriously considering changing to Scala.
I've used Scala before. It has challenges that would make it a non-starter for many teams. It has some cool features, but those (IMO) don't outweigh the negatives that come with the language: it's overly complex (different people have very different styles for writing the language), the compiler is slow, it generates more garbage than Java, lots of implicit behavior, the standard library is not up to par, among others. Java is improving significantly in the coming few releases: pattern matching, records, switch expressions, etc. will bring to programmers the bulk of what Scala has to offer without the added weight. Kotlin is a much better contender for most teams anyway, and even that will be a challenge IMO.
If I read it correctly, you said "Scala standard library is not up to par", "Java is improving significantly in the coming few releases: pattern matching, records, switch expressions". I see the other way around: Java 14 records, pattern matching and switch expressions are like a joke compared to Scala case class and pattern matching. For example, does Java 14 Stream have any method equivalent to `collect` in Scala, which is a combination of filter and map?
> Java 14 records, pattern matching and switch expressions are like a joke compared to Scala case class and pattern matching.
What does Scala's pattern matching do that Java's (upcoming) doesn't?
> For example, does Java 14 Stream have any method equivalent to `collect` in Scala, which is a combination of filter and map?
Not that I'm aware, but then again, I don't see the large advantage compared to making two separate map + filter calls. Streams in Java are lazy, whereas calling `map` or `filter` on a concrete collection in Scala is eager, creating temporary intermediate collections only to discard them in the case of chaining calls.
case class Person(name: String, age: Int)
// a collection of 3 people
val c1 = Vector(Person("A", 5), Person("B", 6), Person("C", 4))
// now I want a collection of people who have age > 4 and then their ages are doubled
val c2 = c1 collect { case Person(name, age) if age > 4 => Person(name, age*2) }
How do you write it in Java 14?
Want something lazy like Java streams? It's LazyList in Scala 2.13 and Stream in Scala < 2.13.
data class Person (val name: String, val age: Int)
val c1 = listOf(Person("A", 5), Person("B", 6), Person("C", 4))
val c2 = c1.filter{ it.age > 4 }.map{ it.copy(age = it.age*2) }
Kotlin and Java don't have a powerful pattern matching like Scala. Maybe that's why they don't have `collect` for filter + map. However I'm learning kotlin now because my employer doesn't allow me to use Scala
I love Scala, it has a nicely advance static type system, supports functional programming and has even macros, although they are a bit messy. Something I miss in go and python. Go's type system is way to simple and python is dynamic, which I think is unnecessary these days. Static type systems can be as expressive as dynamic ones. It has interesting libraries, like cats, shapeless, breeze. And it is popular in the big data field.
I was initially skeptical of Scala when I landed my first Scala gig a few years ago, but now I'm really glad I picked it. Simple things like pattern matching and immutability are amazing, and Implicits + Macros enables some awesome libraries like Shapeless[1], Chimney[2] which solves real business problems in a succinct and type-safe way.
Very excited about what's coming in Scala 3
* Lots of improvements to make the language simpler and easier to work with
* Integrating some tried-and-true patterns from the current Scala ecosystem directly into the language
* First-class tooling to solve some long-standing issues in the ecosystem (binary compatibility)
The team behind Scala 3 has done a tremendous job. Along with the whole movement of better tooling that's happening in the Scala ecosystem right now, I think the language will have a fun and productive future!
The problem of Scala is that it is outclassed by Rust and Kotlin at its two niches of, respectively, "best designed programming language" and "better Java on the JVM".
Scala can't beat Rust because you can't have safe concurrency (and also single-threaded mutation control) without linear types, and you can't have linear types on the JVM; furthermore, a GC and VM-based language is inferior to a native non-GC one providing the same guarantees.
Scala can't beat Kotlin because Kotlin is designed to be just a better Java and Scala also tries to do other things that reduce Java compatibility; pivoting would result in being behind Kotlin with no hope of catching up.
Furthermore, its core features are cute but fundamentally broken: class inheritance is an anti-pattern and functional features need either purity like Haskell or mutability control like Rust to work safely and efficiently; on top of that, the language is also complicated and hard to learn.
Scala and Rust are not competitors. They solve different problems and are designed for different kind of software. Rust will never be in the same league of productivity / abstraction as Scala is. There is a huge mental overhead of manual memory management that the language forces on you everywhere. Try to write a lockless or immutable Hashmap in Rust and then in Scala to see the difference. Or a graph-like structure. Or async code. Just compare method signatures. Scala is a piece of cake compared to Rust in this area.
On the flip side, Scala will never be as good system language as Rust is, even after adding more improvements to the JVM e.g. value types, or even with Scala native. In these use cases where I need a tight control of resources I'd take Rust over Scala every time.
As for Kotlin - meh, it is just Java with nicer syntax, not interesting to me at all.
I really love Scala, but I worry about its future given Google putting its weight behind Kotlin, and the two offering a lot of the same features and philosophy.
Does anyone know if the Scala maintainers have addressed this directly?
* If you use even half of Scala's functional capabilities, Kotlin isn't really an alternative.
* What Google does with Kotlin and Android is completely irrelevant to the Scala ecosystem and its users.
* On the back-end side, Kotlin doesn't intersect that much with Scala. I haven't met anyone migrating from say, Play to Spring thanks to Kotlin's support.
* In the big data world, if you rely heavily on Spark, Scala is still the preferred option on the JVM. Python is a much bigger threat there.
* Lightbend and the Scala center have been seriously working on tooling, which is the biggest issue to address compared to Kotlin (Jetbrains has a huge advantage here).
> I haven't met anyone migrating from say, Play to Spring thanks to Kotlin's support.
Hi, now you have :) Well, Vert.x and Ktor, not so much Spring Boot.
It's mainly because effective and readable Scala requires a lot more discipline and experience than effective Kotlin for a Java developer. If we'd started solely with experienced Scala devs then I suspect we wouldn't have had an issue.
There is, also, the problem of footguns - we've inherited a large Scala codebase from a sister company, and they, unfortunately, let the devs run free. So there's large amounts of hard to debug, hard to read, Scala magic going on. Implicit classes, inherited three levels deep! Macros! Why? Because they could!
Kotlin wins also because it has a stable and usable Native flavor. Scala Native is a third-party project and seems dead, while Kotlin Native is the core part of the Kotlin language and being developed at a fast pace.
Kotlin/Native is not semantic compatible with Kotlin code written for the JVM without any regard for other platform's existence.
Then there is the total lack of access to the huge JVM eco-system, a less performant automatic memory system, and AOT playing catchup with AOT/JIT tooling available for the JVM, some of which with battlefield experience in production since the early 2000's.
And then there is the whole thing that JetBrains gladly sells CLion licenses for the whole development experience with Kotlin/Native.
The problem with scala is that the docs were too late to come.
Those who put them out are geniuses (props Cats ppl, ZIO too) - but it seems it is now too late. You know there’s irony that alot of the earlier docs were based on haskell books, too.
Its not the math. Look at haskell’s freenode presense vs scala’s. Scala’s a 6th of haskell. What haskell had over scala is docs and community.
Scala was just too late, and my coworkers are all whispering Kotlin. It’s a real shame.
Irony edit: i actually maintain a scala codebase at work, one of two under thirty other devs who do, and me and one of the major players in the team were talking about this only two days ago. Sort of a sad kind of funny.
That's a complete myth, really. The Scala ecosystem has its fair share of problems, but Odersky and his lab's involvement and stewardship have never been one of them.
The complaints I see about Scala mostly seem to centre on whether other people are adopting Scala. "Google's backing Kotlin", "Rust and Go have more trajectory", "FP programmers in Scala write too complicated code that puts off the OO developers", "FP programmers I know are moving to another language", and of course the sad twitter-wars that seem to break out within the Scala programming community that put people off.
Personally, I've found Scala to be by far the best language I've ever worked with. The complaints on the complexity of the library are ones they are (at least partially) trying to address in Scala 2.13. Dotty, though not revolutionary, looks like a nice set of improvements too.
It's not a "pure FP language" (though some might like it to be), but is a multi-paradigm language on the JVM. It has a lot in it, but moves relatively slowly. To me, those are its advantages, and for someone like me they are fantastic. I am in academia, which means that a lot of my software is written by me for courses and so I get to work on it in patches about twice per year. In Java-land, that'd mean major language versions are now faster than I get to revisit my projects. In Scala, I've had projects progress from 2.10 to 2.13 (and soon 3) with maybe two days' effort updating them so they feel fresh with the language, even though the language still feels more advanced than Java, Kotlin, and most of the "faster" competitors.
Scala.js works astonishingly well (I wrote my own react-like framework in about 1,000-lines of code, so I no longer need to fuss about whether React's just updated so everyone should be using function hooks now either). Graal looks like it's going to come along and solve the issues with native deployment soon too.
In short, while most of the complaints I hear are about Scala as a community, it seems one of its strengths is how it is robust to the winds and storms that blow through programming communities.
Having recently jumped into a Scala team from a mainly OOP background, I'm starting to see the light with the language. Using the type system to handle code you would otherwise have to write defensively. Letting the compiler take more of the strain of the second order functional concerns of the program and leaving what's left to be an accurate description of your problem domain is a refreshing perspective on coding. Your code looks a lot more like the problem you are trying to solve rather than 75% if(x==null) and 25% business logic. That said, the learning curve is steep and the quasi-hidden nature of implicits never sits well with me. It seems like a way of adding semi-defined behavior to your code and is one of those language features that should be treated with care.
Scala is an amazing programming language without rivals when it comes to flexibility. Having said that, while I feel enormous respect for people who pushed functional programming in scala to the limit and almost mainstream, I think blindly porting 99% of Haskell to scala is largely responsible for scalas's observed complexity.
Scala is dead for anything that isn't academic. They didn't listen to their customers and ultimately burnt them. Every company I know that was using Scala is running pretty much running any other direction now. It was an interesting experiment I guess.
For all the complaints about the language that always pop up in these threads: yes, the language lets you shoot yourself in the foot (with great power comes people who don’t apply it responsibly), but it’s precisely that power that makes it so useful and exceptional when judiciously applied.
I like to say that scala is as if java and ruby had a love child and it all worked out. Unfortunately, that does mean that java people will feel it’s too fast & loose, and the ruby people will feel stymied by its static typing. But I just love that where other statically typed languages generally say “no”, scala says “well, I trust you know what you’re doing...”.
The only substantive tool complaint I have these days isn’t with compiler speed - it chugs through the codebase plenty fast - but with tool startup time. Hopefully the more recent java versions and maybe some native packaging will eventually help with that.