Live data from Hacker News

The Road to Scala 3

scala-lang.org

131–140 of 196 posts

Re: The Road to Scala 3

#131

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…

> 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.

[1] https://www.bruceeckel.com/2015/08/29/what-i-do/

Re: The Road to Scala 3

#132
post #86
post #45

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…

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…

Scala 3 has been around for seven years on Github https://github.com/lampepfl/dotty/commit/2308509d2651ee78e11...

Scala.js and Scala Native will support Scala 3 eventually.

SBT isn't nearly as bad as it used to be. It's an open question how much more it will "improve".

Re: The Road to Scala 3

#133

Earlier quoted context omitted.

What about kotlin?

Yes, Kotlin seems to me like the future of Java.

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.

Re: The Road to Scala 3

#134
post #86

Earlier quoted context omitted.

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…

Scala 3 has been around for seven years on Github https://github.com/lampepfl/dotty/commit/2308509d2651ee78e11... Scala.js and Scala Native will support Scala 3 eventually. SBT isn't nearly as bad as it used to be. It's an open question how much more it will "improve".

> 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!

Re: The Road to Scala 3

#135
post #129

Earlier quoted context omitted.

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…

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;…

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.

Re: The Road to Scala 3

#136

Earlier quoted context omitted.

Scala’s type system goes far beyond simple generics.

and thats fine in an academic setting, but please don't bring that into the real world unless you have a really good use case.

So then please don't cite Scala as an example of type parameters being not worth it.

Re: The Road to Scala 3

#137

Earlier quoted context omitted.

and thats fine in an academic setting, but please don't bring that into the real world unless you have a really good use case.

So then please don't cite Scala as an example of type parameters being not worth it.

in academia sure, have fun!

Re: The Road to Scala 3

#138
post #104

To all those saying Scala is dying: 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…

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 wri…

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.

Re: The Road to Scala 3

#139
post #104

To all those saying Scala is dying: 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…

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 wri…

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.

Re: The Road to Scala 3

#140

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…

> 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…

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

Post reply on HN