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

281–290 of 383 posts

Re: Towards Scala 3

#281

Post by RBerenguel »

sandGorgon wrote: post #279
RBerenguel wrote: post #262

Earlier quoted context omitted.

Although we decided to start using Scala specifically because PySpark was not as performant (2.0 is not so far ago), a reasonable use case I keep always in mind is aggregation (and in general any API which is still not solid/experimental/under work). Python bindings are always the last to be available (because all groundwork is being done in Scala). We have a relatively large scale process that takes advantage of cus…

I will stay away from veering into a statically typed vs dynamically typed conversation here ;) But I'm very excited about pyspark 2.3 UDF bringing grouped map . It will be interesting to hear your views on that https://databricks.com/blog/2017/10/30/introducing-vectorize...

Only checked the implementation of the "Arrow UDFs" recently, because I'm interested in the Arrow interaction (for curiosity), so still don't have a strong opinion. My main concern is that a lot of the PySpark systems are playing around how to interact and speed up the systems while still staying on top of the Scala base.

I'd recommend Dask (haven't tried it much but from all I've seen is top-notch) to anyone who wants Python all the way down (at least until you hit the C at the bottom) ;)

Re: Towards Scala 3

#282

Post by ionforce »

lmm wrote: post #263
bad_user wrote: post #207

Earlier quoted context omitted.

> 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 mean if you write something like: (for { x the answer will be rather surprising, because in Scala for/yield is not necessarily monadic.

It's only surprising if you ascribe monadic properties to that syntax versus understanding it as literal syntactic sugar and absolutely nothing else.

Re: Towards Scala 3

#283

Post by coryfklein »

naasking wrote: post #241
ItsMe000001 wrote: post #238

Earlier quoted context omitted.

I'm a Flow user rather than TS (and Flow complains about that code out of the box), but you are not telling us all: Since TS 2.6, if you enable all the optional " strict " mode checks than TypeScript does complain about that code. I see no disadvantage in those checks, e.g. "strictFunctionTypes", being optional, since you can always make them mandatory for your own project(s). To test it: - Go to the TS Playground at…

Is that option documented somewhere? I imagine there are some tradeoffs with enabling it.

The major tradeoff, IMO, is that it is even toggle-able at all, let alone being a feature switch that is enabled by default.

If you enter any random TS project today, odds are it isn't using that switch, and enabling the switch will lead you down a month long rabbit-hole of fixing cascading type errors.

Re: Towards Scala 3

#284

Post by ionforce »

YorkshireSeason wrote: post #190
saosebastiao wrote: post #175

Earlier quoted context omitted.

> Implicits are a generalisation of default arguments. There is an extreme semantic difference between an implicit parameter and a default argument. Have you spent any time at all using them? That's like claiming HKT is just a generalization of type constructors. Would you claim that HKT isn't anything new or novel because constructors have been around forever?

> Have you spent any time at all using them? Sure I have used both. Default arguments and implicits both have the same key idea: you can omit arguments to functions, and the compiler, guided by type information, synthesises the missing arguments during compilation. In order to understand the difference between both, it is crucial to realise that this compile-time synthesis of missing arguments has two related but dif…

Maybe a disagreement here is fueled by the power level difference in these two features. Beyond the superficial injection examples, Scala implicits also support injecting values constructed dynamically and also recursive/derived implicits.

Re: Towards Scala 3

#285

Post by ionforce »

pacala wrote: post #161
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…

> If scala team were to disavow sbt, that'd be the single best thing they could possibly do for the ecosystem. Seconded. Between http://www.lihaoyi.com/mill/ and https://bazel.build/ , there are plenty of alternatives.

Scala enthusiast Jon Pretty just announced `fury` as well!

Re: Towards Scala 3

#286

Post by coryfklein »

benjaminjackman wrote: post #225
actsasbuffoon wrote: post #154

Earlier quoted context omitted.

Typescript does indeed do frequent releases, though they're not nearly as ambitious as Scala 3.0. A Typescript release usually has 1-3 exciting new features, and a number of smaller bug fixes and improvements.

Correct, but collectively, between now and 2020 it's almost certain in aggregate, Typescript will have significantly more `features` than Scala 3.0, and they will have the benefit of being used and iterated upon for 2+ years.

Like many things, the utility of a language can actually decrease as you add more things on to it. Both Scala and Go take a principled approach of only accepting heavily vetted features.

The time it takes to develop a feature is very rarely the bottleneck.

Re: Towards Scala 3

#287

Post by sandGorgon »

RBerenguel wrote: post #281
sandGorgon wrote: post #279

Earlier quoted context omitted.

I will stay away from veering into a statically typed vs dynamically typed conversation here ;) But I'm very excited about pyspark 2.3 UDF bringing grouped map . It will be interesting to hear your views on that https://databricks.com/blog/2017/10/30/introducing-vectorize...

Only checked the implementation of the "Arrow UDFs" recently, because I'm interested in the Arrow interaction (for curiosity), so still don't have a strong opinion. My main concern is that a lot of the PySpark systems are playing around how to interact and speed up the systems while still staying on top of the Scala base. I'd recommend Dask (haven't tried it much but from all I've seen is top-notch) to anyone who wan…

well we run a hundred machine cluster on Dataproc for doing our stuff. Dask is still not battle-tested, cloud ready (or available) and is generally harder to work with than pyspark.

In general, I will stay happily in the spark world using pyspark rather than go to Dask right now.

Re: Towards Scala 3

#288

Post by ivan_gammel »

swirepe wrote: post #255
dtech wrote: post #228

Earlier quoted context omitted.

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?

Real example from my experience: you use a Scala Map and pass it to something like FreeMarker, expecting that it will work like Java Map there. It will not and depending on your test coverage and SQA capabilities, you may notice it very quickly or very late (you'll get no compile error, since template engines usually accept generic objects and then analyze their type via reflection).

Re: Towards Scala 3

#289

Post by geodel »

DandyDev wrote: post #210
munificent wrote: post #201

Earlier quoted context omitted.

> Why are people so intent to bash sombody else's language choices?! Partially it's simple tribalism. But part of it is also the rational awareness of the opportunity cost of investing in a language other than the author's preferred one. The more people using language X that I don't like, the fewer people using my preferred language Y. That means fewer libraries I can use, docs I can read, bugs that get fixed, etc. L…

That might be true to some extend, but many languages have completely different target audiences. People whose favourite language is Go, will probably not move to Scala (and vice versa). Kotlin vs Scala is an easier to understand competition. In any case, if people want other people to invest in "their language", they should focus on making that language and its ecosystem compelling to use, not bash other languages..…

I have seen 2 types of bashers. One which seems typical line of business app developers. They disparage other languages, praise theirs on basic things like IDEs, libs etc. I don't mind these much.

However others who approach from position of authority like compiler hackers, language authors themselves, or very senior developers etc. Ideally criticism from them should be more valid but more often than not I have seen they keep making bad faith arguments and justify their hate by precise technical arguments so they can't be challenged by non-technical arguments. It makes vary of their arguments even on topics other than favorite programing language.

Re: Towards Scala 3

#290

Post by ionforce »

braindongle wrote: post #260
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.

I was in a meeting where this just happened. And as liberal as I am, it is exactly PC nitpicking. You can also choose to lead by example rather than correcting people. Despite all the good intentions in the world, people may not react well to this style, making your contribution locally ineffective.

This is double if the person you're correcting doesn't think what they're doing is "wrong".

Post reply on HN