Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

From First Principles: Why Scala?

lihaoyi.com

Post reply on HN
Print view View original

221–230 of 342 posts

Re: From First Principles: Why Scala?

#221

Post by mwcampbell »

zmmmmm wrote: post #197
ebruchez wrote: post #127

Earlier quoted context omitted.

> Scala defines its own set of collection classes [...] And that is a huge benefit. Scala collections are really great. In addition , Scala also has wrappers around Java collections for interop, or you can just use plain Java collections directly.

> Scala collections are really great. It doesn't really matter how great they are, it kills JVM interop right there ... and its even worse if it doesn't and you get implicit conversions killing your performance. This is where there is a bit of bait and switch with the JVM story (applies to a lot of JVM languages) - "language has great feature X" and "use any library from the JVM ecosystem" - often turn out to be mutu…

> Groovy is the only JVM language I've found that seems to deliver a real JVM interop story

Have you tried Kotlin yet? If so, what interferes with its JVM interop story in your opinion? I'm happily using Kotlin with several Java libraries, and IIRC, no Kotlin-specific libraries except for the stdlib.

Re: From First Principles: Why Scala?

#222

Post by kaba0 »

desbo wrote: post #209
yw3410 wrote: post #204

Earlier quoted context omitted.

Yes - but you /also/ lose the stack trace and it's /far/ too easy to do; hence my OP. It is /infuriating/ to be knee-deep trying to work out which of your 30 Eithers failed with a non-descript error.

You don't necessarily lose the stack trace. Typically the left side of an either is an Exception (or an error ADT that wraps one). When you want to handle the left case, you can log out the full trace as you would without Either. The Monad instance for Either means that chaining them together with flatMap has a short-circuiting effect and the first failure will stop the rest of the chain from being evaluated. I find…

Hmm, when I first learnt Scala, I haven’t had too advanced FP knowledge, so I am yet to have first-hand experience with this sort of exception-handling and I’m yet to decide how good it is.

Compared to Haskell, it is probably better in some way because you have the proper stacktrace; but it “feels” impure a bit.. In a way Java’s exceptions are already an Either type with the result type and the thrown Exception (with “auto-decomposition”, unless checked exceptions) —- is the advantages like manual management of when mapping/flatmapping happens worth it in your opinion? Nonetheless thanks for the heads up, I might try out Scala again with the exception handling model you mentioned!

Re: From First Principles: Why Scala?

#223

Post by smabie »

lihaoyi wrote: post #130
jolux wrote: post #33

Earlier quoted context omitted.

F#

I actually came to Scala via F#. You can even find exact dates of those transitions in my stackoverflow history. Scala and F# are sinilar enough to basically be the same language, though I found F# had a number of warts and idiosyncracies that made me move on to Scala. Scala didn't have all of these (though of course it had warts of its own!) and is what stuck with me for the long term

F# has a much more primitive type system than Scala and isn't particularly impressive imo. And it doesn't have functors ala OCaml.

Re: From First Principles: Why Scala?

#224

Post by jjav »

brabel wrote: post #140
dkarl wrote: post #74

Earlier quoted context omitted.

I'm on exactly that kind of team now. They've been working on a very simple problem for several years now and have an enormous, sophisticated, but still buggy and unstable solution. They're really smart people, and they had to be extremely capable programmers to get this far, but the embarrassing question is, how would a team of mediocre developers have tackled this problem? They would have picked a mediocre language…

I am fairly certain the jury is out on this question: It's always better to write simple, almost dumb code that anyone can understand than to use advanced abstractions from category theory or whatever. Why? Because every single study or anedocte I've ever heard is like yours: adding complex abstractions to code do NOT make it more reliable. But they do make it much harder to modify, understand, and fix. FP tought us…

> the other lesson from FP: overly complex abstractions are also very bad

Lisp, in its persistent failure to achieve world domination, has been teaching us this lesson for over 60 years now!

Infinitely powerful languages are fun and, yes, powerful. But as soon as the project has more than one or two people in it, they also result in runaway complexity that will hurt the product far more than any gains in expressibility.

Re: From First Principles: Why Scala?

#225

Post by einpoklum »

The article mostly lost me with two points:

* It claims to be a compiled language "like C++ and Java" - not making a distinction between targeting multiple hardware platforms and targeting a cozy VM.

* It ties itself strongly to the Java ecosystem.

So, I guess I might consider it in the 'nicer Java' category - and it does seem nicer than Java, subjectively - but not outside of that ecosystem.

Re: From First Principles: Why Scala?

#227

Post by kaba0 »

msluyter wrote: post #75
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…

After a number of years with Python, I started a position working in Scala about 6 months ago. I really wanted to learn something new, and become acquainted with functional programming concepts. I agree with most of the above. A couple of additional thoughts: * sbt -- I still have a lot of coming up to speed to do here, but the manual is like 500 pages and it's somewhat overwhelming. There are tons of little oddities…

I learnt Scala before diving deeper into FP, but I think properly learning/understanding Monads and some other FP concepts greatly help every sort of programming I do (even though it is mostly OOP nowadays). You come to notice it everywhere and even if you can’t abstract over them (there is no one `bind` or `join` function, so it may be called different with each Monad instance), but after understanding them you will gain a better reasoning power over them.

Re: From First Principles: Why Scala?

#228

Post by joshlemer »

dkarl wrote: post #203
joshlemer wrote: post #142

Earlier quoted context omitted.

This is spot on! Way too often in Scala codebases, which tend to wrap IO calls in Future or similar is that you'll have chains of side effecting futures like readFromDb() .flatMap(x => doSomethingElse(x)) .flatMap(x => doSomethingElseAgain(x)) .flatMap(x => onceAgain(x)) And this all gets passed up the call stack to one generic thing that basically does nothing in the case of error, maybe logging it and that's it. It…

Amen. I saw exactly the same problem with over-reliance on flatMap, either explicitly or in for expressions, in future-heavy Akka code that I do in cats and cats-effect code. People love the unifying abstractions underneath these types, and they love developing instincts about how to write code based on them, but from an application programming point of view, their instincts are often counterproductive. I don't think…

That's a great observation about for-comprehensions. It's an other one of these cute niceties that in the most basic cases can come in handy but again nudges users away from consciously thinking through what they're doing (good luck handling the error path in a for-comprehension over Futures).

Re: From First Principles: Why Scala?

#229

Post by lihaoyi »

tanin wrote: post #214

I'm a big fan of Scala, though I think the sweet spot for Scala is for a small team with pre-existing Scala's expertise. For a one-person project, I definitely use Scala. I used to use Ruby a lot. You can move fast with safety with the caveat that the code quality is harder to manage/control. Contrasting this with golang where they really take the guard rails to the other extreme (e.g. can't compile if a variable is…

We're scaling out Scala to a larger team here at work, and part of the effort is certainly about putting in guardrails.

In fact, a lot of it is putting in thr guardrails people like from Go: enforced autoformatting, banning unused variables, fatal warnings, etc. are all just a flip of a switch these days (though we only enforce these things on-merge, people are free to test locally regardless, which I understand is a big pain point in Go!)

Re: From First Principles: Why Scala?

#230

Post by valenterry »

yawaramin wrote: post #126
valenterry wrote: post #52

Earlier quoted context omitted.

Let's clarify some points for folks not so familiar with Scala. > * Scala minor version are binary incompatible, so maintaining Scala projects is a big pain. Upgrading Spark from Scala 2.11 to Scala 2.12 was a massive undertaking for example. Scala just chose a strange naming scheme. Other languages would have just increased their major version instead. The scala minor version is increased every few years and not eve…

Did you mean: values: DataValue ? Otherwise the decoder is incorrect and, I'm not 100% sure but, is likely to throw a runtime error.

You are totally right!
Post reply on HN