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

231–240 of 342 posts

Re: From First Principles: Why Scala?

#231

Post by yw3410 »

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…

Sure - you can implicit srcloc or capture the Exception, both of which preserve it; but that's not the default behaviour and it's not what we recommend to beginners.

If you go onto the scaladoc for Either today, you see a stringly-typed Either where they discard the Exception.

Re: From First Principles: Why Scala?

#232

Post by ebruchez »

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…

> 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 base and libraries you are dealing with

Also, implicit conversions between Scala and Java collections have been discouraged/deprecated for years now. You should use the explicit conversion when needed, with `.asScala` or `.asJava`. This makes it obvious whether you might pay a price in the conversion.

Finally, your position overlooks the fact that there are solid reasons to use and prefer Scala collections instead of Java collections: they are quite feature-rich compared to Java collections, are immutable by default, while providing mutable collections if you want those as well.

> that's explicitly because it is designed from the ground up for that

Scala was designed for Java interop from the get go. I am not sure how you are suggesting making things better, besides saying that Scala should never have had its own collections. That would take away a huge part of what makes Scala great, in my book.

Re: From First Principles: Why Scala?

#233

Post by kaba0 »

prionassembly wrote: post #210

I want to switch away from Python, at least for personal projects. I want to broaden my range, experiment with weird paradigms (Raku) or get code that’s a little faster (eg Rust). The problem is that I use Python as a “glue language” and heavily rely on excellent third party libraries. I don’t want to learn how to write a minimum spanning theorem algorithm; I’m used to have it next to several other convenient graph u…

The JVM ecosystem is similarly rich (and basically the only one comparable; there are many js packages but they are more opinionated towards web development), with plenty of languages to choose from (and with Graal’s python implementation you can even write python code that interoperates with other JVM code)

As for concrete languages, I like Java, because it has just enough abstraction to make it useful and is not overly complex. Scala is a real gem in that it was one of the first OOP+FP hybrid, a marriage that seems really fruitful since then basically every OOP lang introduced more and more FP concepts and vice versa. There is also Clojure if you are into LISPs. If overly functional programming is not your thing, Kotlin is a modern language with some additional features to Java though I am not particularly fond of it. And there are even more niche languages running on top of it.

But the real gem is the JVM itself, and it is really actively developed and many new, exciting features are in the works.

Re: From First Principles: Why Scala?

#234

Post by lihaoyi »

fulafel wrote: post #151
lihaoyi wrote: post #106

Earlier quoted context omitted.

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

How is concurrency implemented in Scala.js? Eg switching tasks when you use Future for concurrent long running tasks that do IO or sleep?

Scala's Futures work unchanged, it just has a single-threaded threadpool instead of a multithreaded one. Anything built on Futures (e.g. my Castor actor library) is unchanged as well.

Scala Futures are more or less a 1:1 mapping to Javascript Promises, and work identically.

There isn't long running IO or sleeps, same JS, but this isn't a big problem in practice. As long as you're not juggling threads directly - and most Scala code doesn't - your code should run unchanged concurrency-wise in Scala.js just with no parallelism. Though of course you can't use OS interfaces like java.nio.file.Files in the browser!

Re: From First Principles: Why Scala?

#235

Post by MichaelMoser123 »

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 greatest problem with scala - figuring out what this code in front of me does.

Re: From First Principles: Why Scala?

#236

Post by yw3410 »

hderms wrote: post #202
spion wrote: post #168

Earlier quoted context omitted.

And will you get a call trace when you do that?

we use error types that extend Exception specifically for the purpose of getting a call trace. A lot of people hate doing this but it's been extremely helpful on our project

We do this too - but the other problem you get is that Exception aren't treated specially (like Any and Nothing) in the inference hierarchy so errors are liable to "collapse" to Throwable or Exception. I like wrapping them with a new type if possible to stop this behaviour.

Re: From First Principles: Why Scala?

#237

Post by valenterry »

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…

That's a common falsehood though.

It does not matter how "simple" each line of code is.

What matters is how "simple" the whole application/solution is.

You can argue that you can write very simple code in Assembler - all instructions are very clearly defined and very simple (well, maybe not anymore in CISC...). Someone can learn them all in a day. The problem is just that now you end up with a lot of code and overall that will be hard to maintain.

Compare it to Javascript: certainly not the language where code is most maintainable or simple, but the end-result is easier to maintain then assembler.

In the end, the choice of programming language is like a the choice of a compression-tool like gzip. The more complex, the more difficult to learn and use (setting library size and various compression settings) but the output will be smaller compared to a simple tool or no compression (Assembler) while containing the same amount of information.

Re: From First Principles: Why Scala?

#238

Post by rodelrod »

prionassembly wrote: post #210

I want to switch away from Python, at least for personal projects. I want to broaden my range, experiment with weird paradigms (Raku) or get code that’s a little faster (eg Rust). The problem is that I use Python as a “glue language” and heavily rely on excellent third party libraries. I don’t want to learn how to write a minimum spanning theorem algorithm; I’m used to have it next to several other convenient graph u…

So you've found a tool that works great for your purposes. Why is that a bad thing?

Re: From First Principles: Why Scala?

#239

Post by lihaoyi »

uDontKnowMe wrote: post #68
dkarl wrote: post #55

Earlier quoted context omitted.

Unfortunately, "Scala as a worse Haskell" is alive and well. The /r/Scala subreddit, for example, is dominated by folks who tell every Scala-curious beginner who drops by that the accepted right way to write Scala is the pure FP ecosystem and everything else died a long time ago. There are beautiful, simple, elegant ways to write Scala, but I'm afraid that the community isn't converging on a single concrete style, an…

Yep this is a huge cultural problem with the Scala community. On paper and in marketing material, Scala is flexible enough to empower you to slip into mutable/OOP style or more FP style. But in practice the pure FP enthusiasts are the ones who totally dominate the ecosystem (aside from Haoyi Li). You simply cannot just ignore the Haskell Larpers/Wannabe's and get on with it, because they infect all the community wate…

It's true that hardcore FP folks have been a problem in the past, and to some extent still are.

However, things have definitely gotten a lot better now. There's a large contingent of "boring Scala" folks in the online community, and its growing. See this discussion https://www.reddit.com/r/scala/comments/lfbjcf/does_anyone_h... for example

AFAIK a lot of the wannabe-Haskell-programmers ended up transitioning fully to actual-Haskell-programmers too, which is probably a win-win that's good for everyone involved. Life's to short to use a language you hate, different strokes for different folks and all.

Re: From First Principles: Why Scala?

#240

Post by thinkharderdev »

randmeerkat wrote: post #201
thinkharderdev wrote: post #188

Earlier quoted context omitted.

Maybe. I certainly don't have data on it but am also not sure what sort of data would actually prove that point. Teams that choose Scala may just be solving different sorts of problems. Or maybe they take longer and deliver a higher quality product. All I know if that I am personally way more productive in Scala than any other language I've used (and I have used most of them at one point or another).

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

On the margin, yes. If a language helps to deliver a better product (fewer bugs, more dependable, etc) then your prior should be that that is a good thing that will, all else equal, make for a better product. But I don't accept the premise that it is easier and faster to deliver a working product in a different language. Maybe it is in some cases but me and my time are most productive and produce the highest quality product using Scala. And I think that has a lot to do with the language and the ecosystem itself. But ymmv and if it's not a good fit for your team then you shouldn't use it.
Post reply on HN