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.
From First Principles: Why Scala?
321–330 of 342 posts
Re: From First Principles: Why Scala?
#322Earlier 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.
Re: From First Principles: Why Scala?
#323Earlier 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.
Don't get me started with the whole forcing of "lets be python like" initiatives as of late.
Re: From First Principles: Why Scala?
#324Earlier 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'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?
#325Earlier 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…
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?
#326Earlier 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?)
Re: From First Principles: Why Scala?
#327Earlier 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")
Re: From First Principles: Why Scala?
#328Earlier 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?
Re: From First Principles: Why Scala?
#329I 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".
Re: From First Principles: Why Scala?
#330Earlier 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…