From First Principles: Why Scala? • Hacker News Board

Re: From First Principles: Why Scala?

#101

Post by vemv » Thu, Feb 11, 2021, 5:21 PM UTC

> In contrast, cross-compilers for dynamic languages like Clojure tend to have a long-list of caveats and incompatibilites

I don't think the author fully comprehended the linked resource (namely https://clojurescript.org/about/differences). Perhaps he just noted the its size.

A good chunk of the document lists things in common, not differences. The actual differences have nothing to do with dynamic typing and are deliberate design decisions:

- don't pretend the JVM and JS have identical runtimes when it comes to concurrency or numerics. Clojure is a language, not a platform abstraction.

- Emit efficient, optimally minifiable javascript code, at the cost of offering something less traditionally lisp-y when it comes to eval, macros, and other forms of code loading. Those are still possible, but some discipline is imposed.

Re: From First Principles: Why Scala?

#102

Post by thelittlenag » Thu, Feb 11, 2021, 5:30 PM UTC

joshlemer wrote: post #72

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…

Nobody should be recommending Slick to anyone for new projects. Slick will not be supported in the future.

Lightbend is planning to end support and development of Slick? This is the first I've heard of this. Can you point me towards what they've said?

Re: From First Principles: Why Scala?

#103

Post by meowzero » Thu, Feb 11, 2021, 5:31 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…

> - Scala adds an Option type, whereas Kotlin adds nullability checking for existing object types.

I like null coalescing, but Scala uses a more generic way to handle nulls like Options. After working with both, I'm not sure which way I prefer. I do like not having to create new syntax for language features and could be handled with a monad. Async/await is another that can be handled with an IO, Future, ZIO, etc.

Re: From First Principles: Why Scala?

#104

Post by pdpi » Thu, Feb 11, 2021, 5:31 PM UTC

yw3410 wrote: post #82

pdpi wrote: post #77

Earlier quoted context omitted.

> Scala has tons of language features and lets people do crazy things in the code. In many ways, it's even worse than that. Scala has exactly two features (implicits and punctuation-free method calls) that allow you to build massively complicated libraries that pretend to be language features, and which work worse than equivalent features in languages that support them explicitly. A good example of this is typeclasse…

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 counterintuitive way to make things simpler rather than more complicated.

Re: From First Principles: Why Scala?

#105

Post by yw3410 » Thu, Feb 11, 2021, 5:31 PM UTC

Kototama wrote: post #95

yw3410 wrote: post #81

Earlier quoted context omitted.

I am continually perplexed at the swallowing of exceptions in certain FP communities. Result types, Either et cetera make it extremely easy to swallow errors by flatMapping thoughtlessly losing the context of where they were - you typically /want/ the call stack when you hit into an exceptional flow.

It makes the code impure (that is with side-effects). One can also argue that if you can encode the potential errors in the type they are not exceptional. It's not that bad though, because you get much less of these kind of errors than in a typical Java program (for example).

Yes, it is a side-effect - and does make the code impure; but it's an /exceptional/ flow like OOM, infinite looping, stack overflows which also break equational reasoning.

My argument is that as a programmer you /choose/ the base lemmas which you're comfortable with - with an exception you're saying for a large swathe of your code, it will assume a lemma. When is /does/ break you get to point the finger at it with a stack trace saying here is where the lemma was broken. As an aside there are nicer ways to do this ala contracts, but exceptions aren't a /bad/ way.

The equivalent of try.toOption is try catch everything and discarding. The equivalent of flatMapping without adding surrounding context is equivalent to try catch rethrowing. Both of these are /much/ too common in FP codebases.

Re: From First Principles: Why Scala?

#106

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

vemv wrote: post #101

> In contrast, cross-compilers for dynamic languages like Clojure tend to have a long-list of caveats and incompatibilites I don't think the author fully comprehended the linked resource (namely https://clojurescript.org/about/differences ). Perhaps he just noted the its size. A good chunk of the document lists things in common, not differences. The actual differences have nothing to do with dynamic typing and are de…

> - don't pretend the JVM and JS have identical runtimes when it comes to concurrency or numerics. Clojure is a language, not a platform abstraction.

> - Emit efficient, optimally minifiable javascript code, at the cost of offering something less traditionally lisp-y when it comes to eval, macros, and other forms of code loading. Those are still possible, but some discipline is imposed.

This is exactly the kind of thing I'm talking about: Scala.js doesn't need to make these tradeoffs at all! Concurrency works identically (just no parallelism), numerics work identically, macros work identically. The list of pure-Scala things that behave differently in Scala.js is shockingly short (https://www.scala-js.org/doc/semantics.html)

Scala.js sacrifices none of these and still emits efficient (sometimes faster than idiomatic JS!), optimally minifiable javascript code. The fact that Clojure needs to make these tradeoffs and Scala doesn't is largely due to Scala's static nature allowing more aggressive analysis and optimisation at compile time. For example, the reason Scala.js can provide exact semantics for numerics while maintaining high performance is precisely because it knows what exactly types things are, and can use that information to optimize the generated JS in a semantics-preserving way (http://lampwww.epfl.ch/~doeraene/presentations/jslongs-vmm20...)

Re: From First Principles: Why Scala?

#107

Post by dmux » Thu, Feb 11, 2021, 5:32 PM UTC

Cthulhu_ wrote: post #43

dominotw wrote: post #40

Earlier quoted context omitted.

> Hard to win technical arguments with Scala geniuses that like using complicated language features. I was on a team building good old crud apps using monads, monoids, categories, combinators, effects cats, seamless and bunch of other nonsense that i've now purged from my brain. You could've easily mistaken our team for a programming language research group at a university. This is literally the number one reason i w…

This is my biggest gripe with Scala as well. I'm sure it's a great language, but I've often seen it used to add complexity where none is necessary. It's abused to give developers a sense of accomplishment and intellectual superiority. In fact, in one project my former employer was involved in, one main reason they picked Scala was to, on the one hand, weed out the chaff from their existing team of .net developers (in…

>...I've often seen it used to add complexity where none is necessary.

This reminded me of a great blurb about Niklaus Wirth's approach to languages:

>Wirth’s philosophy of programming languages is that a complex language is not required to solve a complex problem. On the contrary, he believes that l languages containing complex features whose purposes are to solve complex problems actually hinder the problem solving effort. The idea is that it is difficult enough for a programmer to solve a complex problem without having to also cope with the complexity of the language. Having a simple programming language as a tool reduces the total complexity of the problem to be solved. [0]

[0] Pg.2 http://www.cslab.pepperdine.edu/warford/ComputingFundamental...

Re: From First Principles: Why Scala?

#108

Post by yw3410 » Thu, Feb 11, 2021, 5:33 PM UTC

runT1ME wrote: post #93

dominotw wrote: post #40

Earlier quoted context omitted.

> Hard to win technical arguments with Scala geniuses that like using complicated language features. I was on a team building good old crud apps using monads, monoids, categories, combinators, effects cats, seamless and bunch of other nonsense that i've now purged from my brain. You could've easily mistaken our team for a programming language research group at a university. This is literally the number one reason i w…

>I was on a team building good old crud apps using monads, monoids, categories Here's the thing, if you look at a basic Spring crud app, you are also using Monads, Monoids, Categories, Traverse, etc. but you aren't expressing it in the type system. Seriously go look at modern Spring's flux stuff, it's all there minus the type classes. I've seen teams that tried to over engineer Spring, teams that tried to over engine…

Verizon's Scala projects are very cool - I wish that they got more limelight and documentation/support.

Re: From First Principles: Why Scala?

#109

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

_a1_ wrote: post #42

bjarneh wrote: 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.

Using scalac is not a standard use case. Standard use case is to use sbt (well, or mill, since we're in lihaoyi's thread :D). Sbt starts up slow, but with bloop, or sbtn (native client of sbt), the compilation is really fast (much faster than C++ for example): $ time sbtc compile [info] entering *experimental* thin client - BEEP WHIRR [info] terminate the server with `shutdown` > compile [info] compiling 1 Scala sour…

Yeah, set 1.4 was a huge improvement. I wrote a lot of scala several years ago and just got back into it this year and the dev experience is much nicer now with the SBT sever model

Re: From First Principles: Why Scala?

#110

Post by rubyn00bie » Thu, Feb 11, 2021, 5:34 PM UTC

I loved Scala until a minor version updated somewhere around 2.9-2.11 destroyed all my hope. Eight years later I still refused to use it to build anything. Yet, with that said, IMHO, it can be fucking great _second_ language.

If you haven't used a statically typed language before, i.e. you're from Ruby, JS, Python, et. al then it's one bangin' ass brain rodeo. I'd highly recommend spending a couple months trying to learn it. Once you're done, you will almost certainly spend near zero effort learning any other typesystem save the MLs (which would, in some ways, probably be a better rodeo).

One of my favorite "ah-ha! that is totally how it fucking works" moments with Scala was going to see how `Function` worked only to find this bad boi: https://www.scala-lang.org/api/current/scala/Function22.html

A lot of time people think there's more magic going on than there is and just seeing that's how a function works with 22 arguments was pretty illuminating for me coming from Ruby.