Towards Scala 3 • Hacker News Board

Re: Towards Scala 3

#211

Post by hyperflex » Fri, Apr 20, 2018, 5:09 PM UTC

misja111 wrote: post #62

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…

> Just curious, what companies (or kinds of companies) are betting on Scala nowadays? LinkedIn, Twitter, The Guardian, Morgan Stanley, Barclays, Zalando. Generally speaking, Scala is used a lot by companies involved with Big Data (because they use Spark).

The control plane for Cisco Hyperflex[1]'s distributed storage uses Scala. We're hiring[2].

1- https://www.cisco.com/c/en/us/products/hyperconverged-infras...

2- https://jobs.cisco.com/jobs/SearchJobs/hyperflex?3_12_3=187

Re: Towards Scala 3

#212

Post by diogofranco » Fri, Apr 20, 2018, 5:10 PM UTC

sandGorgon wrote: post #168

RBerenguel wrote: post #92

Earlier quoted context omitted.

Python is king in analysis, but for big data engineering, most of the building blocks (as mentioned elsewhere in this thread, Akka, Kafka, Flink, Spark, etc) are written in Scala

It doesn't matter. Because pyspark is still the go-to language. In fact with spark 2.3 python UDF, the performance gap has also reduced. https://mindfulmachines.io/blog/2018/4/3/spark-rdds-and-data...

pyspark might be the go-to language for data scientists playing with the spark repl, or MLLib, but for production data engineering, scala is still king.

Besides performance and the obvious fact that not knowing scala makes it difficult to understand the underlying Spark code, there are multiple ways in which scala is more natural to develop in (many libraries are for scala only, for example).

Re: Towards Scala 3

#213

Post by JD557 » Fri, Apr 20, 2018, 5:16 PM UTC

bad_user wrote: post #207

lmm wrote: post #83

Earlier quoted context omitted.

> It's obvious that Scala was specifically designed to be a solid foundation on which one can implement the concepts of a little known branch of mathematics called the category theory, and almost every design choice in the language flows from there. Nonsense. Scala was designed to make programming easier and safer than Java - XML literals and pattern matching certainly have nothing to do with category theory. Scala's…

> Scala's for/yield has surprising behaviour ... because it doesn't have a categorical grounding Not sure what you're talking about, but for/yield is syntactic sugar for map/flatMap, just like the "do notation" is in Haskell. Of course it has theoretical grounding, because it wouldn't work without flatMap being the monadic bind. > mixing lists and sets Again, not entirely sure what you're talking about, but if true,…

I believe that he's referring to the fact that Scala's Set is not a monad, so it "shouldn't" have a .flatMap operation.

Scala has other containers that have a .flatMap operation that are not real monads, such as Future and Try.

That can lead to surprising behavior on for/yeld loops.

Disclaimer: I do work in Scala and enjoy the language.

Re: Towards Scala 3

#214

Post by tel » Fri, Apr 20, 2018, 5:22 PM UTC

preordained wrote: post #191

endgame wrote: post #79

Earlier quoted context omitted.

> If you take FP to its logical conclusion, FP is a slippery slope that eventually leads to Monad-Transformer centric designs. I don't understand what you mean by this, and I write production haskell for a living. We don't have teetering towers of transformers, and the best advice I've seen is often "put away the shiny tools and just use functions", https://lukepalmer.wordpress.com/2010/01/24/haskell-antipatt... . Si…

It's been a while since I lurked Haskell forums/haunts (was into it way back when), but at that time Lens was a big deal...if that's not a highfalutin library made for the most entrenched monad geeks (and for the purpose of making setters and getters, no less), I don't know what is. I guess I'm really shocked to hear that Haskell is all pragmatic and simple now with slim abstractions...but I'd love to be corrected.

I'd suggest that you're giving Lens a pretty short shrift. It's not "just" getters and setters as it works on immutable data. It also has a composition story that's better than normal getters and setters and _much_ better than other immutable data update stories.

Re: Towards Scala 3

#215

Post by eeperson » Fri, Apr 20, 2018, 5:23 PM UTC

jrq wrote: post #122

Disclaimer : I'm nobody important, but I do have an opinion If scala team were to disavow sbt, that'd be the single best thing they could possibly do for the ecosystem. I used to write a lot of scala, and working with sbt was enough to eventually get under my skin. I really like some of the OOP aspects of scala, the left-to-right style of thinking matches how my brain works. Scala having a lot to offer can distract n…

What problems did you have with sbt? Depending on how long a go you used it, those problems might have been fixed. In the last couple of years, a lot of simplifications have been made to how sbt build scripts are written.

Re: Towards Scala 3

#216

Post by clhodapp » Fri, Apr 20, 2018, 5:24 PM UTC

> Scala 3 code can use Scala 2 artifacts because the Scala 3 compiler understands the classfile format for sources compiled with Scala 2.12 and upwards.

I feel like this isn't getting much attention but it is a huge deal. A big part of the reason that Python 3 went the way it did was users didn't want to upgrade until their libraries did and libraries didn't want to upgrade until their users did. With Scala 3, users can upgrade pretty rapidly, freeing libraries to upgrade without fear of leaving their users behind.

Re: Towards Scala 3

#217

Post by AsyncAwait » Fri, Apr 20, 2018, 5:26 PM UTC

Cyph0n wrote: post #66

pjmlp wrote: post #56

Earlier quoted context omitted.

More than that, if you want Kotlin/Native debugging support, you need to either buy Clion or AppCode, as it is not available on the community edition.

Charging for debugger access sounds so 90s lol

They're not charging for debugger access. CLion is the only IDE where they have tie ins to GDB etc. so the Native plugin is only for that, but most Kotlin users are on the JVM, where the IDEA Community Edition is not only free, but open-source.

Re: Towards Scala 3

#218

Post by MichaelMoser123 » Fri, Apr 20, 2018, 5:30 PM UTC

lmm wrote: post #192

DandyDev wrote: post #174

It's amazing how many people in this thread justify their own language choices by making negative, sweeping statements about another language (Scala in this case) that is successfully used by people other than themselves. Yes, some people who previously used Scala, now use Kotlin. And some people who would've used Scala if Kotlin didn't exist, use Kotlin. Same probably goes for Rust. But there is a big enough market…

The reality is that a language lives or dies by its ecosystem - particularly when it comes to a language like Scala that's in a tightly symbiotic relationship with its IDEs (the next time someone tries to sell you a "visual programming language", look at Scala for a language that makes really effective use of the GUI for programming without compromising the things that make textual programming languages good - see e.…

> if the language is to live, I have to convince other people it's the best

Aren't JVM languages interoperable - because they use the same classfile/byte code format?

What does it matter if the jar is written in java or scala, as long as it is possible to use the external interface from any of these languages?

Re: Towards Scala 3

#219

Post by vbezhenar » Fri, Apr 20, 2018, 5:30 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…

That's my negative point about Kotlin (sorry, offtopic here, but stil). It moved fast before release and now for a long time there were only very minor releases (well, coroutines were nice addition and that's all) despite the fact that there's a lot to improve in Kotlin.

Re: Towards Scala 3

#220

Post by saosebastiao » Fri, Apr 20, 2018, 5:31 PM UTC

twic wrote: post #197

saosebastiao wrote: post #159

Earlier quoted context omitted.

That assumes that Java is the only funnel for Scala. Sure, Kotlin likely now captures more of the people trying to get out of Java, but how many people does it capture with backgrounds in Haskell, OCaml, Lisp, R, Python/Pandas, or any other language for that matter?

Aren't there so few people with backgrounds like that (Python aside) that it doesn't really matter?

No? I came to Scala from R and Clojure. The point is that Kotlin has pigeonholed itself into being a language for people who can't stand Java. Scala is partially that, but it is also vying for the attention of anybody who does object oriented programming, anybody who does functional programming, anybody that cares about type safety, etc.

The idea that Kotlin is hurting Scala adoption rests on the assumption that the only people who would ever adopt Scala are the people who are trying to get rid of Java.