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

121–130 of 292 posts

Re: Scala 3.0

#121

Post by amw-zero »

sesm wrote: post #119

So, they removed implicits and introduced a number of other tools to replace common usecases for implicits. Can we take a step back now, and reflect on what was the original problem implicits were designed to solve and how it is solved now in Scala 3? I've heard the original problem was that they wanted a chain of functional transformations to return the same type of collection (unlike, say, Clojure or Java 9 which r…

I still don't fully understand it, but they wrote a lot about the topic here: https://dotty.epfl.ch/docs/reference/contextual/motivation.h...

Re: Scala 3.0

#122

Post by amw-zero »

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.

Re: Scala 3.0

#123

Post by rnikander »

esarbe wrote: post #114
rnikander wrote: post #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

With dependent types, each `e.key` has it's own and separate type. So, if you have two `e`s, the type of the first e's key will not match the type of the second e's key. So, with: def process(p: Path, key: p.Key): Something = ??? this will not compile: val p1: Path = ??? val p2: Path = ??? process(p1, p2.key) <- compile-time-error

Interesting. Thanks!

I've been using a lot of Swift lately, and they have a generic type roadmap that talks about "existential types" and being able to "open" an existential. This looks very similar.

Re: Scala 3.0

#124

Post by amw-zero »

meatmakesdumb wrote: post #96

Personally I'm looking forward to scala native 1.0 more than anything else. We'll have a strong Haskell competitor. I dont like jvm.

How is current Scala not actually a Haskell competitor today? Superficial dislike of a VM isn't a valid reason.

Re: Scala 3.0

#125

Post by pjmlp »

xfer wrote: post #79
isbvhodnvemrwvn wrote: post #22

Earlier quoted context omitted.

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

Kotlin doesn't sound like a good language to bet on since most suitable(for jvm) features it has will be integrated by Java now that it has picked up pace. I guess it only has decent marketshare because of google's android support(they are throwing stuff on the wall to move away from Oracle IP i guess) and Jetbrains being very popular among java devs.

That story regarding Kotlin and Oracle doesn't sell because unless Google rewrites Android toolchains in Kotlin/Native, there is plenty of JVM infrastructure to deal with, and so far there haven't been signs to fully replace Android Java.

The sour grapes of the Kotlin/Android marriage is that going forward one will need KMM for code between JVM and ART, or be happy to just use what ART undestands.

Re: Scala 3.0

#126

Post by zeec123 »

It is so bad, that in julia functions are not first class. Instead, I would love to use scala 3 for machine learning since this is the perfect type system for such a task, but linear algebra support is not good enough.

Re: Scala 3.0

#127

Post by crucialfelix »

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?

An Enum in ts is weird. It's not just a type, it's something compiles to something in the runtime.

So to use the value you have to import the Enum and use that.

const handlers = { '/': { Verbs.GET: () => .... Verbs.POST: () => ...

Whereas:

const handlers = { '/': { GET: () => .... PAWST: //nope! must be one of GET | POST | PUT | DELETE

Basically it's a lot less work and you don't need to import the enum and maintain it.

Re: Scala 3.0

#128

Post by halfmatthalfcat »

sesm wrote: post #119

So, they removed implicits and introduced a number of other tools to replace common usecases for implicits. Can we take a step back now, and reflect on what was the original problem implicits were designed to solve and how it is solved now in Scala 3? I've heard the original problem was that they wanted a chain of functional transformations to return the same type of collection (unlike, say, Clojure or Java 9 which r…

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.

Re: Scala 3.0

#129

Post by amw-zero »

MrPowers wrote: post #70

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…

> Make it clear what libraries are recommended for certain tasks

I think no community has this problem solved, and I also think it is unsolvable unfortunately. The need to experiment seems to be human nature, and we are still really terrible at designing for code reuse, so small, subtle feature differences often require a totally different interface / library.

I don't disagree with the desire to solve this problem, I just think it's completely unrealistic and not rooted in reality. It reminds me of when people say "we should make this simpler."

Yes, that's a great goal, and one that is easy to say but not easy to achieve.

Re: Scala 3.0

#130

Post by halfmatthalfcat »

isbvhodnvemrwvn wrote: post #22
killingtime74 wrote: post #9

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.

I was waiting for this comment. Every single thread about Scala has someone pushing this narrative that Kotlin is the real arbiter of change when it really has been Scala the entire time pushing boundaries on the JVM.

Kotlin is great and if you want a cleaner Java experience, by all means use it but Scala is real champion in pushing many, many things into the mainstream.

Post reply on HN