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

Scala 3.0

github.com

Post reply on HN
Print view View original

141–150 of 292 posts

Re: Scala 3.0

#141

Post by agbell »

darksaints wrote: post #136
swader999 wrote: post #135

Earlier quoted context omitted.

The days I spent chasing implicits are still lost to me forever.

They should have never been a language feature before IDEs were capable of working with them and exposing them. Luckily they do now...but Scala 3 makes it so that understanding them with a simple text editor is much easier. The fact that they have to be imported in a way that acknowledges their usage is a simple but important way to ease that burden, and the distinction between `given` and `using` is extremely helpfu…

Rumor has it Kotlin was inspired by frustrations getting Scala edge cases to work in IntelliJ.

Re: Scala 3.0

#142

Post by agbell »

sesm wrote: post #134
halfmatthalfcat wrote: post #128

Earlier quoted context omitted.

They didn't "remove" implicits in the absolute sense but they made it much more ergonomic to work with implicit-like behavior using the "given" keyword now.

Sorry, maybe I was wrong. I was looking at this article https://docs.scala-lang.org/scala3/new-in-scala3.html and I had an impression that they split implicits into several other more specific features.

That is my understanding of what they did.

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

Re: Scala 3.0

#143

Post by RhodesianHunter »

hocuspocus wrote: post #74
serial_dev wrote: post #66

Earlier quoted context omitted.

What they probably meant is that both Scala's and Kotlin's improvements pushed Java to improve. Both languages had many different features that back then weren't available in Java but since then got added to the Java language, and that made Java better, too.

I still don't see how Kotlin is involved. People drafting JEPs are well aware of how modern languages, including the ones running on the JVM, have evolved in the past decades. Kotlin is pretty late to the party and hasn't really brought anything new to the JVM (by choice), except for coroutines maybe. Edit: see pron's comment below.

Kotlin becomes the default on Android, more people are writing Kotlin, there's more pressure on Java to adopt the best Kotlin features.

If you look at most of the recent additions to Java, they were in Kotlin from the beginning. This is no coincidence.

Re: Scala 3.0

#144

Post by RhodesianHunter »

pron wrote: post #44
isbvhodnvemrwvn wrote: post #22

Earlier quoted context omitted.

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

Java has not picked up a single feature from Kotlin yet (maybe nullability types someday?), and, in fact, opted for very different ones (e.g. contrast records vs. data classes, virtual threads vs. syntactic couroutines), although I guess Scala has provided some inspiration for some features, as Java's are closer to Scala's than to Kotlin's. ML is probably the biggest influence, with some Haskell flavour. But I find i…

What are you talking about? Java release notes look like a list of Kotlin features these days.

Sealed classes, data classes, multiline strings, coroutines -> project loom, switch statement improvements to resemble Kotlin when statement, improvements to Streams to match Sequences.

Re: Scala 3.0

#145

Post by namelosw »

amw-zero wrote: post #122
namelosw wrote: post #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…

Can you elaborate on the changes in TS that hint at dependent types? That's interesting.

I'm not referring to some specific changes. It's just there are many type operators already and still not enough to express JavaScript.

In the earlier versions of TypeScript, I often stuck with something natural in JavaScript but cannot express the same thing with type annotations - It's like opening a pandora box, once some advanced type operators have been introduced, whenever I played with them I would quickly found more type operators to be desired.

And so it did. Things were getting better over years, there were a lot more type operators, mapped types, the infer keyword, etc. I feel it points to a direction: There is still a lot of existing JavaScript functions' type depend on the input which cannot be well-typed. For example, there are functions similar printf in most languages, or return type T when 0 is passed otherwise return type U. To satisfy those cases, we'll basically reinvent a whole new programming language in the type system - if the new language happens to be JavaScript itself it would be similar to other dependent type systems.

Re: Scala 3.0

#146

Post by doggodaddo78 »

Not to denegrate or barf on anyone's birthday cake but IIRC there were some complaints of unfriendly community support interaction styles. Is this still the case?

Re: Scala 3.0

#147

Post by agbell »

augustk wrote: post #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?

In some areas it is explicitly the opposite that happened, and in a way that is for the best — see implicits.

Scala 2 is a very flexible language and a lot of outsider complaints seem grounded in this flexibility.

Scala 3 is more opinionated in some ways:

"Opinionated: Contextual Abstractions

One underlying core concept of Scala was (and still is to some degree) to provide users with a small set of powerful features that can be combined to great (and sometimes even unforeseen) expressivity. For example, the feature of implicits has been used to model contextual abstraction, to express type-level computation, model type-classes, perform implicit coercions, encode extension methods, and many more. Learning from these use cases, Scala 3 takes a slightly different approach 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

"

I think it is a very practical and grounded focus change.

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

Re: Scala 3.0

#148

Post by RobertKerans »

amw-zero wrote: post #122
namelosw wrote: post #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…

Can you elaborate on the changes in TS that hint at dependent types? That's interesting.

[edit, not quite what GP was referring to, but] At the minute, via [depending on context] a combination of generics/conditional types, unions/literals, type constructors, and [more recently] string templating you can get close in certain circumstances. It tends to be very fiddly though, and [IME] it's quite easy to cause TS to stop narrowing types properly. Someone else with more experience may be able to weight in -- despite using it for a few years I'd not really bothered to exercise some of the more expressive parts of the system until string templating experiments started popping up last year.

This issue thread on the TS repo may be of interest:

https://github.com/microsoft/TypeScript/issues/33014

Re: Scala 3.0

#149

Post by nwsm »

blandflakes wrote: post #131
haolez wrote: post #111

I'm in need of a functional language for a small part of my system and I'm considering Scala and Purescript[0] (mostly because of their ecosystems). Maybe Scala 3 is a good time to be boarding Scala's ship. I'd appreciate if anyone has any advices of one vs the other. [0] https://www.purescript.org/

Are you considering them together, or against one another? I'd have considered Purescript, which compiles to javascript, to compete with Scala.js, but I hadn't realized (but now do) that purescript has a serverside component as well.

JavaScript has Node and Deno? Not sure the point you're making about serverside.

Re: Scala 3.0

#150

Post by stickfigure »

growse wrote: post #81
crucialfelix wrote: post #72

Earlier quoted context omitted.

I use it in Typescript often. Very useful. type Verb = 'GET' | 'POST' | 'PUT' | 'DELETE'; export type TerminusType = 'ICAO' | 'IATA' | 'LOCODE' | 'ADDRESS' | 'LATLNG'; It's much better than just assuming it's a string and hoping you don't make a typo. If the value is supplied from user input then it ensures that you write checks or switch cases.

> I use it in Typescript often. Very useful. > type Verb = 'GET' | 'POST' | 'PUT' | 'DELETE'; > export type TerminusType = 'ICAO' | 'IATA' | 'LOCODE' | 'ADDRESS' | 'LATLNG'; > It's much better than just assuming it's a string and hoping you don't make a typo. > If the value is supplied from user input then it ensures that you write checks or switch cases. Conceptually, how is this different to an enum?

Conceptually, it's very much like an enum. Except that you can't enumerate them at runtime because there is no runtime representation. This can be very frustrating.

There's a hack, it looks like:

    export const VERBS = ['GET', 'POST', 'PUT', 'DELETE'] as const;
    type VerbTuple = typeof VERBS;
    export type Verb = VerbTuple[number];
A real enum would be better, but would violate the "typescript is just javascript" rule.
Post reply on HN