Live data from Hacker News

From First Principles: Why Scala?

lihaoyi.com

21–30 of 342 posts

Re: From First Principles: Why Scala?

#21

If I've said it once I've said it a thousand times: the day Scala kills sbt officially will be the day thousands of devs consider a return to it. Until then, I couldn't dare.

For new Scala devs, how much of a challenge is it to avoid sbt?

Especially for those coming from languages like Python and Go, where the former has no build system (ignoring setup.py), or an almost universal one (go build, sometimes make).

All of the projects I have touched are documented using sbt, and transitioning the build process for existing code projects while a new language learner is a double cognitive load.

Re: From First Principles: Why Scala?

#22

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…

What newer hybrid languages besides Kotlin can cover the benefits you can get with Scala: a solid ecosystem (both for Scala and Java) for developing web applications, microservices, data processing, and good performance.

Julia, Rust, and Elixir are all great, but popularity, ecosystem are not there yet.

Re: From First Principles: Why Scala?

#23

If I've said it once I've said it a thousand times: the day Scala kills sbt officially will be the day thousands of devs consider a return to it. Until then, I couldn't dare.

curious. what exactly is wrong with sbt? I used it once of twice when I was learning scala and I liked it a LOT more than gradle/maven. To the point where I actually opted to use it with my Kotlin projects later.

To me, sbt is confusing as hell.

I no longer program in Scala, but I used to for my previous job and I regularly came across build files I couldn't understand -- and when I asked the person who wrote them, they couldn't explain their build properly either.

And this happened in enough cases that I wouldn't consider it an exception or a problem with a particular developer. SBT used to have two entirely separate syntaxes, and it was a mess translating from one to the other. I don't know if this is still the case (I know one of the two syntaxes got deprecated, can't remember which one now).

Re: From First Principles: Why Scala?

#24
post #17

Scala is one of those great languages with that one Achilles heel. The speed of that compiler: $ time scalac Hello.scala real 0m2,907s user 0m7,901s sys 0m0,308s $ cat Hello.scala object Hello{ def main(args: Array[String]){ println("hello world") } } Implicit type conversion can be debated I guess, but otherwise a very beautiful language.

Yeah cold compiles are slow, but most modern tools keep a hot compiler to re-use and once warm a hot compile of hello world is more like ~200ms. There's a bit of complexity managing these daemons, but that's something that the build tool normaly handles for you transparently

Re: From First Principles: Why Scala?

#25
post #8

If I've said it once I've said it a thousand times: the day Scala kills sbt officially will be the day thousands of devs consider a return to it. Until then, I couldn't dare.

It looks like its a build tool? Are you obligated to use that with scala or something?

You're not obligated, but much like Maven is the build tool for Java, sbt is the build tool for Scala.

You use alternatives at your own peril. This means you won't be able to understand other people's builds, for example.

I know some Scala projects use Maven instead. Whether that's a good idea is debatable!

Re: From First Principles: Why Scala?

#26

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 defines its own set of collection classes [...]

One (arguably) negative consequence of this is that Scala's collections don't play nice with Hibernate and similar ORMs. Due to the way they work, both Scala and Hibernate wanted to "take over" your collections, and obviously they cannot do so at the same time. Of course, it's arguable whether this is a flaw with Scala or with Hibernate, but for the programmers who just wants to get things done that's irrelevant.

It used to be a big deal a few years ago, to the point teams in my company decided to either drop Hibernate or drop Scala.

PS: if I remember correctly, early Scala adopters had reached the consensus that ORMs didn't play nice with Scala's FP style anyway, and so using Hibernate was a mistake. Possibly this attitude changed later.

Re: From First Principles: Why Scala?

#27

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…

Scala has learned from Scala's mistakes too. Scala 3 cleans up a lot of the mess that had accumulated over the years and is on the cusp of being rolled out this month.

Re: From First Principles: Why Scala?

#28
post #14

Scala is just an amazing language. I'm very happy that the worst of the 'Scala as a worse Haskell' days is over and that the Scala community is finding it's own programming style. I remember years ago when I had a heated discussion about local mutable state. An that time it felt like heresy to even suggest it. I just recently had another discussion with the same programmer and he was like: "Yeah, that works". Good ti…

Local mutable state as in a var in a function or how did you mean?

Basically that, yes. The idea is, as long as the mutable state starts and ends within the confines of an individual function, you can get away with treating that function as if it were "truly" FP.

The main argument against this is that it's a concession that makes the codebase less coherent. The more hardline argument being that the encapsulated mutable state is still more prone to bugs and should be almost always be avoided, except at great cost.

Re: From First Principles: Why Scala?

#29

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…

What newer hybrid languages besides Kotlin can cover the benefits you can get with Scala: a solid ecosystem (both for Scala and Java) for developing web applications, microservices, data processing, and good performance. Julia, Rust, and Elixir are all great, but popularity, ecosystem are not there yet.

For Julia there are PyCall and RCall, so the ecosystem is less of an issue than with other languages. Also, its ecosystem has been growing quickly over the last 2 years or so.

https://github.com/JuliaPy/PyCall.jl

https://github.com/JuliaInterop/RCall.jl

Re: From First Principles: Why Scala?

#30

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…

>the sacrifices needed to ensure Java compatibility entail many quirks that I find frustrating.

That reminds me of that dead JVM language called Ceylon. It didn't compromise anything to ensure Java compatibility. The combination of OOP+FP was executed with zero friction. Meanwhile Scala did it so poorly it created a stupid myth that OOP and FP shouldn't mix.

Of course everyone knows that nobody used Ceylon, not even Redhat who sponsored the language. The compiler was also dog slow. Typechecking complicated type unions/intersections can get really slow with bigger projects. The metamodel also created a lot of JS bloat if you were brave enough to use it in the browser. Lots of practical complaints that ultimately make you stop using it. But oh man the idea and design. It was very well thought out and enjoyable to program in.

Post reply on HN