From First Principles: Why Scala? • Hacker News Board

Re: From First Principles: Why Scala?

#331

Post by merb » Fri, Feb 12, 2021, 11:34 PM UTC

zmmmmm wrote: post #199

merb wrote: post #181

Earlier quoted context omitted.

they never said that, but it's basically abadonware. look at the commit history: https://github.com/slick/slick/commits/master you can also look at the contributors page: https://github.com/slick/slick/graphs/contributors the guys who primarly contributed to it basically left lightbend, and in 2019 he shifted his priorities. it only had 28 commits since 2020 (including merge commits and changes to the build process)…

> 28 commits since 2020 wow, the bar for "not dead" is really high these days :-)

well as said 28 commits, NOT ALL were code. MOST of them were basically "fix build"/update dep. so basically the project did not change for over a year.

AND 2019 wasn't really better. 3.3.2 (3.3.3 was mid 2020) was in JUNE 2019 and 3.3.0 was at the beginning of 2019. there won't be a 3.4 anytime soon, if nobody steps up and starts maintaining it, there won't be a 3.4 at all.

slick is heavy on macros it will not survive scala 3

Re: From First Principles: Why Scala?

#332

Post by cutler » Fri, Feb 12, 2021, 11:36 PM UTC

mwcampbell wrote: post #20

I dabbled with Scala several years ago, but I've been using Kotlin for a JVM-based project and am happy with it. My main reason for choosing Kotlin is smoother interop with the JVM world. For example: - Scala adds an Option type, whereas Kotlin adds nullability checking for existing object types. - Scala has its own convention for getters and setters, whereas Kotlin automatically turns JVM getters and setters into pr…

You left out the big one - Android.

Re: From First Principles: Why Scala?

#333

Post by still_grokking » Sat, Feb 13, 2021, 9:25 AM UTC

MrPowers wrote: post #36

I am a Scala programmer & think it's a great language. Here are some arguments for why not Scala: * Li's libs (os-lib, upickle, utest) have clean public interfaces, but most Scala ecosystem libs are hard to use, see the JSON alternatives for examples: https://www.lihaoyi.com/post/uJsonfastflexibleandintuitiveJS... * The Mill build tool looks a lot better than SBT, but seems like everyone is still using SBT * Scala mi…

> * Scala minor version are binary incompatible

Isn't it "major" versions?

AFAIK Scala has a version scheme of "epoch.major.minor"

Re: From First Principles: Why Scala?

#334

Post by still_grokking » Sat, Feb 13, 2021, 10:02 AM UTC

Cthulhu_ wrote: post #46

occupy_paul_st wrote: post #11

I definitely agree that many newer languages are strongly inspired by Scala, but I don't see a strong argument for why to choose Scala over one of a newer hybrid language. My own intuition is that these newer languages have had the benefit of being able to learn from Scala's mistakes. A lot of them have intentionally sacrificed some of the Scala's flexibility to be easier to learn and use. I found Scala to be an extr…

I feel like Scala started a trend in language design, where every language adds features from other languages. Not because there's a need, but because some people are used to language X. Example: adding OOP in PHP and Javascript. In both examples, especially the first attempts, were half-baked. Why bolt on half a language feature? Both languages would be much better served with dependency management and / or modules,…

JavaScript was OO form day one. There aren't even much languages that are so consequent OO like JavaScript. Everything is an object even functions.

JavaScript is actually quite similar to Self (besides the syntax), which itself is a kind of a SmallTalk like language. It's hard to be more OO than that. :-)

Re: From First Principles: Why Scala?

#335

Post by still_grokking » Sat, Feb 13, 2021, 10:15 AM UTC

occupy_paul_st wrote: post #11

I definitely agree that many newer languages are strongly inspired by Scala, but I don't see a strong argument for why to choose Scala over one of a newer hybrid language. My own intuition is that these newer languages have had the benefit of being able to learn from Scala's mistakes. A lot of them have intentionally sacrificed some of the Scala's flexibility to be easier to learn and use. I found Scala to be an extr…

I to this day don't get what's wrong with Scala's marketing, as people are complaining about the "complex type system" but nobody does so for TypeScript.

Same for compile times. TS compilation is ridiculously slow yet there're no complains whatsoever out there. Scala compile times are OK on the other hands side, especially if you ever used C++ with similar complex code, or TS like said, but "the slow compiles" are a topic now for years.

Just makes no sense to me, don't get it.

Re: From First Principles: Why Scala?

#336

Post by still_grokking » Sat, Feb 13, 2021, 10:28 AM UTC

merb wrote: post #331

zmmmmm wrote: post #199

Earlier quoted context omitted.

> 28 commits since 2020 wow, the bar for "not dead" is really high these days :-)

well as said 28 commits, NOT ALL were code. MOST of them were basically "fix build"/update dep. so basically the project did not change for over a year. AND 2019 wasn't really better. 3.3.2 (3.3.3 was mid 2020) was in JUNE 2019 and 3.3.0 was at the beginning of 2019. there won't be a 3.4 anytime soon, if nobody steps up and starts maintaining it, there won't be a 3.4 at all. slick is heavy on macros it will not survi…

Well, that would streamline nicely the options for DB libs in Scala…

Doobie (optionally with Quill Syntax) would be left and become likely the "Hibernate of Scala-Land".

That's not too bad news imho.

Re: From First Principles: Why Scala?

#337

Post by still_grokking » Sat, Feb 13, 2021, 10:31 AM UTC

valzam wrote: post #292

solicode wrote: post #79

Earlier quoted context omitted.

I've heard that too but I think there are at least efforts to support Scala 3. Having said that I think Quill looks nicer ( https://getquill.io/ ) if you want a DSL like that.

I haven't used it heavily but one of our newer microservices uses Quill for read-only access to Postgres. I have found it to be great to work with, to combination of "just use case classes" and a DSL that feels like writing SQL is pretty nice.

You can have Quill syntax for Doobie nowadays:

https://tpolecat.github.io/doobie/docs/17-Quill.html

That's by far the best DB access layer I've ever worked with.

Re: From First Principles: Why Scala?

#338

Post by still_grokking » Sat, Feb 13, 2021, 10:47 AM UTC

lmm wrote: post #279

mwcampbell wrote: post #20

I dabbled with Scala several years ago, but I've been using Kotlin for a JVM-based project and am happy with it. My main reason for choosing Kotlin is smoother interop with the JVM world. For example: - Scala adds an Option type, whereas Kotlin adds nullability checking for existing object types. - Scala has its own convention for getters and setters, whereas Kotlin automatically turns JVM getters and setters into pr…

> - Scala adds an Option type, whereas Kotlin adds nullability checking for existing object types. Kotlin's approach amounts to doubling down on null IMO - it actually makes it harder to interoperate with newer JVM code that favours options over nulls (e.g. streams) from Kotlin than from Scala. And since "platform types" are silently treated as non-null, you still get null exceptions at runtime. > - Scala defines its…

My experience is that most Kotlin features boil down to myths created by good marketing. When you look at them in detail they're full of gotchas and unexpected behavior (especially when interacting) due to everything being some ad-hoc special case only created to simulate some Scala feature.

Tones of ad-hoc features isn't good language design imho, even the features are desirable in isolation. That's the same issue as the biggest problem with PHP or C++.

On the other hand side Scala may seem "complicated" on the surface but it's actually just a bunch of quite simple basic principles, and some syntax sugar on top.

Scala is like math: It's build form simple first principles. Just it offers the means to combine those and create this way almost arbitrary complex abstractions.

Re: From First Principles: Why Scala?

#339

Post by tomp » Sat, Feb 13, 2021, 11:44 AM UTC

yw3410 wrote: post #198

Fellshard wrote: post #163

Earlier quoted context omitted.

I've been working through 'Haskell From First Principles', and it turned on a lightbulb: the 'right' half of Either is the 'important' one because its type variable is free to change. instance Functor (Either a) where -- a is fixed here! fmap :: (b -> c) -> Either a b -> Either a c fmap _ (Left l) = Left l fmap f (Right r) = Right (f r) As a general rule, the last type parameter of a type carries special significance…

This is also the reason we have the convention in Scala as well - the inference to partially apply the type works in a certain way. But I agree with the parent post, a more descriptive name would be better.

The obvious (and obviousyl better/correct) name for that type is Result; instead, Either should be unbiased.

Re: From First Principles: Why Scala?

#340

Post by dbsmith83 » Sat, Feb 13, 2021, 7:46 PM UTC

lmm wrote: post #282

dbsmith83 wrote: post #2

Scala is nice for doing things with Spark compared to say, Java, but I really think that Kotlin can do just as well. The only advantage Scala has with Spark is the syntactic sugar. Once there is an API for Kotlin (beyond the preview version), I will be dropping Scala like a bad habit. Kotlin is also concise, has better IntelliJ support, less "implicit magic", and better Java interop. https://github.com/JetBrains/kotl…

Kotlin has lots of syntax sugar but the semantics are crazy. It's essentially an imperative language where the only way to reason about effects (suspend functions) is by reasoning about control flow. That already makes things like error handling incomprehensible, and it'll be a really bad fit for Spark's way of doing things (where values have to be serializable and shipped around the cluster) - imagine trying to use…

I'm curious what your use case is for using a suspend function in spark. I have written several spark jobs with Kotlin and have never had a reason to create one. The only difference from the Scala/Java jobs is that I had to be much more explicit with certain things (encoders in higher order funcs, etc.).