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

221–230 of 292 posts

Re: Scala 3.0

#221

Post by Scarbutt »

flurdy wrote: post #117
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/

I wouldn't jump on the Scala 3 ship just yet. Maybe if mostly a learning project but not for an important part. Whilst it was not a surprise release there will be long time until a majority of the libraries and frameworks will also work with it. The big ones are mostly there, but there are lots of smaller ones that are not and there will be teething problems, even after a long alpha-beta-rc train. Scala 2.13 is still…

Looks like many libs already support Scala3: https://index.scala-lang.org/search?targetTypes=jvm&scalaVer...

Re: Scala 3.0

#222

Post by emergentorder »

zeec123 wrote: post #195
emergentorder wrote: post #181

Earlier quoted context omitted.

Check out my project NDScala ( https://github.com/SciScala/NDScala ). N-dimensional arrays in Scala 3. Think NumPy ndarray, but with compile-time type-checking/inference over shapes, ndarray/axis labels & numeric data types.

Thanks. Does it map to native routines like numpy? If yes, what about the copy overhead from JVM to native memory?

Yes, it uses ONNX Runtime / MLAS (their native BLAS lib) under the hood. And yes, there is copy overhead but you can eliminate it internally to a single function/graph by compiling it down to a single ONNX model. The end result is within ~15% run time of PyTorch w/ MKL when training a reasonably-sized MLP. And ORT also provides support for CUDA and a number of other "execution providers".

Re: Scala 3.0

#223

Post by nikitaga »

patrickthebold wrote: post #199
OOPMan wrote: post #170

Earlier quoted context omitted.

That's an interesting take, as someone that's used Scala for a while I feel like there actually isn't that much syntax. I guess my perception is warped :-)

Scala has a lot of 'sugar': f(...) becomes f.apply(...) matching calls unapply with some various binding. Some parenthesis are optional: Some(1,2,3) is Some((1,2,3)) optional . so a + b is a.+(b) colon changes associativity, so a +: b is b.+:(a) for expressions become, map, flatMap, filter, withFilter and forEach, according to various rules. def f[A: B]() adds an implicit parameter of type B[A] I'm sure there's more…

The fact that you can make any instance callable like a function by adding an `apply` method to it isn't just "syntax sugar", it's a pretty fundamental mechanic of FP-OOP fusion that Scala is built around. Same for `unapply`.

At any rate none of this "sugar" was a problem to anyone I know who learned Scala. There are harder things about it than learning basic syntax.

Re: Scala 3.0

#224

Post by eweise »

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

There's some weird history there. For most of the project's existence, Scala 3 was known as Dotty. It was basically a research project, and it was recognized from the beginning that it was a different language than Scala, largely due to the type system semantics...the goal being a formally defined, fully sound type system (Scala had some edge cases that made it not sound, even if it was more sound than most languages…

Not sure that's correct. I remember going to a talk around 2013 with Odersky and got the impression that dotty would be the future scala.

Re: Scala 3.0

#225

Post by _old_dude_ »

pron wrote: post #115
_old_dude_ wrote: post #112

Earlier quoted context omitted.

> ML is probably the biggest influence I disagree. Java records are from Standard ML but sealed is not, it's from Scala with the improvement that subtypes of a sealed types are sealed too. Java still not have a real syntax for ADT, Standard ML has datatype, Rust or Scala 3 have enums on steroid [1]. [1] https://dotty.epfl.ch/docs/reference/enums/adts.html

Java records and sealed types are its interpretation of product and sum types, and, true, this interpretation draws inspiration from Scala's. Deconstructing patterns are coming soon, but Java now does have real syntax for ADTs: sealed interface Expr {} record ConstantExpr(int i) implements Expr {} record PlusExpr(Expr a, Expr b) implements Expr {} record TimesExpr(Expr a, Expr b) implements Expr {} record NegExpr(Exp…

Ok, it's perhaps a true Scotsman argument but saying that Java as a syntax for ADT is like saying JS (pre 2015) has classes because it can be simulated by function + prototype or that Java (pre 8) has lambdas because it can be simulated by anonymous classes.

Java misses the syntactic sugar to define ADT in one place like in Standard ML, OCaml or F#.

The closest you get is to declare records inside a sealed interface, but once you add generics in the mix, it starts to get messy.

I was not able to define a classical list with cons and nil in Java.

  sealed interface List {
    record Cons(T car, List cdr) implements List {}
    record Nil() implements List {} 
  }
The compiler give you warnings, Cons or Nil are not a top level type and you can create several instances of Nil.

Re: Scala 3.0

#226

Post by saiojd »

eigenspace wrote: post #217
zeec123 wrote: post #161

Earlier quoted context omitted.

It means I cannot fully specify the type of function my interface expects as an argument. A function is of type ‘Function’. There is no way to define it with the type of its argument or the type of what it returns.

Actually, Julia functions are all subtypes of Function. Every julia function has a unique type. We don't parameterize a function by it's input and return types because functions are extremely polymorphic in julia. However, there's lots of tricks one can do to dispatch on whether or not a given function have methods that satisfy some sort of interface, see here: https://github.com/oxinabox/Tricks.jl#we-can-use-static_…

Functions are polymorphic in many languages that let you annotate the their types. The concern is not really for dispatch here, it's for readability/correctness.

Re: Scala 3.0

#228

Post by nine_k »

zug_zug wrote: post #167

Cool I guess. I just notice that say, unlike PHP, I don't know if there's a single thing in the scala 3.0 release I care about (as somebody who's preferred language as scala) [Edit: Except for fixing implicits, big win]. A lot of times it feels like it's a language with so much potential which then misses some basic real-world use-cases for the 99% who couldn't care less about covariant blah blah, and just want a cle…

It just so happens that "reliable, reusable" and "covariant blah" are interlinked — if you want any form of type inheritance, of course (which I usually don't).

Re: Scala 3.0

#229

Post by eigenspace »

saiojd wrote: post #226
eigenspace wrote: post #217

Earlier quoted context omitted.

Actually, Julia functions are all subtypes of Function. Every julia function has a unique type. We don't parameterize a function by it's input and return types because functions are extremely polymorphic in julia. However, there's lots of tricks one can do to dispatch on whether or not a given function have methods that satisfy some sort of interface, see here: https://github.com/oxinabox/Tricks.jl#we-can-use-static_…

Functions are polymorphic in many languages that let you annotate the their types. The concern is not really for dispatch here, it's for readability/correctness.

> The concern is not really for dispatch here, it's for readability/correctness.

Then dispatch to an error.

Re: Scala 3.0

#230

Post by pron »

_old_dude_ wrote: post #225
pron wrote: post #115

Earlier quoted context omitted.

Java records and sealed types are its interpretation of product and sum types, and, true, this interpretation draws inspiration from Scala's. Deconstructing patterns are coming soon, but Java now does have real syntax for ADTs: sealed interface Expr {} record ConstantExpr(int i) implements Expr {} record PlusExpr(Expr a, Expr b) implements Expr {} record TimesExpr(Expr a, Expr b) implements Expr {} record NegExpr(Exp…

Ok, it's perhaps a true Scotsman argument but saying that Java as a syntax for ADT is like saying JS (pre 2015) has classes because it can be simulated by function + prototype or that Java (pre 8) has lambdas because it can be simulated by anonymous classes. Java misses the syntactic sugar to define ADT in one place like in Standard ML, OCaml or F#. The closest you get is to declare records inside a sealed interface,…

> Java misses the syntactic sugar to define ADT in one place like in Standard ML, OCaml or F#.

I don't think so.

> I was not able to define a classical list with cons and nil in Java.

If you want to restrict Nil to a single instance, don't make it a record class:

    sealed interface List {
      static  List cons(T car, List cdr) { return new Cons(car, cdr); }
      static  List nil() { return (List)Nil.INSTANCE; }

      record Cons(T car, List cdr) implements List {}
      enum   Nil implements List { INSTANCE }
    }
You can statically import if you mind them not being "top level":

    import static List.*;
And then write, say:

    var x = cons("a", nil());
    var y = cons(1, x);
Not as succinct as ML, but workable.

Although, in this particular case,

    record List(T car, List cdr){}
would suffice.
Post reply on HN