Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

The Road to Scala 3

scala-lang.org

Post reply on HN
Print view View original

191–196 of 196 posts

Re: The Road to Scala 3

#191

Post by sideeffffect »

Bahamut wrote: post #109
ccthr wrote: 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…

> We've resorted to teaching largely Java devs Scala on the job with mixed results.

If I had to hire and teach people for Scala, I would probably go with those familiar with TypeScript or C#.

https://twitter.com/alexelcu/status/1175293360963227648

Re: The Road to Scala 3

#192

Post by pas »

abhijat wrote: post #166
lihaoyi wrote: 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…

I assume you don't have to use sbt builds because you use mill? Also you mentioned command line tools. Any chance you could elaborate on how you distribute them? Thanks

http://ammonite.io/#RunningScripts ?

Re: The Road to Scala 3

#193

Post by wbillingsley »

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.

Re: The Road to Scala 3

#194

Post by abhijat »

pas wrote: post #192
abhijat wrote: post #166

Earlier quoted context omitted.

I assume you don't have to use sbt builds because you use mill? Also you mentioned command line tools. Any chance you could elaborate on how you distribute them? Thanks

http://ammonite.io/#RunningScripts ?

Thanks, I was looking for standalone distribution (something like go) but this looks quite interesting and may be a good alternative.

Re: The Road to Scala 3

#195

Post by stewbrew »

oxnrtr wrote: post #119
stewbrew wrote: post #77

Earlier quoted context omitted.

Just an example: Why wasn't it a priority to make scala run well on dalvik? The place is taken by kotlin and is one of its strongest selling points.

Core team didn't care about Android. Simple as that. :-)

That was pretty much my point.

Re: The Road to Scala 3

#196

Post by erikpukinskis »

asimpletune wrote: post #40
jacobn wrote: post #32

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…

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

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

Post reply on HN