From First Principles: Why Scala? • Hacker News Board

Re: From First Principles: Why Scala?

#241

Post by kaba0 » Thu, Feb 11, 2021, 11:42 PM UTC

darksaints wrote: post #58

agbell wrote: post #4

Great Analysis! I agree that languages are becoming more like Scala. I'm not sure about the JIT part though. Aren't many of the recent language success stories now about AOT compiled languages like Go, Rust and Swift?

There are very few optimizations that a JIT can improve over a static compilation of a strongly-typed language. Strong typing brings immense capability for static analysis and subsequent optimizations. The most successful JIT optimizations out there typically are ones that make dynamic languages about as fast as statically typed languages by making assumptions about the runtime types of objects, while trapping/reopti…

It’s not as black and white. What about GC, compacting objects and the other myriad of optimizations the JVM does? I do want to mention that I am not overly knowledgeable on these topics, only really interested in compiler technology, but a program compiled with PGO will have to add code for each specialized function, won’t it? So perhaps not every sort of application would win by PGO AOT compilation; a structure over the running code, and manipulations over it are a great and powerful idea.

But I do agree that Scala in the early years did have some ugly artifacts from compiling to the JVM and trying to remain a “good citizen“ there, not sure about current trends.

Re: From First Principles: Why Scala?

#242

Post by elmalto » Thu, Feb 11, 2021, 11:42 PM UTC

I have used python and scala for work and I find myself wishing to be able to use scala a lot when I use python (especially when using pandas or trying to multi process/thread). Not so much the other way around even though I also love python and think it’s amazing. Main reason: The type system is great and there are so many things that I can express/enforce using it that are missing for me in python even using typing libraries.

Yes, there is a large crew of FP fans around scala that can be obnoxious at times, but they have also brought a lot of good stuff around. The way I see it: You need groups that “overshoot” and then settle on the middle ground. Compromise...

I use FP when it’s not too complicated, but stay away from the larger monad systems that are hard to explain to newcomers (effects/IO/Kleisli etc) because I honestly feel like it’s too much. Let me just run my debug logger when I want to... (yes I know that’s not what it’s about)

I probably fall in the category of using scala as the (way) better Java with sprinkles of FP and non-mutable data objects everywhere. I really like the authors style (his work is awesome in general and I point to your posts a lot for our juniors, thank you for your contributions if you read this)

It has its flaws, just like any other language, but it’s also incredibly expressive and fast (enough) for the backend and data engineering that we do

Re: From First Principles: Why Scala?

#243

Post by Fellshard » Thu, Feb 11, 2021, 11:44 PM 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.

Right; ostensibly you could create a language that lets you easily poke holes in any slot of a type, but I'm not sure you necessarily /gain/ a lot in doing so except for confusion. It would take a lot more convolution to specify types and instances for every function application.

Re: From First Principles: Why Scala?

#244

Post by valenterry » Thu, Feb 11, 2021, 11:44 PM UTC

stickfigure wrote: post #64

imtringued wrote: post #30

Earlier quoted context omitted.

>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…

Ceylon was (is?) really beautiful. At least type unions/intersections found their way into Typescript. IMO Gavin's biggest mistake was picking Eclipse for the IDE platform at a time when every professional was moving to IntelliJ.

And into Scala 3 too!

Re: From First Principles: Why Scala?

#245

Post by valenterry » Thu, Feb 11, 2021, 11:45 PM 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,…

> Counter-example would be Go, that resists change

Now it gets generics, so we are one step closer to Scala. :)

Re: From First Principles: Why Scala?

#246

Post by thinkharderdev » Thu, Feb 11, 2021, 11:48 PM UTC

MichaelMoser123 wrote: post #235

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…

> The overuse of DSLs in Scala is really annoying. Too many DSLs is another example of something I consider to be an antipattern, but there is no Scala community consensus on the responsible use of DSLs. Domain specific languages are heavy users of the implicit keyword and implicit conversion; maybe that makes the code more concise, but it doesn't quite help with reading / understanding the code. For me that's the gr…

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 that I think is where Scala shines. There are different ecosystems but if you look at something likes cats/cats-effect then there are a core set of type classes on which everything else is built and if you understand those core abstractions then understanding any codebase which uses them is very easy. And those abstractions are extremely flexible to the point where they can be applied to an astonishing variety of problems.

Contrast that with something like Java which, while quite simple syntactically, has a huge and varied super-structure of incongruent abstractions on top of it. Every time I dive into a largish codebase of "enterprise Java" it feels like the engineers has a running bet on who could use the most GoF patterns in any given module.

Re: From First Principles: Why Scala?

#247

Post by kaba0 » Thu, Feb 11, 2021, 11:53 PM UTC

esarbe wrote: post #206

randmeerkat wrote: post #201

Earlier quoted context omitted.

> Or maybe they take longer and deliver a higher quality product. Without going into how do you define a higher quality product, does quality really matter that much..? Most code is going to be re-written every few years anyway. Software engineers aren’t building architectural wonders that will last hundreds or maybe thousands of years. So is the complexity of a language like Scala really worth it, just to deliver a…

Well, I've been working in financial and data services for many, many years now and I can tell you as much: many of the code bases I've been dealing with (and am dealing with) written in less strictly typed languages (much Python, lots and lots a lot Java) are riddled with hidden runtime errors that you'll just never see in Scala. If there's a bug, it's usually some modelling problem or some conceptual issues, not th…

Java has really great tooling to make it really safe if one wants to — the problem is usually the managements’ cheapness with programmers fresh out of school/bootcamp. There are areas with high security requirements where Java is used with great success.

Re: From First Principles: Why Scala?

#248

Post by kaba0 » Thu, Feb 11, 2021, 11:55 PM UTC

chaorace wrote: post #28

asimpletune wrote: post #19

Earlier quoted context omitted.

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…

There are certain algorithms that either can’t or only insanely error prone way can be expressed “purely”. There is nothing wrong with locally mutable state. It is basically the same as a State monad that is evaluated/executed — which can arguably be worse

Re: From First Principles: Why Scala?

#249

Post by lihaoyi » Thu, Feb 11, 2021, 11:55 PM UTC

AzzieElbab wrote: post #220

Scala is awesome. It is meant to be a scalable language where you go from level 1 to say 5 as you learn. Problems arise when you put a level 5 guy into a level 1 team and letting him loose. No common style guide, no team training, just write those type signatures approaching tweets max length and let the rest wonder wth is going on

I'd argue that the real problem is finding people who think they're level 5 but aren't. Writing dense impenetrable code certainly doesn't sound like a high-level engineer to me!

Scala certainly has no shortage of these people, but at my work we throw senior engineers with zero Scala experience or training at the language and it generally turns out OK. Turns out that a 10x faster Python or a 10x more concise Java are selling points enough, even without any fancy code!

Re: From First Principles: Why Scala?

#250

Post by the_af » Thu, Feb 11, 2021, 11:56 PM UTC

philipkglass wrote: post #118

thelittlenag wrote: post #63

Earlier quoted context omitted.

The two major SQL libraries in the Scala ecosystem these days are Doobie ( https://tpolecat.github.io/doobie/ ) and Slick ( https://scala-slick.org/ ). With Doobie you manually write your queries, and then map the results into the objects in your domain model. Nothing is generated for you. OTOH, nothing is hidden and you are free to write queries as optimized and specialized as you need. The real selling point of Doo…

I have had poor experiences with "fancy" SQL libraries in multiple languages. This includes Slick and Quill in Scala. I don't remember what the problems were with Slick that leave such a bad feeling when I hear its name -- that was 5 years ago -- but I had problems with Quill just last year. I was trying to use it to generate an efficient "in" query against a two column composite primary key, and nothing seemed to wo…

I didn't have a good experience with scalikejdbc, which was what we ended up using. Possibly we didn't use it well, and I can't remember the details now, but our DB code ended up looking like a mess.