Comment by morshu9001
2 days ago
Doing fancy things with types used to interest me, now it's the last thing I want to touch, after being burned too many times by libs trying to be clever.
I used Scala a few times when it was semi popular, just seemed like Java but with lots of redundant features added. Not sure what the aim was.
Certainly one can get too clever/fancy, but I appreciated that Scala let me express things in the type system that made more of my program confidently correct at compile time than I could do in Java. I hate writing tests, and with Scala, I could write fewer of them, but still be confident that things were working as intended.
But ultimately using Scala at the place I worked at the time was a failure. A couple of my co-workers had introduced it, and I joined the bandwagon at some point, but it just didn't work out.
Many Java developers inside the company didn't want to learn, and it was really hard to hire good Scala developers. The ones who did learn (myself included) wrote terrible Scala for a least the first 6 months, and that technical debt lingered for a long time. When other people outside the team (who didn't know Scala) needed to make changes to our code, they had a lot of trouble figuring things out, and even when they could, the code they wrote was -- quite understandably -- bad, creating extra work for us to review it and get it into shape.
I also feel like Scala suffers from similar complexity/ways-to-do-things problems as C++. I often hear people say things like "C++ can be a safe, consistent language if you just use a subset of it!", and then of course everyone has a subtly (or not-so-subtly) different subset that they consider as The One True Subset. With Scala, you can write some very complex, type-heavy code that's incredibly hard to read if you are not well-versed in type/category/etc. theory (especially if you are using a library like cats or scalaz). Sure, you could perhaps try to come up with some rules around what things are acceptable and what aren't, but I think in this case it's a hard thing to specify, and different people will naturally disagree on what should be allowed.
I really wanted Scala to succeed at our company, but I think that's hard to do. I feel like the ideal case is a small company with just a few tens of developers, all whom were hired specifically for their Scala expertise, with a product/business that is going to keep the number-of-developers requirement roughly static. But that's probably very rare.
C++ was how I'd describe it, too many different ways to do simple things. I guess Java++
> I used Scala a few times when it was semi popular, just seemed like Java but with lots of redundant features added. Not sure what the aim was.
Blub is a great language!
then why is java adding back half baked versions of scala features every major release
Saying that the new Java features are half baked, to me, shows you're just feeling hurt because people prefer Java over your favourite language.
Java may not be the pinnacle of programming languages, but since Java 8, pretty much every feature it's added has been absolutely excellently done.
i mean, it follows the java philosophy (preseving backward compat). theyve done great work improving java. but i see no reason to use it over scala where i get better features, its more like a java 2.0
2 replies →
Cause it actually needed lambdas and things that go with it. Didn't need all the Scala-specific data structs like Array.
And the most important thing Java was always missing until recently, virtual threads, were lacking in Scala too.
Virtual threads is a JVM & stdlib feature, not a language feature.
(And I'd disagree that virtual threads were all that important compared to language features.)
1 reply →
Lambdas weren't simple to shoehorn into Java. But most of the recent changes have been implemented as well or better, or as well as you could imagine while maintaining backwards compatibility and Java-ness.
Records/sealed interfaces (ADTs) are quite clean.
Text Blocks are better in Java IMO. The margin junk in Scala is silly.