Live data from Hacker News

Scala projects are difficult to maintain

mungingdata.com

31–40 of 235 posts

Re: Scala projects are difficult to maintain

#31

Meh, the complaints fall basically in two categories: 1. Open source libraries are sometimes not maintained which is absolutely true but also just a general hazard of the open source software ecosystem. The solution in most cases is to just not use open source libraries that are somebody's hobby project (which the author very sensibly recommends). But that is true whether you are using Scala or not. 2. Spark is weird…

Some responses:

1. Yea, but languages that are backwards compatible have libs that are useful for way longer. I can still use Java JAR files that were built with Java 8, and published many years ago. The open source libs get stale so much quicker in Scala.

2. I'd actually argue that Spark is less weird that some other dependencies. If you look at the cats README (https://github.com/typelevel/cats) there is this caveat: Cats relies on improved type inference via the fix for SI-2712, which is not enabled by default. For Scala 2.11.9+ or 2.12 you should add the following to your build.sbt: scalacOptions += "-Ypartial-unification"

More cats specific stuff here: https://github.com/sbt/sbt/releases/tag/v1.5.0-RC2

I use Spark a lot so used that for the examples, but think other libs cause even weirder maintenance challenges.

Re: Scala projects are difficult to maintain

#32
post #5

I have only marginal experience with both but.. isn't this the case also with java nowadays?

Don't have a lot of Java experience, but think it's backwards compatible, even across major versions, whereas Scala isn't even backwards compatible for minor versions.

Minor versions are not binary compatible but in general it is trivial to cross-compile for different Scala versions if you are writing a library and SBT makes it pretty simple to use the right binary for your projects Scala version. As the author mentions this sort of breaks down when library authors drop support for older Scala versions. In my experience though that is primarily an issue with Spark being way behind in Scala version support.

Re: Scala projects are difficult to maintain

#34

I had a startup that went all in on scala. By the time we realized we chose the wrong language it was too late. Complexity is the primary issue with the scala language... when the whole goal is to have a scalable language which in itself is diametrically opposed to simplicity, your language is dead on arrival. After using Scala, Go seemed like a dream come true. We really loved the integration of OO and FP, really mi…

I only witnessed from the outside, but saw a similar story play out. A client had bet on Scala for a new platform and made it about 6 months in before throwing in the towel and rewriting the whole thing in in Java. It's too hard to recruit and the tooling isn't mature enough.

Re: Scala projects are difficult to maintain

#35
I feel like conventions would solve this problem. There's lots of programming languages that cater to multiple paradigms. Ruby and Javascript come to mind, conventions really do help when dealing with specific problems/frameworks.

I'm not sure I agree with OPs blog post.

This line specifically stuck out to me. "Scala should be avoided for easier problems that don’t require advance programming language features."

What are advanced programming features? Isn't this just a matter of where you are coming to Scala from?

Re: Scala projects are difficult to maintain

#36
post #18

Also Scala is not (yet) bootstrappable and the first binaries depended on proprietary software. https://bootstrappable.org/projects/jvm-languages.html https://bootstrapping.miraheze.org/wiki/Bootstrapping_Specif...

Now that's an interesting thought. Since someone was already working on a bootstrapping compiler, I suppose that's the best way, but since the JVM is so high level in general, and doesn't normally have many optimizations at the bytecode level, I almost wonder if it wouldn't be easier to start from one of the early compilers de-compiled into Java instead.

Re: Scala projects are difficult to maintain

#37

This is so even at a low-level. Look at the beautiful code examples in a Scala book and you might be seduced, but make a small change and there is nothing beautiful about it.

Yeah I’ve had totally the opposite experience. I would inherit dumpster fire Scala code based and found the language always gave me the tools I would need to apply refactorings with surgical precision, always maintaining some invariant (e.g. code compiles, test pass, etc...) for each commit.

By the end of whatever work I was doing, there was always the added benefit of the code base looking and feeling much better. Plus it’d take maybe 1/5 as much time to do a huge refactor compared to my experience in say Java.

I really don’t understand why people have such a hard time with Scala, other than its very different from imperative ways or doing things.

Re: Scala projects are difficult to maintain

#38

Meh, the complaints fall basically in two categories: 1. Open source libraries are sometimes not maintained which is absolutely true but also just a general hazard of the open source software ecosystem. The solution in most cases is to just not use open source libraries that are somebody's hobby project (which the author very sensibly recommends). But that is true whether you are using Scala or not. 2. Spark is weird…

Some responses: 1. Yea, but languages that are backwards compatible have libs that are useful for way longer. I can still use Java JAR files that were built with Java 8, and published many years ago. The open source libs get stale so much quicker in Scala. 2. I'd actually argue that Spark is less weird that some other dependencies. If you look at the cats README ( https://github.com/typelevel/cats ) there is this cav…

Fair enough, the whole SI-2712 debacle is indeed a source of issues well beyond Spark but in general it's just a matter of adding a compiler flag to sort it out. The other example is of course the whole mess of macros...

On the other side though, strict backwards compat creates it's own set of costs (that are often harder to quantify. Java backwards compatibility is great but it seems like it is also at least prat of the reason Java moves at such a glacial pace.

Re: Scala projects are difficult to maintain

#39
post #3

>Python projects that are built with Python 3.6 are usable in Python 3.7 projects for example. This has not been my experience in the Machine Learning space.

Could you provide any specific examples? I've never had any problems swapping between versions but I don't do anything in the ML space.
Post reply on HN