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

Scala projects are difficult to maintain

mungingdata.com

Post reply on HN
Print view View original

131–140 of 235 posts

Re: Scala projects are difficult to maintain

#131

Post by the_only_law »

a4isms wrote: post #108
cmrdporcupine wrote: post #100

Earlier quoted context omitted.

I think Scala needs to be treated something like how smart shops treat C++: there's so much there you can hang yourself with, so you need to define a subset/dialect and create a style guide and stick with it. This is how C++ has been successful at Google, and it's how I'd approach something like Scala if I were to go back to doing it now.

An evergreen conversation: "I love C++." —Alice "Oh? Which C++?" —Bob Every successful C++ team defines its own C++ subset.

This is why I can't figure out how for the life of me to learn C++ effectively for professional use.

Re: Scala projects are difficult to maintain

#132

Post by attractivechaos »

phekunde wrote: post #44

Have you tried C++, Rust, Java or any other language? They all at some point in the development cycle become a maintenance nightmare. I will let you on a secret, we software developers create problems and then solve those problems. That is how software developer jobs are retained :)

Software engineers solve simple existing problems by creating complex new problems.

Re: Scala projects are difficult to maintain

#133

Post by hota_mazi »

nine_k wrote: post #116
rednum wrote: post #83

Earlier quoted context omitted.

Yeah, good luck when someone with experimental temperament decides to implement some of your crucial functionality with semialgebras. (that's what happened in my previous job where we run Scala). I'm happy I didn't have to debug any customer issues around that module. Also, I didn't enjoy constant bickering with my reviewers what makes a beautiful code or not. Apparently there are five ways to do everything in Scala…

Were semialgebras a right abstraction, or over-engineering? What is helpful in situations like this is the motto "as simple as possible, but not simpler". During a code review, if you see something you think is too complex, ask the author: "How could it be made even simpler? If not, how exactly a simpler approach did not work?" It sometimes helps find an overlooked simplification.

> Were semialgebras a right abstraction, or over-engineering?

I think that's missing the point.

The criterion should be: is the code clear enough to be easily testable, easy to debug, and easy to evolve?

I will take a wrong abstraction with the qualities listed above any day of the week.

Re: Scala projects are difficult to maintain

#134

Post by AheadOfTime295 »

MrPowers wrote: post #46
jmartrican wrote: post #41

> Scala libraries need to be cross compiled with different Scala versions. This seems like a big turn off. Question to any Scala dev's out there. Does this get in the way? And does it make upgrading Scala versions difficult?

Upgrading Spark from Scala 2.11 to Scala 2.12 was a huge effort. See here for more discussion: https://contributors.scala-lang.org/t/spark-as-a-scala-gatew... Some projects are easier to upgrade, but for complex projects, minor Scala version bumps can be quite challenging.

And the story goes on: upgrading Spark to Scala 2.13 https://issues.apache.org/jira/browse/SPARK-25075

Re: Scala projects are difficult to maintain

#135

Post by hota_mazi »

PopsiclePete wrote: post #117
weatherlight wrote: post #89

Earlier quoted context omitted.

I have found that languages that support both FP and OO paradigms its best to do things like data manipulation in FP, and use OO to encapsulate those processes and be limited to just passing messages to other objects. Avoid inheritance. Once an object is instantiated, don't change its internal state. etc.

>Avoid inheritance. Once an object is instantiated, don't change its internal state. etc. Just embrace Clojure then. You get all that enforced for you, plus the entire Java eco-system.

You lose static typing though, and that's a deal breaker with me.

And no, core and other half-hearted attempts at gradual typing from Clojure don't even come close to hitting that mark.

Re: Scala projects are difficult to maintain

#136

Post by hota_mazi »

AzzieElbab wrote: post #127

But Java had adopted about 75% of scala’s features from 5 years ago. Mostly with some quirky limitations and bloated syntax. What exactly makes it easier for people to understand is beyond me

Because less is more.

What makes Java and Kotlin more popular languages than Scala is that both Java and Kotlin are being extremely deliberate in choosing what features they include and more importantly, which not to include.

Scala includes everything by default because it allows the EPFL to submit a lot of papers to conferences.

Re: Scala projects are difficult to maintain

#137

Post by AheadOfTime295 »

terhechte wrote: post #30
nullifidian wrote: post #4

Earlier quoted context omitted.

Does rust have this issue? Anyone with experience?

I did a lot of Scala some years ago and also ended up in sort of a ragequit. Nowadays I'm mostly doing Rust or Swift. Rust, of course, has a steep learning curve due to the lifetime & borrowing system. However, the errors are usually very easy to understand. In the rare case where they aren't, it is easy enough to figure out what's wrong by searching for the error message. One of the Scala issues I had was that the e…

The maintainer of Slick was in the last round of layoffs at Lightbend. Not sure who maintains Slick these days.

https://news.ycombinator.com/item?id=22854494

Re: Scala projects are difficult to maintain

#138

Post by dehrmann »

> Publishing open source project to Maven is way more difficult than most language ecosystems.

Maybe this is a feature, not a bug. I won't call out the language/repo, but I was able to gain admin access for a library my company published with just an email from my company's domain. There are major security issues with "easy." There are also quality issues. You're more likely to publish something if you think it has value; I've published work to Maven Central, but only the high-quality, reusable work.

Re: Scala projects are difficult to maintain

#139

Post by anthonyskipper »

AzzieElbab wrote: post #112
cmrdporcupine wrote: post #100

Earlier quoted context omitted.

I think Scala needs to be treated something like how smart shops treat C++: there's so much there you can hang yourself with, so you need to define a subset/dialect and create a style guide and stick with it. This is how C++ has been successful at Google, and it's how I'd approach something like Scala if I were to go back to doing it now.

That is exactly it. A company wide style and coding guide is a must with scala

A company wide style doesn't quite get it done. Is your style not to allow high kinded FP coding? (because it is too hard to understand). If so does that mean you don't allow libraries written in that style, like SLICK?

We had PHDs and very senior engineers, and they thought debugging common libraries like slick would take them weeks of work and they opted for avoiding that entire type of scala. But that is hard to do, because its a lot more than a coding style.

Re: Scala projects are difficult to maintain

#140

Post by JD557 »

I might be a bit biased, since I've been writing Scala professionally for years.

While most of the article rings true, I wanted to share some counter-arguments:

1) A lot of the problems mentioned are only really noticeable if you use Spark, which really lags behind in Scala versions compared to the rest of the ecosystem. As someone who doesn't use Spark, I don't really feel much of the "Scala minor versions" pain.

2) While not great, cross-compilation/publishing is not that bad (there are plugins like `sbt-release` and `sbt-crossproject` that pretty much take care of it).

3) I mostly disagree with the "Difficult to publish to Maven" point. I'm not saying that it's easy, but I enjoy the fact that it's not as trivial like other languages. I would argue that this whole process makes [1] almost impossible, which is a plus for me.

1: https://medium.com/@alex.birsan/dependency-confusion-4a5d60f...

Post reply on HN