Towards Scala 3 • Hacker News Board

Re: Towards Scala 3

#131

Post by virmundi » Fri, Apr 20, 2018, 2:57 PM UTC

How have people faired with Scala integration with Java libraries? When Scala first came out, I liked the idea. If I wanted to use X library, great, I can. As I pondered it more, this seemed terrible. Say I hug the functional side of Scala. I know what I'm doing. Then I hire a Jr Dev. She comes from the world of Java/Python where functional is no as big of thing (keeping in mind that while Python does support, to a degree, functional, many use it as a procedural/OO language in school). Suddenly I have to worry about the Jr Dev doing silly things like introducing mutable Java objects into functional code. Side effects could start to show at odd times, which makes debugging terrible in a production environment.

All that said, how have others dealt with this issue? Did you just not work directly with Java libraries? Did you use the OO side as a Better Java?

Re: Towards Scala 3

#132

Post by Cyph0n » Fri, Apr 20, 2018, 2:58 PM UTC

realusername wrote: post #75

lmm wrote: post #69

Earlier quoted context omitted.

Can you be specific? This is a popular meme but it doesn't match my experience of Scala's language features at all (indeed I'd say Scala is very good at pushing things out into libraries or composition of existing features rather than making them language features), and often I find people with this kind of complaint were actually using a library with poorly named functions and mistaking its features for language fea…

I would start with operators and operator overrides, most of the time they don't make sense and it's difficult to know what it does, that's why most other languages banned them. Secondly, the implicit concept makes the code difficult to read. Then I would add that the differentiation between function & variable isn't always clear and sometimes you don't know what you call.

Most uses of operator overrides in the Scala standard library make complete sense.

Want to add a value to a (mutable) Seq? Use +=.

Want to add a value and return a new Vector? Use +.

Want to build a new list that is the concatenation of two Lists? Use ++.

sbt is probably where you encountered "weird" operators, but their use has declined over the past few years from what I've seen.

Re: Towards Scala 3

#133

Post by manojlds » Fri, Apr 20, 2018, 2:58 PM UTC

stephen wrote: post #118

...ships in 2020? I'm impressed with what they're doing (and love the language), and it's hard work, and their speed is faster than, say, Java's dead-pace evolution in the 2000s. But, poking around at TypeScript, I've been blown away with the MS/TS speed of development. ~2-3 month release cycles, with non-trivial changes to the language (mapped types, conditional types, etc.), that are themselves unique/novel type sy…

It's not the next release. There is 2.13 and 2.14 to be released. Are you saying Typescript has major version release every 3 months?

Re: Towards Scala 3

#134

Post by polskibus » Fri, Apr 20, 2018, 2:59 PM UTC

afroboy wrote: post #41

nnq wrote: post #2

Just curious, what companies (or kinds of companies) are betting on Scala nowadays? It seems that the people wanting "better Java" all decided they like Kotlin, and the functional programming people now gravitate more towards either F# (for .NET ecosystem) or OCaml/Reason (for the more unixy world). And the academic/research/learning crowd seems to like Haskell more. Who's still in Scala boat? Are Google or Fb or oth…

Twitter now is running its Scala code on GraalVM.

Woah, can you provide a reference? I'm curious about the rationale and performance implications.

Re: Towards Scala 3

#135

Post by snuxoll » Fri, Apr 20, 2018, 3:00 PM UTC

Bizarro wrote: post #26

pjmlp wrote: post #14

Earlier quoted context omitted.

F# only has access to a subset of .NET deployment scenarios, where Scala can be used pretty much everywhere there is a JVM. So most companies actually are more keen to bet on Scala than F#. OCaml/Reason world lacks the wealth of Java libraries, which are an import away on Scala. Regarding Kotlin, so far its killer use case is targeting Android, where one is stuck with an ageing Java subset. Outside of Android, it rem…

I don't think many companies are betting on Scala anymore. F# is just as irrelevant in the grand scheme of things. Let's face it, Kotlin hurts Scala adoption.

Kotlin has many benefits that Scala has in terms of “being a better Java” without sacrificing the readability and usability benefits of Java itself.

Scala is a fantastic language, but it’s not one your average Java developer can pick up in a day or two.

Re: Towards Scala 3

#136

Post by sidlls » Fri, Apr 20, 2018, 3:01 PM UTC

chamakits wrote: post #125

sidlls wrote: post #76

Earlier quoted context omitted.

Why isn't it nearly as nice? Is there something particular about Scala such that Kafka or Akka are best implemented in it? Could you give some concrete examples (e.g. compare it with Java, C, C++, Rust, Haskell)?

I think the parent comment was talking more about using those libraries with Scala, not necessarily implementing them. Can't speak too much about the others, but I recently looked into using Akka with Java. Akka itself had a good deal of documentation for Java users. However, other related products (look tools for monitoring Akka, etc) were clearly treating Java as a second class citizen. When there was documentation…

I took the comment to mean that Scala is the best choice for having implemented, e.g. Kafka, and that other languages somehow aren't suited for it, and asked the question with that in mind.

Re: Towards Scala 3

#137

Post by merb » Fri, Apr 20, 2018, 3:01 PM UTC

Well it won't solve the biggest problems with interop https://github.com/scala/collection-strawman/issues/283 (sadly).

I mean I can understand all the reasons not to, however It's just a pita that there is no sane way to do it, besides reimplementing either two api's or come up with your own collections.

Re: Towards Scala 3

#138

Post by room271 » Fri, Apr 20, 2018, 3:02 PM UTC

As a heavy Scala user I'm excited by this. But really I don't think it will improve Scala adoption because the blockers there are all around developer experience (tooling is terrible - sbt, and feedback cycles are very slow).

Personally, for a lot of my current use cases (APIs) I'm veering towards Go more and more as I find it a lot more productive.

Re: Towards Scala 3

#139

Post by dtech » Fri, Apr 20, 2018, 3:03 PM UTC

merb wrote: post #137

Well it won't solve the biggest problems with interop https://github.com/scala/collection-strawman/issues/283 (sadly). I mean I can understand all the reasons not to, however It's just a pita that there is no sane way to do it, besides reimplementing either two api's or come up with your own collections.

Is this really such a big problem? You can either work directly with the Java collections if the code is performance sensitive, or have a `.toScala` call at your Java -> Scala boundary and a `.toJava` call at your Scala -> Java boundary.

Re: Towards Scala 3

#140

Post by Cyph0n » Fri, Apr 20, 2018, 3:04 PM UTC

virmundi wrote: post #131

How have people faired with Scala integration with Java libraries? When Scala first came out, I liked the idea. If I wanted to use X library, great, I can. As I pondered it more, this seemed terrible. Say I hug the functional side of Scala. I know what I'm doing. Then I hire a Jr Dev. She comes from the world of Java/Python where functional is no as big of thing (keeping in mind that while Python does support, to a d…

When interacting with a Java library, I use scala.collection.JavaConversions to convert any Java structures to the equivalent Scala collection. Once I'm done operating on the collection (map, filter, etc.), I convert it back to Java.