Is Dotty the official compiler now?
Yes
Scala 3.0
11–20 of 292 posts
Re: Scala 3.0
#12I get paid to write TypeScript, it has come a long way to a relatively enjoyable experience compared to how expressive i feel with Scala. Looking forward to giving Scala 3 a spin to learn whats new
I was looking at dotty/scala 3 earlier in the year and I was quite surprised to see familiar friends from Typescript in the form of literal types and union types. val scala: "Scala" = "Scala" const typescript: "Typescript" = "Typescript" "Scala" | "Typescript"
I played with it a bit because I really like TS's union, literal types and smart-casting, unfortunately it doesn't seem quite there yet and I found it only usable for T | null types.
Syntax is all there so maybe it'll get better in 3.1+
Re: Scala 3.0
#13Earlier quoted context omitted.
I was looking at dotty/scala 3 earlier in the year and I was quite surprised to see familiar friends from Typescript in the form of literal types and union types. val scala: "Scala" = "Scala" const typescript: "Typescript" = "Typescript" "Scala" | "Typescript"
This creates two types with quotes in their type names, and then creates a union type of the two? Then the compiler needs to determine if the token's context requires a type or a value, and disambiguate accordingly? In the example above, the created type "Scala" is distinct from a type Scala, correct? I did some quick poking around for Scala literal types, but I found stuff like https://github.com/jeremyrsmith/litera…
No. It's a Singleton type, which means that instead of just being a String, it has to be exactly the String "Scala".
i.e.
val x: "scala" = "scala" // would compile
val y: "scala" = "java" // would produce a compile error
Union types are an orthogonal concept, and work as you'd expect:
val z: String | Int = "foo"
Re: Scala 3.0
#14> Fix typo in file name #12181
Tasty: set experimental to zero #12438
Ah key commits that you just know you have to bump the version up after receiving.
Re: Scala 3.0
#15Earlier quoted context omitted.
This creates two types with quotes in their type names, and then creates a union type of the two? Then the compiler needs to determine if the token's context requires a type or a value, and disambiguate accordingly? In the example above, the created type "Scala" is distinct from a type Scala, correct? I did some quick poking around for Scala literal types, but I found stuff like https://github.com/jeremyrsmith/litera…
No. It's a Singleton type, which means that instead of just being a String, it has to be exactly the String "Scala". i.e. val x: "scala" = "scala" // would compile val y: "scala" = "java" // would produce a compile error Union types are an orthogonal concept, and work as you'd expect: val z: String | Int = "foo"
Interesting, and I presume it works for singletons of any type, correct?
val x: 1 = 1
val y: 2.718281828 = 2.718281828
Re: Scala 3.0
#16Earlier quoted context omitted.
I was looking at dotty/scala 3 earlier in the year and I was quite surprised to see familiar friends from Typescript in the form of literal types and union types. val scala: "Scala" = "Scala" const typescript: "Typescript" = "Typescript" "Scala" | "Typescript"
This creates two types with quotes in their type names, and then creates a union type of the two? Then the compiler needs to determine if the token's context requires a type or a value, and disambiguate accordingly? In the example above, the created type "Scala" is distinct from a type Scala, correct? I did some quick poking around for Scala literal types, but I found stuff like https://github.com/jeremyrsmith/litera…
Literal types quite simply means that values are types. For example in TypeScript the literal type "Foo" is a special string type, where the only valid value is the literal "Foo" – assigning "Bar" to a variable with the type "Foo" is a compile time type error. Literal types can be combined into union types like any other type.
Re: Scala 3.0
#17I get paid to write TypeScript, it has come a long way to a relatively enjoyable experience compared to how expressive i feel with Scala. Looking forward to giving Scala 3 a spin to learn whats new
As someone who has spent a lot of time diving deep into Scala (I worked on compiler related semantic tooling for scalameta, worked on a experimental parallelizable Scala compiler, and even have a single commit in this release from almost four years ago LOL), and who more recently has been working with TypeScript, I find this really interesting and agree in some ways.
Scala 2.x already had path-dependent types, which combined with implicits and type inference were technically sufficient to implement versions of of the dependent function types we have now in 3.x. In my opinion, how you did this previously could get really clunky (See e.g. hlist mapping in https://github.com/milessabin/shapeless/blob/8933ddb7af63b8b...). Lots of things that frankly felt like casting magic spells, and there were sometimes fragile and weird bugs especially with how implicits were resolved, see e.g. https://github.com/scala/scala/pull/6139.
The native type-level meta-programming coming in 3.x along with a lot of streamlining of the underlying type system and implicit resolution rules (e.g. https://github.com/lampepfl/dotty/pull/5925) could help a lot. This is just one example of a more advanced feature, but there are lots of things like this that changed in Dotty (maybe the most interesting is the DOT calculus that makes a better backbone for the type system). I don't know what tooling for Scala 3.x looks like, but even Intellij's frankly amazing Scala plugin broke down sometimes for 2.x.
After using TypeScript, I just personally enjoyed the experience better. Technically Typescript's type system is equally as powerful as Scala's, but the primitives for expressing more complicated types just seem much easier compared to the path-dependent stuff you would need to do in Scala. I was amazed to find stuff like this https://github.com/aws-amplify/amplify-js/blob/dedd5641dfcfc... in mainstream wide usage. I'm not even sure how you could write these type of transformations as well in any version of Scala. I suppose maybe records work, or in this specific case there are functional patterns that are preferred.
Caveat, I haven't followed Dotty for a couple years now, so I could be missing a lot. Regardless, I have really enjoyed the tooling around Typescript as well as the design. The real-world usage of more complicated dependent types (and there are good uses IMO) have been more fluent and easier to understand, and less dependent on tricky behavior like for implicits. VS Code's tools are really magical, and I hope with some of the amazing underlying work done in Dotty the Scala developer experience could look more like that.
Re: Scala 3.0
#18Earlier quoted context omitted.
No. It's a Singleton type, which means that instead of just being a String, it has to be exactly the String "Scala". i.e. val x: "scala" = "scala" // would compile val y: "scala" = "java" // would produce a compile error Union types are an orthogonal concept, and work as you'd expect: val z: String | Int = "foo"
Interesting, and I presume it works for singletons of any type, correct? val x: 1 = 1 val y: 2.718281828 = 2.718281828 That's kind of cute. I presume its main purpose is for overrides in order to get something similar to template specialization. C++ templates can be specialized by types and by values, but Scala method overrides are only by type, and literal types allow you to present a value as a type, so if the valu…
In TypeScript perhaps the most important use case for literal types is the ability to to create discriminated unions, or algebraic datatypes (ADTs). Many modern languages have a separate feature for this (such as enums in Rust), but in TypeScript they can be constructed using literal and union types. Here's an example:
interface ProductOffer {
kind: 'productOffer'
eans: Ean[]
discountPercentage: number
}
interface GroupOffer {
kind: 'groupOffer'
groups: GroupId[]
discountPercentage: number
}
type Offer = ProductOffer | GroupOffer
Re: Scala 3.0
#19Always wanted to look into Scala but it seemed very intimidating. Is there a good intermediate 'How to' for Scala 3 anyone can recommend?
Re: Scala 3.0
#20[deleted]