Live data from Hacker News

Towards Scala 3

scala-lang.org

91–100 of 383 posts

Re: Towards Scala 3

#91
post #45

Earlier quoted context omitted.

Also, no plans to get rid of implicits apparently. Sorry Scala, we're not gonna be friends.

Not fully, but implicit type conversion must be marked explicitly: https://medium.com/bigdatarepublic/key-takeaways-from-the-sc...

Here's the current state: https://github.com/lampepfl/dotty/pull/4229

Re: Towards Scala 3

#92
post #27
post #4

Earlier quoted context omitted.

Scala is used pretty heavily in the big data world, particularly if you are working with Spark.

Python is still king there, even DataBricks market it that way. Scala is for advanced stuff that matters.

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

Re: Towards Scala 3

#93
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…

Expedia is a big time scala shop, but new stuff is trending towards Kotlin.

Re: Towards Scala 3

#94
post #79
post #67

There are a lot of comments pointing out pros and cons of Scala, comparing it to other languages using superficial proxies. I'd like to share a different perspective based on my own work with OOP-centric and FP-centric languages. If you take OOP to its logical conclusion, OOP is a slippery slope that eventually leads to Gang-Of-Four centric designs. If you take FP to its logical conclusion, FP is a slippery slope tha…

> 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…

> Ed Kmett's comments on Scala make me worry that the "solid foundation" isn't as solid as it could be: https://www.reddit.com/r/haskell/comments/1pjjy5/odersky_the.... . How much of this is true in more recent Scala versions?

Some are fixed (Either, inference for many of the type lambda cases), some are being fixed in the next version (container overloads, CanBuildFrom), some are not really issues at all (free theorems are fine, an extra map on a monad is not a problem and sometimes more efficient, specific compiler bugs have been fixed but never said anything about the language in general, Haskell as used in the wild (with orphan instances) doesn't guarantee typeclass coherence either), some are real but exaggerated issues (subtyping and implicits, type inference for tricky recursion), a few are genuine issues that remain and probably always will (having to trampoline your monads, no kind system).

Re: Towards Scala 3

#95
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…

And Clojure? I find it to be the best experience on JVM.

My favorite Lisp variant.

I have not listed it, because in spite of spec, it still is a dynamic language.

Re: Towards Scala 3

#96
post #54
post #37

Earlier quoted context omitted.

Don't think it has a bright future since Rust and Kotlin share much of what brings people to Scala and are better in many ways, including and perhaps most importantly the fact they are improving faster than Scala.

Neither of those has or intends to have HKT, and they'll never be an acceptable replacement for Scala without it. They're "improving faster" but only in that they're starting from further behind.

I thought I saw HKT planned for Rust, as in, being in the works.

Re: Towards Scala 3

#97
post #23
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…

Yeah, I don't think Scala 3 changes anything with regards to perception and/or adoption of Scala. That ship has pretty much sailed. Martin Odersky seems like a really good language designer. I took a look at the Scala 3 languages features, and a more radical departure from historic Scala probably would have helped Scala.

Three or four years ago the biggest criticism of Scala was that releases were breaking backwards compatibility too much. On this very thread you'll find people worrying that Scala 3 will create a Python 2/3-style endless awkward transition. At this stage it's a mature language with a big established ecosystem, it can't afford to break too radically.

(Did you have specific breaking changes in mind? The most important changes I'd want to make to the language - having a syntax for guaranteed-safe equality comparison and guaranteed-safe pattern matching - could be done in a backwards compatible way, and the only other thing I can think that I'd like would be Idris-style totality checking which could also be backwards compatible.)

Re: Towards Scala 3

#98
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…

F# and OCaml? What source do you use to say that? Scala is way more popular in the industry that these 2 combined.

Re: Towards Scala 3

#99
post #38
post #21

Earlier quoted context omitted.

F# is now supported within the .NET core world so it opens up the deployment scenarios beyond anywhere traditional .NET would live.

Not everyone is getting into .NET Core. In fact, Microsoft has to advocate library writers to actually care about .NET Core and .NET Standard. https://channel9.msdn.com/Shows/Visual-Studio-Toolbox/NET-St...

How is this relevant to the discussion though? F# works on either .NET Core or the regular .NET Framework.

Re: Towards Scala 3

#100
post #90
post #80

Earlier quoted context omitted.

I’m not sure if your info is dated or mine is, but all the systems development at LNKD that was being done in Scala is now done in Java. There is some legacy Scala still but as of a couple years ago they decided no new development. Perhaps they are still using Scala in a data science context, since it is hard to avoid there, these days.

It's trivial to avoid it in data science, with even modest to large (although not "Big") data in the few TB range. My data science team's entire stack is basically Python, with a smidge of Java and Rust for infrastructure (soa, pipelines) development.

I almost added the clarifying statement "on the JVM" but got lazy. Yes, Python is the obvious choice for data science until you hit a certain scale.

It's not even clear to me that most companies doing data science in Scala have that scale -- they're just using tools and libraries companies at that scale have open sourced. You could call it cargo culting, but I think it's more nuanced than that. I think engineers can be separated into two camps roughly: those who are passionate about the language(s) they use, and those who are simply trying to get the result they need and don't care what language they use to get it. A lot of data science engineers naturally fall into the second bucket, so using Scala because a library they want to use is written in it comes naturally, even if they could get the job done in Python (possibly with a bit more wheel reinvention).

Post reply on HN