10 ms·

I've always loved Scala and Scala 3 is shaping up to be extremely exciting. Love the new ADTs and braceless syntax: really gives the language a cleaner and more

by smabie 6y ago

I've always loved Scala and Scala 3 is shaping up to be extremely exciting. Love the new ADTs and braceless syntax: really gives the language a cleaner and more ML inspired feel. No other conventional language (including OCaml, F#, etc) seem to have the effortless kind of power Scala does. The combination of the extremely powerful type system with the "OOFP" paradigm is a great combination. OOFP is such a great paradigm and it's unfortunate that no other language has embraced it. It's ironic that I love Scala so much because I don't particularly enjoy dealing with the JVM and all its complexities and problem. But Scala is so good that it mostly makes up for it. Scala does get a lot of hate (especially around here), but I've never really understood why. There's only one language I like more (kdb+/q), but that's a hard sell, especially because of the cost. Too bad there's not really a ML/AI ecosystem around (besides Spark, which seems to be losing favor partially because of its embarrassing performance), because using Python is such a drag. However, I do understand why non-CS/type theory people might find the language intimidating. But to that I'd say, I've seen new junior (though very smart) developers with no Scala or FP experience get onboarded and write idiomatic Scala code within a couple weeks to a month. The short term cost is more than worth it considering the absurd productivity compared to Java/Kotlin/Python/blublang. Compared to OCaml/F#/Haskell, the improvement is a little less stark, though still clear imo (especially when considering editor tooling and available packages).

TeeWEE 6y ago
For me scala's feature set is absurdly big and there are always 10 ways todo things. Look at the spec of Scala. Its 200 pages long. That's insane. I'd rather use Kotlin.
- pjmlp 6y ago
  Yep, https://arrow-kt.io/ https://arrow-kt.io/ Just give it a couple of more years.
- mbo 6y ago
  The Kotlin spec is... 275 pages: https://kotlinlang.org/spec/pdf/kotlin-spec.pdf https://kotlinlang.org/spec/pdf/kotlin-spec.pdf
  - zaphirplane 6y ago
    Yeah but the font ;)
  - aphexairlines 6y ago
    And 796 pages for Java https://docs.oracle.com/javase/specs/jls/se14/jls14.pdf https://docs.oracle.com/javase/specs/jls/se14/jls14.pdf
- rgoulter 6y ago
  > For me scala's feature set is absurdly big and there are always 10 ways todo things. One of my favourite examples: of these 13 different ways of doing the same thing, only 12 are correct. https://nurkiewicz.github.io/talks/2014/scalar/#/22 https://nurkiewicz.github.io/talks/2014/scalar/#/22
  - valenterry 6y ago
    How is that a bad thing? It's the same in other languages and it is nice to have some flexibility. E.g. lisp: use whichever type of parentheses you want Or Kotlin: use short syntax lambdas fruits.filter(it == apple) or long syntax fruits.filter(fruit -> fruit == apple) or with annotated types: fruits.filter{fruit: Fruit -> fruit == apple} Sometimes brevity is good for the reader, sometimes more details are good for the reader. Not everything is a nail.
    - misja111 6y ago
      The flexibility is perfectly fine when you're programming something on your own. But when you're in a team, or worse, in a large company, it starts to be a problem that everyone can use their own style. It's much easier to read someone else's code when you have a common code style. And in Scala there are not only many different ways to use the standard libraries or to structure your code, there is a pure FP vs OOP-style FP schism as well. Because of this, you can qualify as a senior Scala developer for one job but only a junior in another.
      - valenterry 6y ago
        The opposite. If I write code on my own just for myself I use the highest level of brevity. But if I write code for a team, then in some places I will use explicit type annotations and variable names to aid people unfamiliar with the code to understand what's going on. What you are saying is pretty much "it's easier when everyone only uses nails, because then all I have to bring is a hammer". I think it's good to use screws sometimes. However, your second point I agree with. OOP vs. FP is a different story. This is about paradigms not about mere syntax. So here, a team must be aligned, which can be a challange when using Scala. It's not a language for corporate drones.
- trumpeta 6y ago
  IIRC one of Odersky's stated goal for Scala 3 was to address exactly this issue. That being said, it is developed in a research setting so I guess even if they restrict these features now, there will be new ones added over time...
  - vvillena 6y ago
    Scala has always been an opinionated language. The main difference is that this time is holding opinions against itself. Previously, opinions were held against Java, that's why there are features such as case classes, traits, and immutability by default. They answer to Java problems. Scala is now mature enough that some issues have emerged. Typeclasses are cool, but programming typeclasses in Scala is a bit clunky. The type system is very powerful, but it could be even more powerful and that would actually help people write simpler code. And there are a bunch of unused features that could be removed. This is what Scala 3 is about.
- aliakhtar 6y ago
  This is like saying, airplanes are too complex. There are so many knobs and buttons. I'd rather just walk or ride a bike everywhere. Scala is a very powerful, very expressive language. There are some features which you can just choose to leave out. If you do, you end up with a very clean, concise, and powerful language that makes you really productive. I've literally had moments where I made my algorithm 5x faster just by adding 4 letters: '.par' in front of an operation. Instantly it got parallelized without my having to do anything, and the processing time got cut 5x.
  - tastyminerals2 6y ago
    And that's why there are far fewer pilots in this world than stewards.
  - TeeWEE 6y ago
    Its more like saying: I need to cut some paper ( i need to program): Swiss army knifes (scala) are too complex, I just need a pair of pair of scissors (lisp / other languages).
    - aliakhtar 6y ago
      Scala really isn’t that complex though. It’s actually pretty intuitive. You CAN write bad and hairy scala code just like you can in any language. But that doesn’t mean the language is to blame.
- pkolaczk 6y ago
  Having switched from Scala to Python recently, I must say Python has probably 5x more ways to do things than Scala and I can't see people complaining on Python's complexity. This is something that really surprised me, because "one obvious way " was announced to be a part of Zen of Python.
  - nsonha 6y ago
    and 0 way to do a lot of things
- esarbe 6y ago
  Scala 3 tries to be more opinionated and goes quite some miles (kilometers?) to make the language more regular and simple. The implicits are gone, for example. Kinda crazy, since it was Scala's banner feature for so long. For the primary use-cases of implicits (extensions, type classes, conversion, ...) there are now language level concepts to make these use-cases accessible. "Intent over mechanism" I think Martin calls it.
codeviking 6y ago
I really enjoyed writing Scala code. I'd agree with your evaluation with respect to the expressiveness and power provided by the language. ...but the tooling, at least at that time, was terrible. SBT was terribly overcomplicated, and full of foot-guns. I spent far too much time debugging dependency collisions, issues created by so-called "autoplugins" and other nuances that had nothing to do with getting real work done. Now I'm writing a lot of Go. I'll admit, it's not nearly as fun to write. There's a lot less creativity and expressiveness -- though I think this is probably a good thing. But it also feels like I'm getting a lot more stuff done, and the tooling is amazing.
- tlarkworthy 6y ago
  I use maven to compile Scala.
- lmm 6y ago
  SBT is a fractal of awfulness and I have no idea why anyone ever uses it. But it's never been required. Just use maven and get on with your life.
  - nsonha 6y ago
    cbt and mill are just obvious scala code
    - lmm 6y ago
      How's their IDE integration? (Though TBH I'm coming from a starting point of "Maven isn't broken, there's no need to fix it")
      - nsonha 6y ago
        for mill intelij and vscode via the metals extension
  - cryptos 6y ago
    Yes, SBT is just terrible! It is the reference for usability nightmare in the category build tools.
moonchild 6y ago
> only one language I like more (kdb+/q), but that's a hard sell, especially because of the cost J? It's not quite the same, but is OSS.
thirtyseven 6y ago
> Too bad there's not really a ML/AI ecosystem around (besides Spark, which seems to be losing favor partially because of its embarrassing performance) Compared to what? If you mean engines like Presto, I would say they have different use cases, plus Spark SQL puts them roughly in the same ballpark. Genuinely curious though, as a Spark user that is always interested in alternatives.
- smabie 6y ago
  kdb+/q performance smokes Spark. Actually. most native code on a single machine smokes an entire Spark cluster.
superyesh 6y ago
>Too bad there's not really a ML/AI ecosystem around (besides Spark, which seems to be losing favor partially because of its embarrassing performance), because using Python is such a drag. Even if Spark might not be the best tool for ML, it is still the tool to beat for data processing and custom ETL.
newhkusers1 6y ago
Scala deserves all the hate. It might be a fun language for a throwaway pet project but I'd never recommend it in an enterprise setting. It's an extremely unproductive language because it's too flexible. There are so many different ways to do the same thing which introduces unnecessary complexity.
- hocuspocus 6y ago
  Yet plenty of big companies manage to ship software written in Scala just fine.
willtim 6y ago
I am skeptical about the novelty of Scala's "OOFP" as you put it. It looks essentially the same as the original anonymous classes or SAM types in Java. Function values are objects with a single method and methods themselves are not first-class, but are wrapped in objects as required. The most important part of OO are the first-class modules; and in the literature, arguably more elegant examples of unifying first-class modules and FP exist, for example by starting with FP and adding objects as records containing functions, this way both "objects" and methods would be first-class. Subtyping also adds significant complexity to the language and weakens type inference. Scala is, first and foremost an OO language which embraces subtyping, class hierarchies and imperative programming, see for example its own collections library. As Java gets more and more FP features, there is a danger it will struggle to differentiate itself.
- sjrd 6y ago
  Your comment makes sense if we think of FP as being about "function values". In a world where all sorts of programming languages have function values, this is not a strong enough characterization anymore (if it ever truly was). Functional programming is about programming with immutability first. So OOFP is about immutable objects. I go even further to say it is about objects with immutable interfaces, but the implementations can be imperative as long as encapsulation hides the mutable aspects from the user of the object. This is what you see in Scala's collections library: we use mutability inside the implementation but we expose an immutable API. I gave an entire talk on that very topic at Scala Italy in 2019: https://vimeo.com/362001027 https://vimeo.com/362001027
  - willtim 6y ago
    > Functional programming is about programming with immutability first. I completely agree with this. So perhaps I am being rather hard on Scala.
- kitd 6y ago
  It looks essentially the same as the original anonymous classes or SAM types in Java. Decompiling a Scala .class file shows just how true this is.
barry27 6y ago
Scala is awesome. It gets a lot of hate around here because many of the users of this site are Super Intelligent and Could Have Done It Themselves, Only Better.
JD557 6y ago
> Too bad there's not really a ML/AI ecosystem around (besides Spark, which seems to be losing favor partially because of its embarrassing performance), because using Python is such a drag. I think it's not that bad. Sure, it loses to Python, but that's some tough competition. Personally, I find that smile[1] covers most use cases. Breeze[2] also has a lot of love, but I'm not much of a fan of the `UFunc` abstraction. I'm also really excited about polynote[3]. It's still a bit green and only supports Scala 2.11/2.12, but it's such a joy to be able to use Scala in notebooks :). You also get Python interop, in case you need to use some specific python library. P.S.: I hope that Scala's ML/AI libraries other than Spark keep growing, because "embarassing" is a nice way to describe it's performance on everything that's not a "really-huge dataset". 1: https://github.com/haifengl/smile https://github.com/haifengl/smile 2: https://github.com/scalanlp/breeze https://github.com/scalanlp/breeze 3: https://github.com/polynote/polynote https://github.com/polynote/polynote
- tastyminerals2 6y ago
  Many if not most Scala data/ML libraries are one-person projects which are either abandoned or have compatibility issues. It's a barren land and loses to any similar Python library in terms of functionality. It's good that Java ecosystem can back Scala up otherwise it would be pretty sad.
Thalarg 6y ago
> considering the absurd productivity compared to Java/Kotlin/Python/blublang I have not see more unproductive language than Scala.
tastyminerals2 6y ago
Scala is weird. Sometimes it feels fluid and effortless but sometimes it simply cannot do things you would expect it to. For example, chaining custom methods. Why is it possible to do "arr.map(_.nonEmpty).filter(a => a % 2)" but not possible "arr.map(_.nonEmpty).myCustomFilter(_)"? In D thanks to UFCS and Properties you can chain all kinds of std and custom stuff together which looks more "efforless" and FP in my eyes. Syntax aside I find Scala code hard to read due to how much implicitness it allows which stems from its "do FP or die" attitude which is again, weird for a language designed to incorporate both OOP and FP. Should I mention that in this regard D does a better job at serving the both worlds? And finally, which threw me off completely is a real world case where we had to implement a word-entropy based algorithm to process tons of textual data and it appeared to be not much faster than a Python version despite all the optimization we tried to do. Scala is fast but there are many faster languages including Java itself. Considering the fact that its compiling times force you to leave your seat for a cup of coffee, you'd rather think of investing into another hard FP friendly language like Rust which simply has a wider applicability area. But yeah, this is all speculative but if you are thinking about what next language to pick up, these things start to matter. Where Scala fits nicely is a small team which needs to build some business logic on top of the existing Java backend stack quickly and have a reliable working system. This is where it really shines. Scala provides a nice layer for JVM devs who have a soft spot for FP, safe and elegant solutions.
- fluffything 6y ago
  > you'd rather think of investing into another hard FP friendly language like Rust which simply has a wider applicability area. FYI Aaron Turon did their PhD on Concurrency+Scala, and ended up leading the Rust core team for more than enough years.
- valenterry 6y ago
  There are no "special" methods in Scala. If you see something like "arr.map(_.nonEmpty).filter(a => a % 2)" in the standard library, you can use that syntax yourself too. E.g. "arr.customlyFiltered()" is easy to do. Or even easier "arr.filter(myCustomFilter)". If something doesn't work out for you, please feel free to use e.g. scalafiddle.io and make it example, then you will be helped! :) Scala is indeed not a high performant language. It is as fast as Java and compiles as fast as Java if you only use Java's features. However, then why use Scala in the beginning? Scala is great for writing very maintainable and reusable code, especially with a big team and a lot of business logic. It is also great to "glue" things together like you can do it with Python. For these things it has more than sufficient performance in my opinion.
sireat 6y ago
When Scala, IntelliJ and SBT cooperate the language is so pleasant to work with. There are some puzzling omissions though. For example slice method is missing step. Coming from heavy data munging Python this really bites. Sure would be nice to have some syntactic sugar for slice. Some seemingly simple tasks have no one way of solving them. Let's take parsing JSON. Trivial in Python, painful in Scala. (almost the reverse in Python which has painful XML parsing and Scala's built in support for XML) So far the easiest JSON library has been Li Haoyi's uPickle: https://www.lihaoyi.com/post/HowtoworkwithJSONinScala.html https://www.lihaoyi.com/post/HowtoworkwithJSONinScala.html Still, it does not parse JSON where objects have uknown arbitrary value types. Arbitrary value types are extremely common in real life JSON. Due to pattern matching you see people suggesting you write your own parser! Sure it can be done, but then the next thing you'll be rolling your own crypto...
- sjrd 6y ago
  > So far the easiest JSON library has been Li Haoyi's uPickle: https://www.lihaoyi.com/post/HowtoworkwithJSONinScala.html https://www.lihaoyi.com/post/HowtoworkwithJSONinScala.html > Still, it does not parse JSON where objects have uknown arbitrary value types. Arbitrary value types are extremely common in real life JSON. Looks like ujson, which the article you point to talks about, is what you're looking for. uPickle is a layer on top of ujson for statically typed stuff, but ujson is working with raw JSON values, of arbitrary types.
  - sireat 6y ago
    Thank you! I will have to look into ujson deeper.
    - lihaoyi 6y ago
      You can in fact mix typed and untyped parsing, by having a `ujson.Value` field in the middle of your typed case class or collection. It just works
      - sireat 6y ago

by smabie 6y ago

TeeWEE 6y ago

For me scala's feature set is absurdly big and there are always 10 ways todo things. Look at the spec of Scala. Its 200 pages long. That's insane. I'd rather use Kotlin.

pjmlp 6y ago
Yep, https://arrow-kt.io/ https://arrow-kt.io/ Just give it a couple of more years.
mbo 6y ago
The Kotlin spec is... 275 pages: https://kotlinlang.org/spec/pdf/kotlin-spec.pdf https://kotlinlang.org/spec/pdf/kotlin-spec.pdf
- zaphirplane 6y ago
  Yeah but the font ;)
- aphexairlines 6y ago
  And 796 pages for Java https://docs.oracle.com/javase/specs/jls/se14/jls14.pdf https://docs.oracle.com/javase/specs/jls/se14/jls14.pdf
rgoulter 6y ago
> For me scala's feature set is absurdly big and there are always 10 ways todo things. One of my favourite examples: of these 13 different ways of doing the same thing, only 12 are correct. https://nurkiewicz.github.io/talks/2014/scalar/#/22 https://nurkiewicz.github.io/talks/2014/scalar/#/22
- valenterry 6y ago
  How is that a bad thing? It's the same in other languages and it is nice to have some flexibility. E.g. lisp: use whichever type of parentheses you want Or Kotlin: use short syntax lambdas fruits.filter(it == apple) or long syntax fruits.filter(fruit -> fruit == apple) or with annotated types: fruits.filter{fruit: Fruit -> fruit == apple} Sometimes brevity is good for the reader, sometimes more details are good for the reader. Not everything is a nail.
  - misja111 6y ago
    The flexibility is perfectly fine when you're programming something on your own. But when you're in a team, or worse, in a large company, it starts to be a problem that everyone can use their own style. It's much easier to read someone else's code when you have a common code style. And in Scala there are not only many different ways to use the standard libraries or to structure your code, there is a pure FP vs OOP-style FP schism as well. Because of this, you can qualify as a senior Scala developer for one job but only a junior in another.
    - valenterry 6y ago
      The opposite. If I write code on my own just for myself I use the highest level of brevity. But if I write code for a team, then in some places I will use explicit type annotations and variable names to aid people unfamiliar with the code to understand what's going on. What you are saying is pretty much "it's easier when everyone only uses nails, because then all I have to bring is a hammer". I think it's good to use screws sometimes. However, your second point I agree with. OOP vs. FP is a different story. This is about paradigms not about mere syntax. So here, a team must be aligned, which can be a challange when using Scala. It's not a language for corporate drones.
trumpeta 6y ago
IIRC one of Odersky's stated goal for Scala 3 was to address exactly this issue. That being said, it is developed in a research setting so I guess even if they restrict these features now, there will be new ones added over time...
- vvillena 6y ago
  Scala has always been an opinionated language. The main difference is that this time is holding opinions against itself. Previously, opinions were held against Java, that's why there are features such as case classes, traits, and immutability by default. They answer to Java problems. Scala is now mature enough that some issues have emerged. Typeclasses are cool, but programming typeclasses in Scala is a bit clunky. The type system is very powerful, but it could be even more powerful and that would actually help people write simpler code. And there are a bunch of unused features that could be removed. This is what Scala 3 is about.
aliakhtar 6y ago
This is like saying, airplanes are too complex. There are so many knobs and buttons. I'd rather just walk or ride a bike everywhere. Scala is a very powerful, very expressive language. There are some features which you can just choose to leave out. If you do, you end up with a very clean, concise, and powerful language that makes you really productive. I've literally had moments where I made my algorithm 5x faster just by adding 4 letters: '.par' in front of an operation. Instantly it got parallelized without my having to do anything, and the processing time got cut 5x.
- tastyminerals2 6y ago
  And that's why there are far fewer pilots in this world than stewards.
- TeeWEE 6y ago
  Its more like saying: I need to cut some paper ( i need to program): Swiss army knifes (scala) are too complex, I just need a pair of pair of scissors (lisp / other languages).
  - aliakhtar 6y ago
    Scala really isn’t that complex though. It’s actually pretty intuitive. You CAN write bad and hairy scala code just like you can in any language. But that doesn’t mean the language is to blame.
pkolaczk 6y ago
Having switched from Scala to Python recently, I must say Python has probably 5x more ways to do things than Scala and I can't see people complaining on Python's complexity. This is something that really surprised me, because "one obvious way " was announced to be a part of Zen of Python.
- nsonha 6y ago
  and 0 way to do a lot of things
esarbe 6y ago
Scala 3 tries to be more opinionated and goes quite some miles (kilometers?) to make the language more regular and simple. The implicits are gone, for example. Kinda crazy, since it was Scala's banner feature for so long. For the primary use-cases of implicits (extensions, type classes, conversion, ...) there are now language level concepts to make these use-cases accessible. "Intent over mechanism" I think Martin calls it.

codeviking 6y ago

I really enjoyed writing Scala code. I'd agree with your evaluation with respect to the expressiveness and power provided by the language. ...but the tooling, at least at that time, was terrible. SBT was terribly overcomplicated, and full of foot-guns. I spent far too much time debugging dependency collisions, issues created by so-called "autoplugins" and other nuances that had nothing to do with getting real work done. Now I'm writing a lot of Go. I'll admit, it's not nearly as fun to write. There's a lot less creativity and expressiveness -- though I think this is probably a good thing. But it also feels like I'm getting a lot more stuff done, and the tooling is amazing.

tlarkworthy 6y ago
I use maven to compile Scala.
lmm 6y ago
SBT is a fractal of awfulness and I have no idea why anyone ever uses it. But it's never been required. Just use maven and get on with your life.
- nsonha 6y ago
  cbt and mill are just obvious scala code
  - lmm 6y ago
    How's their IDE integration? (Though TBH I'm coming from a starting point of "Maven isn't broken, there's no need to fix it")
    - nsonha 6y ago
      for mill intelij and vscode via the metals extension
- cryptos 6y ago
  Yes, SBT is just terrible! It is the reference for usability nightmare in the category build tools.

moonchild 6y ago

> only one language I like more (kdb+/q), but that's a hard sell, especially because of the cost J? It's not quite the same, but is OSS.

thirtyseven 6y ago

> Too bad there's not really a ML/AI ecosystem around (besides Spark, which seems to be losing favor partially because of its embarrassing performance) Compared to what? If you mean engines like Presto, I would say they have different use cases, plus Spark SQL puts them roughly in the same ballpark. Genuinely curious though, as a Spark user that is always interested in alternatives.

smabie 6y ago
kdb+/q performance smokes Spark. Actually. most native code on a single machine smokes an entire Spark cluster.

superyesh 6y ago

newhkusers1 6y ago

Scala deserves all the hate. It might be a fun language for a throwaway pet project but I'd never recommend it in an enterprise setting. It's an extremely unproductive language because it's too flexible. There are so many different ways to do the same thing which introduces unnecessary complexity.

hocuspocus 6y ago
Yet plenty of big companies manage to ship software written in Scala just fine.

willtim 6y ago

I am skeptical about the novelty of Scala's "OOFP" as you put it. It looks essentially the same as the original anonymous classes or SAM types in Java. Function values are objects with a single method and methods themselves are not first-class, but are wrapped in objects as required. The most important part of OO are the first-class modules; and in the literature, arguably more elegant examples of unifying first-class modules and FP exist, for example by starting with FP and adding objects as records containing functions, this way both "objects" and methods would be first-class. Subtyping also adds significant complexity to the language and weakens type inference. Scala is, first and foremost an OO language which embraces subtyping, class hierarchies and imperative programming, see for example its own collections library. As Java gets more and more FP features, there is a danger it will struggle to differentiate itself.

sjrd 6y ago
Your comment makes sense if we think of FP as being about "function values". In a world where all sorts of programming languages have function values, this is not a strong enough characterization anymore (if it ever truly was). Functional programming is about programming with immutability first. So OOFP is about immutable objects. I go even further to say it is about objects with immutable interfaces, but the implementations can be imperative as long as encapsulation hides the mutable aspects from the user of the object. This is what you see in Scala's collections library: we use mutability inside the implementation but we expose an immutable API. I gave an entire talk on that very topic at Scala Italy in 2019: https://vimeo.com/362001027 https://vimeo.com/362001027
- willtim 6y ago
  > Functional programming is about programming with immutability first. I completely agree with this. So perhaps I am being rather hard on Scala.
kitd 6y ago
It looks essentially the same as the original anonymous classes or SAM types in Java. Decompiling a Scala .class file shows just how true this is.

barry27 6y ago

Scala is awesome. It gets a lot of hate around here because many of the users of this site are Super Intelligent and Could Have Done It Themselves, Only Better.

JD557 6y ago

> Too bad there's not really a ML/AI ecosystem around (besides Spark, which seems to be losing favor partially because of its embarrassing performance), because using Python is such a drag. I think it's not that bad. Sure, it loses to Python, but that's some tough competition. Personally, I find that smile[1] covers most use cases. Breeze[2] also has a lot of love, but I'm not much of a fan of the `UFunc` abstraction. I'm also really excited about polynote[3]. It's still a bit green and only supports Scala 2.11/2.12, but it's such a joy to be able to use Scala in notebooks :). You also get Python interop, in case you need to use some specific python library. P.S.: I hope that Scala's ML/AI libraries other than Spark keep growing, because "embarassing" is a nice way to describe it's performance on everything that's not a "really-huge dataset". 1: https://github.com/haifengl/smile https://github.com/haifengl/smile 2: https://github.com/scalanlp/breeze https://github.com/scalanlp/breeze 3: https://github.com/polynote/polynote https://github.com/polynote/polynote

tastyminerals2 6y ago
Many if not most Scala data/ML libraries are one-person projects which are either abandoned or have compatibility issues. It's a barren land and loses to any similar Python library in terms of functionality. It's good that Java ecosystem can back Scala up otherwise it would be pretty sad.

Thalarg 6y ago

> considering the absurd productivity compared to Java/Kotlin/Python/blublang I have not see more unproductive language than Scala.

tastyminerals2 6y ago

Scala is weird. Sometimes it feels fluid and effortless but sometimes it simply cannot do things you would expect it to. For example, chaining custom methods. Why is it possible to do "arr.map(_.nonEmpty).filter(a => a % 2)" but not possible "arr.map(_.nonEmpty).myCustomFilter(_)"? In D thanks to UFCS and Properties you can chain all kinds of std and custom stuff together which looks more "efforless" and FP in my eyes. Syntax aside I find Scala code hard to read due to how much implicitness it allows which stems from its "do FP or die" attitude which is again, weird for a language designed to incorporate both OOP and FP. Should I mention that in this regard D does a better job at serving the both worlds? And finally, which threw me off completely is a real world case where we had to implement a word-entropy based algorithm to process tons of textual data and it appeared to be not much faster than a Python version despite all the optimization we tried to do. Scala is fast but there are many faster languages including Java itself. Considering the fact that its compiling times force you to leave your seat for a cup of coffee, you'd rather think of investing into another hard FP friendly language like Rust which simply has a wider applicability area. But yeah, this is all speculative but if you are thinking about what next language to pick up, these things start to matter. Where Scala fits nicely is a small team which needs to build some business logic on top of the existing Java backend stack quickly and have a reliable working system. This is where it really shines. Scala provides a nice layer for JVM devs who have a soft spot for FP, safe and elegant solutions.

fluffything 6y ago
> you'd rather think of investing into another hard FP friendly language like Rust which simply has a wider applicability area. FYI Aaron Turon did their PhD on Concurrency+Scala, and ended up leading the Rust core team for more than enough years.
valenterry 6y ago
There are no "special" methods in Scala. If you see something like "arr.map(_.nonEmpty).filter(a => a % 2)" in the standard library, you can use that syntax yourself too. E.g. "arr.customlyFiltered()" is easy to do. Or even easier "arr.filter(myCustomFilter)". If something doesn't work out for you, please feel free to use e.g. scalafiddle.io and make it example, then you will be helped! :) Scala is indeed not a high performant language. It is as fast as Java and compiles as fast as Java if you only use Java's features. However, then why use Scala in the beginning? Scala is great for writing very maintainable and reusable code, especially with a big team and a lot of business logic. It is also great to "glue" things together like you can do it with Python. For these things it has more than sufficient performance in my opinion.

sireat 6y ago

When Scala, IntelliJ and SBT cooperate the language is so pleasant to work with. There are some puzzling omissions though. For example slice method is missing step. Coming from heavy data munging Python this really bites. Sure would be nice to have some syntactic sugar for slice. Some seemingly simple tasks have no one way of solving them. Let's take parsing JSON. Trivial in Python, painful in Scala. (almost the reverse in Python which has painful XML parsing and Scala's built in support for XML) So far the easiest JSON library has been Li Haoyi's uPickle: https://www.lihaoyi.com/post/HowtoworkwithJSONinScala.html https://www.lihaoyi.com/post/HowtoworkwithJSONinScala.html Still, it does not parse JSON where objects have uknown arbitrary value types. Arbitrary value types are extremely common in real life JSON. Due to pattern matching you see people suggesting you write your own parser! Sure it can be done, but then the next thing you'll be rolling your own crypto...

sjrd 6y ago
> So far the easiest JSON library has been Li Haoyi's uPickle: https://www.lihaoyi.com/post/HowtoworkwithJSONinScala.html https://www.lihaoyi.com/post/HowtoworkwithJSONinScala.html > Still, it does not parse JSON where objects have uknown arbitrary value types. Arbitrary value types are extremely common in real life JSON. Looks like ujson, which the article you point to talks about, is what you're looking for. uPickle is a layer on top of ujson for statically typed stuff, but ujson is working with raw JSON values, of arbitrary types.
- sireat 6y ago
  Thank you! I will have to look into ujson deeper.
  - lihaoyi 6y ago
    You can in fact mix typed and untyped parsing, by having a `ujson.Value` field in the middle of your typed case class or collection. It just works
    - sireat 6y ago