Live data from Hacker News

From First Principles: Why Scala?

lihaoyi.com

321–330 of 342 posts

Re: From First Principles: Why Scala?

#321

Earlier quoted context omitted.

The way I tend to think about it is that there are different axes of "complexity" in a language/ecosystem. Looking only at the language itself then yes Scala is quite complicated with a lot of language features (implicit, higher-minded types, macros, ...) that are uncommon in other popular languages. But another axis to consider is "how many abstractions do I need to understand in order to grok a large codebase?" And…

good point! on the other hand java got some functional features since java8 (lambda/streams/option chaining) that allow to have less bloated code; i think nowadays it is (at least) possible to have a less design pattern heavy code style in java.

True. Java has improved substantially since java8 (including something kinda sorta like case classes with record types in jdk15) but I still think Scala is miles better. I don't think it is generally appreciated how essential higher-minded types and typeclasses are to making functional programming tractable and safe. Perhaps because it is something that is generally hidden away in libraries and developers working on actual application code (i.e. 99% of scala devs) never use them.

Re: From First Principles: Why Scala?

#322

Earlier quoted context omitted.

Don't bother, I have the feeling randmeerkat will argue that if the team is so big, the language must be not expressive!

I have no gripe with Clojure, I take issue with someone claiming that Amazon, Apple, and Netflix have systems that operate at scale because of it. Clojure is a fine niche language, but it’s not the secret sauce to big tech web scale.

I was not claiming that, just that also big companies use it. It may not be used for the core of the business but I'm convinced the services that are build with Clojure are reliable, because the language is solid.

Re: From First Principles: Why Scala?

#323

Earlier quoted context omitted.

You shouldn't swallow errors like that in FP either. You can trap the error in an effect type and throw it at the top level of your app when your effect type gets run after all of the code that processes that error value has a chance to recover. See something like Zio for an example, though you can do similar things without Zio.

If the team uses Zio, or maybe they’ve gotten lost in the religious war of Scalaz, vs Cats, vs Zio... One of the major issues I have with Scala is how fragmented the community is. Everyone has an opinion on how something should be done and everyone thinks that everyone else is wrong.

Well you have extremist who believe that you have to cull the community due to a few bad (but still contributing) apples. Additionally you have a big lightbending company that produces some questionable contributions to the community as if it's the "scala-endorsed way".

Don't get me started with the whole forcing of "lets be python like" initiatives as of late.

Re: From First Principles: Why Scala?

#324

Earlier quoted context omitted.

> It doesn't really matter how great they are, it kills JVM interop right there ... That's extreme. It really doesn't "kill" interop at all. If you want to convert, convert. There are many cases where you are not calling Java in hot paths and where converting is perfectly acceptable. If you don't want to, then don't and use Java collections directly. You have the best of both worlds depending on what kind of code bas…

It only interoperates with Java in a trivial sense. Using Hibernate for example is a real pain in the ass in Scala, because of its insistence on using its own collections.

> It only interoperates with Java in a trivial sense.

It's not in a "trivial sense". You can call any Java code from Scala, call Scala code from Java (except when dealing with Scala constructs that don't have direct Java equivalents). Even Java and Scala functions are the same since Java 8/Scala 2.12. I am not sure how much more interoperability you could even wish again, besides saying that Scala should be identical to Scala. And I write this having written Scala for 10 years and used dozens of Java libraries in Scala projects.

> because of its insistence on using its own collections

This reads like Scala is somehow doing this stubbornly against all reasonable arguments. That's not the case. Scala collections have benefits. Maybe this means using Hibernate is not straightforward from Scala. Ok. I don't know. But this doesn't invalidate Scala having its own collections.

There are tradeoffs in everything. We are talking about two languages and how they interoperate. As far as language integrations go, the Java-Scala interop is excellent, in my view.

Re: From First Principles: Why Scala?

#325

Earlier quoted context omitted.

It might be worth mentioning that Scala now compiles to 3 different targets: - JVM - JavaScript (Scala.js) - native (Scala Native) The tie to the Java ecosystem has significantly loosened over the last few years.

That is interesting... but it's also the opposite message from the article. It even emphasizes again how Scala "leans heavily" on the JVM: > The last thing that Scala does well is to lean heavily on the host language for both its language semantics as well as its implementation. Scala is typically run on the JVM, which together with the Java ecosystem provides a host of useful things that Scala doesn't need to worry…

I should add to lihaoyi's reply that in addition to the target environment's libraries, many Scala libraries cross-compile for Scala JVM, Scala.js, and (to a lesser extent due to its relative novelty) Scala Native.

For example I am now cross-compiling JVM/JS a fairly large project which uses, directly or indirectly, Circe, Cats, ScalaTest, Enumeratum, Shapeless, and Parboiled2, and all of that works flawlessly.

Re: From First Principles: Why Scala?

#326

Earlier quoted context omitted.

I dunno. You see the same pattern with chained class methods in Python and it suffers from the same exception specificity problems, but doing it is still a fair judgment call. Sometimes all you need to know is that there was an error in the chain. Like if an exception is raised by dataframe.transpose().to_dict().values() I don’t ask myself where in the chain the error occurred, I just think, “oh that’s weird why coul…

Your point's well taken. I'd say that there is a bigger issue in the case of flatMapping side-effectful monads because they're typically dealing with things like writing/reading from databases and the error cases should be thoughtfully considered (do I have to roll something back or perform compensating actions, or clean up anything?)

If understood “flatmapping monads” as anything other than the name of a band I’m sure I would agree.

Re: From First Principles: Why Scala?

#327
post #270
post #160

Earlier quoted context omitted.

What makes this quote really interesting is that Wirth was Martin Odersky's (guy who designed Scala) PhD advisor!

Scala is a very simple language at its heart. Unfortunately that empowers developers to write really complicated libraries, leaving application developers in much the same place as if they were using a language with complicated features. (Most application developers can't even tell the difference - most complaints about "Scala is a complex language" turn out to be "I was using a complex library in Scala")

Implicits are responsible for most of Scala's complexity whether you grok them or not.

Re: From First Principles: Why Scala?

#328
post #301

Earlier quoted context omitted.

In my view though, Kotlin is just a much better version of that. But of course if you have lots of scala investment already, it makes more sense to do it within scala itself.

Why?

It comes with the same easy Java interop, but is a much smaller simpler language, while in my view managing to include essentially all of the most useful ergonomic improvements (over Java) that Scala does, but with essentially none of the more complex baggage.

Re: From First Principles: Why Scala?

#329
post #62

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…

Overheard on a Java conference: "I love Scala, clients pay me big bucks to rewrite it into sane Java code".

Java - the terraced housing of programming. Still, point taken.

Re: From First Principles: Why Scala?

#330
post #104
post #82

Earlier quoted context omitted.

Scala 3 has type-classes as a core feature.

Right. We don't have a full production 3.0 release yet, so I tend to think of "Scala" as Scala 2 unless it's specifically qualified as Scala 3. Scala 3 seems to be a really good step in the right direction for me. There's a clear desire for many of the features that are currently achieved through burdensome hacks on top of implicits, and actually reifying several of them into core language features is a counterintuit…

As far as I'm aware implicits are alive and well in Scala 3 and will, I predict, be Scala's ultimate downfall.
Post reply on HN