←back to thread

Scala 3 slowed us down?

(kmaliszewski9.github.io)
261 points kmaliszewski | 2 comments | | HN request time: 0s | source
Show context
derriz ◴[] No.46183103[source]
I was involved in a Scala point version migration (2.x) migration a few years ago. I remember it being painful. Although I recall most of the pain was around having lots of dependencies and waiting for libraries to become available.

At the time Scala was on upswing because it had Spark as its killer app. It would have been a good time for the Scala maintainers to switch modes - from using Scala as a testbed for interesting programming-language theories and extensions to providing a usable platform as a general commercially usable programming language.

It missed the boat I feel. The window has passed (Spark moved to Python and Kotlin took over as the "modern" JVM language) and Scala is back to being an academic curiosity. But maybe the language curators never saw expanding mainstream usage as a goal.

replies(4): >>46183190 #>>46184785 #>>46185410 #>>46198527 #
hylaride ◴[] No.46183190[source]
Outside of Android work, has Kotlin really taken over? My understanding is that Java added a lot of functional programming and that took a lot of wind out of Scala's sails (though Scala's poor tooling certainly never helped anything).
replies(6): >>46183338 #>>46183368 #>>46183737 #>>46184354 #>>46184632 #>>46187198 #
mystifyingpoi ◴[] No.46184354[source]
> My understanding is that Java added a lot of functional programming

This is true, but needs more context. Java 8 added Stream API, which (at this time) was a fantastic breath of fresh air. However, the whole thing felt overengineered at many points, aka - it made complex things possible (collector chaining is admittedly cool, parallel streams are useful for quick-and-dirty data processing), but simple everyday things cumbersome. I cannot emphasize how tiring it was to have to write this useless bolierplate

  customers.stream().map(c -> c.getName()).collect(Collectors.joining(", "))
for 1000th time, knowing that

  customers.map(c -> c.getName()).join(", ")
is what users need 99.99999% of the time.
replies(2): >>46190477 #>>46198679 #
bvrmn ◴[] No.46190477{3}[source]
It bothers me that majority of languages ignores a nice python approach. `', '.join(any_str_iterable)`. Instead of supporting join for myriads of containers there is a single str method.
replies(1): >>46198623 #
still_grokking ◴[] No.46198623{4}[source]
Python's approach is one of the most confusing ways to possibly do it. Not having proper, discoverable methods is super annoying, and I need to look it up every time anew I use Python because it's so unintuitive.

Of course you can write a generic version of `mkString` (as this method is called in Scala), so it's also just one method no matter the container count.

The Python weirdness is actually a direct result from the language lacking generics…

replies(1): >>46215559 #
bvrmn ◴[] No.46215559{5}[source]
From typing perspective there is no sense to have Container[T].join() -> str for any T.
replies(1): >>46217609 #
1. mystifyingpoi ◴[] No.46217609{6}[source]
I agree, but from convenience perspective there is a lot of sense. Java Streams is actually a good example of a "correct" design, but not very convenient.
replies(1): >>46230140 #
2. bvrmn ◴[] No.46230140[source]
That's my point. Python has convenient and good type design with str.join ignored by other languages.

For example I'm lost which abstract class to inherit in Scala to obtain mkString for my custom container.