Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Towards Scala 3

scala-lang.org

Post reply on HN
Print view View original

251–260 of 383 posts

Re: Towards Scala 3

#251

Post by aphexairlines »

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…

Here are a bunch of job postings at Amazon citing that they use Scala:

https://www.linkedin.com/jobs/amazon-scala-jobs/?country=gb

https://www.indeed.co.uk/cmp/Amazon.com/jobs?q=scala&l=Londo...

https://www.amazon.jobs/en/search?base_query=scala&loc_query...

Re: Towards Scala 3

#252

Post by AsyncAwait »

Cyph0n wrote: post #235
AsyncAwait wrote: post #217

Earlier quoted context omitted.

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.

> CLion is the only IDE where they have tie ins to GDB etc. so the Native plugin is only for that Both me and the parent were referring to Native. So they are charging for a Kotlin Native debugger, no? Do they provide a GDB fork or something that can use without CLion?

> Both me and the parent were referring to Native.

I know.

So they are charging for a Kotlin Native debugger, no?

No, Kotlin Native can interface with GDB or LLDB, they're charging for CLion which provides a GUI interface atop of these.

> Do they provide a GDB fork or something that can use without CLion?

No need to fork, you just won't have the frontend that Clion provides.

Re: Towards Scala 3

#254

Post by aphexairlines »

sidlls wrote: post #88
misja111 wrote: post #62

Earlier quoted context omitted.

> 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).

This doesn't mean they're using Scala to develop, necessarily. Some architects at the company I work for decided we needed Kafka, but there isn't a single line of Scala being written by anyone here.

Scala open source projects from The Guardian: https://github.com/guardian?utf8=%E2%9C%93&q=&type=&language...

Scala at Morgan Stanley: https://www.reddit.com/r/scala/comments/480ral/scala_at_morg... https://www.linkedin.com/jobs/morgan-stanley-scala-jobs/?cou...

Scala at Barclays: https://underscore.io/jobs/2017-11-02-barclays/

Scala at Zalando: https://jobs.zalando.com/tech/blog/why-we-do-scala

Scala open source projects from Twitter: https://github.com/twitter?utf8=%E2%9C%93&q=&type=&language=...

Re: Towards Scala 3

#255

Post by swirepe »

dtech wrote: post #228
MichaelMoser123 wrote: post #218

Earlier quoted context omitted.

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

Yes and no. JVM languages can usually use other JVM libraries, but they often aren't idiomatic to that language. Scala can use JVM libraries, but it often feels wrong or cumbersome, e.g. Java is full of mutable builder classes, which I've never once encountered in "native" Scala. The other way around, in Scala you have to be careful if you want your library to be usable from other JVM languages. There's certain Scala…

What Scala features can't you use?

Re: Towards Scala 3

#256

Post by sandGorgon »

diogofranco wrote: post #212
sandGorgon wrote: post #168

Earlier quoted context omitted.

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).

I don't think so. Python and data frames is arguably more natural to think about and reason than scala.

I have no doubt that scala is more performant and the "fat" jar mechanism makes dependency management and codeshipping very easy (it's still tricky to install python dependencies on your spark nodes), but the pandas ecosystem is definitely more intuitive to understand.

Re: Towards Scala 3

#257

Post by Bizarro »

lmm wrote: post #189
Bizarro wrote: post #167

Earlier quoted context omitted.

I wouldn't have called it Scala 3. And if I had the big brain of Martin Odersky, 5 years ago I would've had started thinking about an intermediate step in programming productivity, correctness - instead of doing Doty. I don't follow Scala that much anymore, but it seems that it's mostly a reworking of the internal consistency of Scala from an implementation perspective. At least that was the gist of it I got from wat…

> 5 years ago I would've had started thinking about an intermediate step in programming productivity, correctness - instead of doing Doty. Wait what? In the last post you were complaining it was too close to existing scala, now you're saying it's too big a step? Again, what is the change you're actually advocating?

You misunderstand. The intermediate step in programming productivity has nothing to do with any particular language. I would have not done "Scala 3", but something else that implements "intermediate step up in programming productivity and correctness". Probably something a bit radical, but hey development is so stagnant when it comes to way we program, it would've been worth the risk.

Hint, the stuff that Chris Granger was trying to accomplish.

Re: Towards Scala 3

#258

Post by jrq »

eeperson wrote: post #215
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.

Macros going wrong with complicated builds, implicits galore all over the place, just the usual complaints.

The thing that makes sbt difficult in practice for me is twofold. I don't want to deliver hackedy shit to a client that I then have to defend if their quality control comes back complaining about it. Being able to use regular scala in sbt definitions is convenient but at the cost of making things expressable that should wisely be done another way.

Which brings me to the second point which is getting a sbt definition from a client and then they don't want to change it, or they don't have quality control so it's just awful, or its so bad that someone has to rewrite it for the solution. The latter being the easiest to deal with, but that also costs time.

For those looking, what things do you feel have most improved the sbt experience?

Re: Towards Scala 3

#259

Post by sandGorgon »

kprybol wrote: post #204
sandGorgon wrote: post #168

Earlier quoted context omitted.

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

It depends on the use case. Our work primarily revolves around extending Spark with custom pipelines, models, ensembles, etc. to be deployed into our production systems (petabyte scale). Scala was really the only way to go for us.

I can understand performance difference, but I have not generally seen a difference in building custom pipelines and ensembles .. although I grant I'm not at your scale yet.

What kind of specific pipelines did you have trouble in pyspark ?

Re: Towards Scala 3

#260

Post by braindongle »

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…

Please don't use "guys" this way. This is not PC nitpicking, It's important. "People" or "folks" may not have the ring you're after, but too bad.
Post reply on HN