81–90 of 265 posts
Really excited about this. This is another reason why Scala is an extremely valuable tool these days. With Scala JVM, Scala.js with React Native and now with Scala Native (LLVM), there'll be literally nothing you can't do well with it.
Earlier quoted context omitted.
Much to the Scalaz crowd's dismay, Scala always was an ML first and foremost. Any similarity to Haskell is incidental to Haskell/ML's shared background in strongly typed functional programming.
Incidental? It's pretty well known that Scala was heavily influenced by Haskell. In particular, do notation (for comprehensions), pattern matching, lots of standard lib classes (ex Maybe (Option)), many of the methods in the collections library (map, fold, take, etc) Anyway, I wasn't trying to disparage either of them (or this project). Just poking fun at the seemingly common "I want to use Haskell but I'm forced to…
Except that Martin Odersky himself has explicitly said that the primary influences were SML/OCaml and Java.
> In particular, do notation (for comprehensions),
I'll give you that one
> pattern matching
Which pre-date Haskell by nearly 2 decades in ML
> lots of standard lib classes (ex Maybe (Option)),
Also pre-date Haskell by nearly 2 decades, in addition to be named exactly the same as ML.
> many of the methods in the collections library (map, fold, take, etc)
Which pre-date Haskell by almost 4 decades with origins in LISP.
> Just poking fun at the seemingly common "I want to use Haskell but I'm forced to deploy on the JVM" use case for Scala.
Which is where the Scalaz folks come in. They want to piggy back off of something successful, as opposed to Frege, which is closer to what they actually want (avoiding success at all costs?). Who knows, maybe they actually like the strict-evaluation by default of Scala/ML, which is quite pragmatic, but definitely more in line with ML than Haskell.
Earlier quoted context omitted.
No, not really. Some people from losing ecosystems like to spin it that way¹, but the truth is people are happy, adoption is great, and companies see that pain-points get addressed. Of course there are companies which drop Scala, but often like in LinkedIn's case it's not caused by a dissatisfaction with Scala, but new leaders making different decisions like "we are using 10 different languages, we should consolidate…
I know for a fact LinkedIn dropped Scala because of dissatisfaction over Scala. Things like maintainability, the fact it was just a single company developing Scala, etc that caused them to switch away. Kafka is deprecating their Scala clients because of maintainability issues as well. Scala keeps making breaking changes on dot releases, making it impossible to maintain long term.
Scala is developed by the EPFL, Lightbend, and ScalaCenter. That's three, not one.
> Scala keeps making breaking changes on dot releases, making it impossible to maintain long term.
That hasn't been true for more than half a decade.
Earlier quoted context omitted.
Do you see any possibilities to undo/mitigate JVM-specific design decision which handicap the language? For example could you not erase generics or would that cause too much problems incompatibilities?
Idiomatic Scala doesn't care at all about erased generics. With implicits and macros and libraries built upon them like shapeless, you can do everything you'd want to do with reified generics and more and it'll be done and statically checked at compile time instead of dynamically at run time.
def erased[T](xs: List[T]) : String = {
xs match {
case ns : List[Int] =>"Natural numbers"
case fs : List[Double] => "Floating point numbers"
case _ : List[T] => "Something else"
}
}
System.out.println(erased(List(1,2,3)))
System.out.println(erased(List(1.0,2.0,3.0)))
So, is this "released" yet? There are no downloadable installers or even instructions to compile.
Earlier quoted context omitted.
Much to the Scalaz crowd's dismay, Scala always was an ML first and foremost. Any similarity to Haskell is incidental to Haskell/ML's shared background in strongly typed functional programming.
Incidental? It's pretty well known that Scala was heavily influenced by Haskell. In particular, do notation (for comprehensions), pattern matching, lots of standard lib classes (ex Maybe (Option)), many of the methods in the collections library (map, fold, take, etc) Anyway, I wasn't trying to disparage either of them (or this project). Just poking fun at the seemingly common "I want to use Haskell but I'm forced to…
Is it documented anywhere that this was inspired by Haskell? To me, Scala for comprehensions seem syntactically more like a generalization of Python comprehensions than Haskell's monadic do notation.
Earlier quoted context omitted.
Looks like it's currently using the Boehm–Demers–Weiser conservative garbage collector. In scala-native/rtlib/src/main/resources/rt.cpp it includes gc.h and allocates memory using GC_malloc, i.e. not in precise mode.
Ouch.
Earlier quoted context omitted.
> just like ScalaJS made you need entirely new Scala libraries that did not use reflection. Most Scala libraries never used reflection, so most of the ecosystem "just worked" on Scala.js. I think quite a few things in scala-native are there to show the possibilities of this platform, but in the mid- to long-term those improvements will be supported everywhere: - @struct and AnyVals: As soon as AnyVals can support mor…
> Most Scala libraries never used reflection, so most of the ecosystem "just worked" on Scala.js. Do you have personal experience with this? I do not have hard numbers, but for me - basically none of my stack worked. I had to find a new JSON parser. I had to find new validation for my form stuff. Etc. etc. It wasn't impossible, but it was a lot of work.
Earlier quoted context omitted.
Note: I use Scala in my day job. I consider it better than Java, but worse than other languages. I definitely agree that all languages accumulate compromises and inelegant hacks as they evolve. It's unavoidable. That said, in my opinion Scala's blunders are many. You can find out about many of them from Paul Philips, ex committer of Scala, but if he sounds too bitter to you (he does to me; at this point he sounds lik…
> all languages accumulate compromises and inelegant hacks as they evolve. It's unavoidable. Scala devs deprecate and remove things that haven't worked out well. They have an established track record of making these migrations easier with each release. > Null Upcoming versions will make references non-nullable by default. If you want things to be nullable, you will have to opt-in explicitly with T|Null. > - Type infe…
I can see how the opt-in null references might help prevent you from writing Scala code that uses null, but how does it help when interacting with Java code?