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

81–90 of 292 posts

Re: Scala 3.0

#81

Post by growse »

crucialfelix wrote: post #72
cutler wrote: post #32

Earlier quoted context omitted.

Sounds like more Scala sophistry. I thought they were supposed to be aiming for pragmatism with Scala 3.

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?

Re: Scala 3.0

#82

Post by a_humean »

AzzieElbab wrote: post #54
maxov wrote: post #17

Earlier quoted context omitted.

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…

TS is great but lack of pattern matching cripples the language somewhat

The tc39 pattern matching proposal seems to have some renewed energy with new champions (including from the typescript team) and syntax proposals:

https://github.com/tc39/proposal-pattern-matching

Also there has been movement in the user land space with libraries like ts-pattern that make use of new features in typescript 4.x to provide basically the full pattern matching experience:

https://github.com/gvergnaud/ts-pattern

Re: Scala 3.0

#83

Post by vaylian »

halayli wrote: post #80

looking at the all time contributors, it further solidified my belief that a team of 2 to 3 solid engineers can almost take on any project that comes their way.

Given enough time

Re: Scala 3.0

#84

Post by dtech »

valenterry wrote: post #78
geodel wrote: post #75

Earlier quoted context omitted.

From their blog: > After 8 years of work, 28,000 commits, 7,400 pull requests, 4,100 closed issues – Scala 3 is finally out. Since the first commit on December 6th 2012... I mean it is lot of work for sure. But is it such a fast pace?

It is. Scala does not use semver. The last major release was 2.13.0, not 2.0.0. That's a bit confusing I guess. What that means is, they haven't just added some features, they redesigned/rewrote to language from ground up to simplify it and make formally sound. I actually don't know any other language that does that (though I'm sure there are others, maybe Haskell is one of them). In addition, a lot of features are v…

they switched to semver starting with Scala 3. They intend to remain compatible throughout 3.x.

Re: Scala 3.0

#85

Post by cage433 »

jim-jim-jim wrote: post #45
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).

> Scala is not perfect but it’s very good. I like to refer to it as Haskell with an extra chromosome: slow, hard to comprehend, and incredibly strong. I'm lucky enough to write it in my day job and I feel like I'm living life on easy mode because of it. It'd take a lot of money to lure me back to garbage like Python/JS at this point.

> I like to refer to it as Haskell with an extra chromosome: slow, hard to comprehend, and incredibly strong.

that's a weird and offensive thing to say

Re: Scala 3.0

#86

Post by brabel »

kjaer wrote: post #77
wiradikusuma wrote: post #68

I can't find this anywhere, maybe someone could help answer: 1. How much better is the performance? (In terms of compilation speed, and runtime) 2. Compatibility with Graal Native?

Graal Native takes JVM bytecode as input, and Scala 3 is binary compatible with Scala 2, so it should be compatible with Graal Native out of the box.

Does Scala 3 not advance the capabilities of Scala Native, making GaalVM unnecessary (if still an option) for running Scala without the JVM?

Re: Scala 3.0

#87

Post by acjohnson55 »

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?

It can be used as an enum and might be more convenient in places where you don't need to bother converting between string data outside the system and enum data types.

It also plays nicely with union types, so that you can very quickly define as hoc enums directly in your function declarations, which might be useful if there's only one or two usages of a particular enum, or a section of code where the allowable values very quickly changes.

You basically get a lot of expressiveness without boilerplate, which can be pretty convenient.

Re: Scala 3.0

#89

Post by acjohnson55 »

rtoway wrote: 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.
Post reply on HN