A Tour of Scala 3 - Martin Odersky

[@carnelyve866]

Amazing! Its time to come back to scala.

[@manfredw8725]

Glad they settled on "given" instead of "delegate" in the final version of Scala 3.

[@theStrategicRook]

There are 1 types of programmers in this world - those who love Scala and those who haven't coded in it.

[@zzantares]

Lot of great features that puts Scala towards the good direction, my only concern is compile times, with all this type-level trickery is time to shift again to focus on performance but in the compilers rather than the programs (as these are already fast).

[@abhishes]

18:55 I am really confused by the example on this slide. Why should we write a method which can take two complete arbitrary types and then do a case on it? it would be nice to just have two separate methods.

[@FrVle]

`id: Username | Password` means that the argument `id` is EITHER of type `Username` OR `Password`, so you only have 1 of 2 possibilities, if you create 2 arguments then you have a `Username` AND a `Password`. `Username | Password` is equivalent to Scala 2 `Either[Username, Password]` and pattern match on `Left` and `Right`. In Scala 3 open union types (the types with the pipe | ) are more flexible because you can have more than 2 arbitrary possibilities without predefining the type somewhere else

[@abhishes]

@@FrVle I understand what it is. I'm wondering WHY on earth will you write a function like that. Just have 2 functions.

[@FrVle]

@@abhishes because of the same reason you would use an "if" expression, control flow, there is uncertainty on the input, and you can manage that using Types so that the compiler helps you out

[@protaties]

@@abhishes The key difference between using union types and having 2 functions is that having 2 functions, which also known as function overload, is resolved at compile time. So which function is called have to be determined at compile time. But, using union types, it determines the clause at runtime, which provides you more flexibility.

[@DrewIsFail]

I'm in the same boat, it seems way cleaner to just have each piece of information go through it's own processing pipeline. It seems far to easy to accidently pass a string password to that and potentially have it end up somewhere unexpected. The responses here don't seem to account for context. There shouldn't be a context where data for the user name could get routed to the password, so no, you would never have a logical switch on password vs username.

[@JMROMERO95]

I'm not sure, I love Scala, but the main problems of the language are the ambiguity of implementation for developers (like where to use OOP or FP in the software and how to combine them correctly) and most importantly the absurdly long compile times, this are both the biggest issues with the language and maybe they're solved partially, but couldn't see that in the presentation at least, which is a little concerning. Still, love Scala, I hope it can grow as a language and every time less people trash it.

[@ElectronGuigui]

Regarding the long compile time, I believe that Bloop (scalacenter.github.io/bloop/) and/or newer build tools (Mill instead of SBT for instance) pretty much solve this problem.

[@Bizmonger]

I recommend using an imperative shell with a functional core. Shell: UI logic, Data Access Layer Core: Domain functions

[@mehrzadahmadian4078]

does oracle's jdk licencing affects future of languages like scala that runs on jvm? if we start to use scala in our commercial products, will we be able to run it free without getting into trouble with oracle?

[@myfear]

mehrzad ahmadian hey. There won't be a licensing issue if you use the right jdk. Make sure to check out Adoptopenjdk.net.

[@hgfuhgvg]

Will this work in union types? def foo(s:String):String = ... ; def foo(i:Int):String = ...; def bar(x:String | Int) = foo(x)

[@ZelenoJabko]

Tested - it does not.