Live data from Hacker News

Scala 3.0

github.com

101–110 of 292 posts

Re: Scala 3.0

#102
Congratulations!

I always have great respect for Scala because itself and the community tried to adopt and push the novel idea in the industry. Take a look at the changes, they're no joke to design and implement. At the same time, they're also trying to make the language consistent and simple. (Yes, I mean simple, not easy or single-paradigmed)

They are taking the hard way, and not only there are not enough people to appreciate the effort, but also attract some hatred from time to time. I hope Scala 3 would bring us and itself a bright future, and inspire more languages to move forward.

(For example, there are a lot of type features added to TypeScript in most releases because it needs to do the typing on existing dynamically typed languages, it may also be a hint that dependent type actually makes sense in mainstream languages).

Re: Scala 3.0

#103

I'm so psyched about this. I've followed the development of Scala 3 for pretty much the whole voyage, and I think they've done an incredible job bringing the community along through some pretty radical changes to the language. It has definitely not been an easy process herding a community with very big, informed, divergent opinions on the language. In the end, I think they did an awesome job. Many, many sacred cows o…

I totally agree. I love the direction of Scala 3. This quote says it all I think:

"Scala 3 takes a slightly different approach [from Scala 2] and focuses on intent rather than mechanism. Instead of offering one very powerful feature, Scala 3 offers multiple tailored language features, allowing programmers to directly express their intent"

So rather than something like implicits, that can be used N different ways, only 2 of which are practical, Scala 3 adds those 2 features explicitly.

https://docs.scala-lang.org/scala3/new-in-scala3.html

Re: Scala 3.0

#104
post #58

The optional brackets really makes the code look clean and easy to read!

I largely agree. It was (and is) a contentious issue, but I think it helps a lot in removing textual noise, in most cases. And it's always possible to add the brackets in where clarity helps.

I largely disagree and am not looking forward to dealing with mixed brace code at work.

Re: Scala 3.0

#105

Scala is not perfect but it’s very good. It’s competitive pressure arguably improved Java (streams, pattern matching, data classes).

I think apart from streams it was Kotlin that did the trick.

It could also be transitive: Scala inspired Kotlin and then Kotlin did the trick, I hope they could share the credit :)

Re: Scala 3.0

#106

I am excited about Scala 3. Scala is a powerful tool that can make teams hyperproductive. Here are the tooling shifts that can broaden the Scala 3 userbase: * Community switching from SBT to Mill * Community agreeing on automated code formatting and everyone using the same scalafmt settings. After using automated code formatting tools like black for Python and gofmt, programmers really don't want to talk about whites…

> Getting the community to use the Principle of Least power is perhaps the hardest

This hurts so much. The nerd in me wants to gush over the improvements in Scala 3, but that pleasure has been ruined by observing in my own coworkers that the people who are the most excited about Scala are terribly self-indulgent in their work. I know when my coworker says he's excited about @inline that our first Scala 3 service (which I'm guessing he will roll out next month) will have more than one use of @inline, for no other reason than his desire to learn it. I am a huge fan of Scala, but I am developing a knee-jerk Grinchiness about any kind of excitement about it.

I hate the way my feelings have changed, but still, I think we have to wrestle with the fact that in many if not most software organizations, the Scala advocates are people who enjoy having fun with technology and leveling up their skills and who cultivate an intentionally and stubbornly unexamined assumption that continually adding new programming powers to their skillset is the best way to serve the needs of the business and the needs of their coworkers.

If I could wish for one impossible thing for Scala, it would be widespread top-down forced adoption, so that lots of people who aren't particularly enthusiastic about Scala are forced to use it. I think people who are less enthusiastic about Scala write better code in Scala. I think they could improve Scala (and Scala could improve their programming as well.) What I'm seeing now in practice is Scala being avoided by those people who have the skepticism and discipline to use it well, and embraced by people whose engineering decisions are determined by their feelings of curiosity and boredom.

Re: Scala 3.0

#107
post #104

Earlier quoted context omitted.

I largely agree. It was (and is) a contentious issue, but I think it helps a lot in removing textual noise, in most cases. And it's always possible to add the brackets in where clarity helps.

I largely disagree and am not looking forward to dealing with mixed brace code at work.

Hopefully there will be a scalafmt rule that can enforce consistency.

Re: Scala 3.0

#108
I think the best evolution of a programming language is when some features are removed and replaced by a unifying concept which makes the language both smaller and and more expressive. Has that happened in Scala 3?

Re: Scala 3.0

#109
post #24

Earlier quoted context omitted.

Both are guest languages, Java owns the platform. What did the trick are the other programming languages that can stand on their own as platforms.

Scala can compile to JS or LLVM. Why owning a platform when amazing ones already exist?

One either gets to say where the platform goes, or keeps playing catch-up with its features, requires additional tooling, wrapper libraries, care about FFI, IDE plugins that understand all of that in a coherent way.

Re: Scala 3.0

#110
Looking at the new features. Can anyone say what dependent function types are good for? In the example (https://dotty.epfl.ch/docs/reference/new-types/dependent-fun...), what's the difference between:

def extractKey(e: Entry): e.Key = e.key

and:

def extractKey(e: Entry): Entry.Key = e.key // the way I'd normally think of it

Post reply on HN