Live data from Hacker News

Scala projects are difficult to maintain

mungingdata.com

211–220 of 235 posts

Re: Scala projects are difficult to maintain

#211

Earlier quoted context omitted.

Scala's operator overloading and implicits are known sharp edges (and don't get me started on XML literals) but the article doesn't mention those as hindrances for maintainability. Package dependencies are not necessarily a language issue and become more about conventions of its community. Comparatively, people aren't complaining about dependency problems in the Clojure, Java, and even Kotlin communities because ever…

Lack of correct leadership. Java, Kotlin, C# and TypeScript are led by companies that want usage. Scala was and still is primarily an academic exercise. Same problems as with Haskell - the leadership are paid to add random optimised-for-sounding-clever ideas to the language, not design a language in the gestalt that optimises for user success. In particular TypeScript is not a research language and therefore the docu…

Scala's origins at EPFL under Odersky does give it a disadvantage given the history of academic origin languages in industry. OCaml was made at INRIA and it seems to have suffered the fate of becoming a niche language and toolchain for industry programmers. The Limbo programming language from Plan 9 didn't get very far until it was re-adapted and re-imagined as Go which has obviously gotten a lot of adoption from industry.

I'm not an either/or kind of person and don't see why a language suitable for academic purposes can't be broadly useful in industry, but I would also agree that leadership that has little background in certain use cases may not design and orient the language accordingly.

Re: Scala projects are difficult to maintain

#212
post #209

Earlier quoted context omitted.

Destructuring in Scala is allocation heavy, I expect it to be much lighter weight in Java.

Scala compiles to java bytecode. Scala can only be faster then Java, in that Scala can leverage all functionality of the JVM and on top provide extra smarts that Java cannot due to backwards compatibilty it has to offer.

This has never been true for non-native languages (Scala, Clojure, Kotlin, etc.) as far as I'm aware. They've always been slower. The JVM is designed with Java in mind and co-evolves with it.

Re: Scala projects are difficult to maintain

#213

Earlier quoted context omitted.

Do you seriously think Scala has fewer features than Java and Kotlin?

I would say so. The language specification of Scala is much shorter than Javas. Having less features does not mean the language is easier to learn though. Scala has less features, but the ones it has do work well in combination with the others and are very general.

The specification of Brainfuck fits in two paragraphs, according to your definition, that should make it a very easy language to program in.

The fact that Scala's features work well together is a myth that's been debunked over and over. Just look at the number of semantic meanings for "implicit" or the underscore character.

Scala is just what happens when a language just adds every single feature under the sun with very little care for user productivity.

Re: Scala projects are difficult to maintain

#214

Is the Scala language simply too big? I tried to learn it once (years ago) and quickly found myself overwhelmed by the number of concepts. I remember feeling like 80% of power of the language could have been achieved with 20% of the complexity. The latest Java releases are somewhat proving this with functional interfaces and records.

There are certainly folks that argue the language it too big. Here's a great talk arguing that a lot of language features should be eliminated and Scala should be made a functional programming language: https://www.youtube.com/watch?v=v8IQ-X2HkGE&t=1s&ab_channel=... I'm personally in the camp of "keep Scala huge and weird and multi-paradigm, but just make less breaking changes and focus all efforts on making the ecos…

Worth noting that the presenter of this talk has done a complete 180 on subtyping as he's now using subtyping and variance in the core of his flagship library ZIO. He realized it was sometimes better to use the language's strengths rather than denigrate them for "ideological" reasons.

Also worth noting that Scala is not a "very big" language in any sense that I know of. It has a lot fewer features than C#, for instance. And probably a comparable amount to TypeScript.

Re: Scala projects are difficult to maintain

#215
post #203

Earlier quoted context omitted.

> Finally, a side note about OSS. I don't think it's fair to expect anybody to maintain any kind of library in any language for free True! but why Spark & Flink, which are backed with business, didn't bother themselves to catch up with changes in Scala! they delayed their upgrade to 2.12, not mention 2.13! and as far as I know the 3.0 hasn't been discussed yet! Am I right? In general I'm happy and thankful that I lea…

> Software Industry is a young industry and complex, like any other profession, and a developer need to think about lots of other things as well, not just the language and possible pattern/syntaxes it has to keep up with! Looks like you’ve chosen the wrong profession

Dear friend, I don't know about your experience on the industry, specially with Scala. My experience on working with the language for more than 4 years and being responsible for more than 15 components written in Scala, wasn't delightful. I'm still maintaining some components in Scala, and I have a clear picture of it means. Hope you'll have more successful experience with it.

Re: Scala projects are difficult to maintain

#216

I think about scala a bit because the second biggest chess website (lichess) is open source and written in play framework/scala. Was interested in learning some scala to help contribute since I play on the site so often Wonder if they've run into these issues with the language though

They almost certainly run into these issues, but like most of the community, they probably think the cost is well worth bearing, given the advantages the language gives you.

Once you're used to the way it works, and if you're using well-maintained libraries, I find that it's really not such a big deal. Though it's always awkward to have transitive dependency conflicts, and those are best avoided if possible.

Re: Scala projects are difficult to maintain

#217

It is ironic that a language named itself as Scala, doesn't really scale with the team sizes.

It was originally called Scala because the language itself could "scale"; the grammar was so flexible that you could use it to seemingly write new language constructs. For example `while` or `repeat` loops are expressible with functions, and it looks natural because dots can be replaced with spaces in many cases. Functions can have many special characters as names, and functions can be called in-fix, and so on.

People took these possibilities and ran with them, creating all sorts of wonderfully illegible DSLs. It was widely recognised as a bad idea.

Re: Scala projects are difficult to maintain

#219

Earlier quoted context omitted.

Do you seriously think Scala has fewer features than Java and Kotlin?

But there is no such thing as Java. It is Java plus spring plus guava plus something else for immutables

I think the point is that comparing Scala the language to Java the language is apples-to-oranges. In general you are using Java along with a bunch of libraries (or Scala plus a bunch of libraries) so the question is whether Java plus all the libraries you are using is less complex than Scala plus all the libraries you are using. And the answer is not nearly as obvious as many people tend to assume.

For example, the most common thing people point to when talking about Scala's complexity is implicits. And that's fair because implicits can be hard to understand and can be used in wildly inappropriate ways. But I have found that what implicits are mostly doing (at least when used correctly) is taking stuff that would be implemented in Java with some crazy runtime reflection scheme and making it a compile-time construct. So then the question is not "are implicits complex?" but "are they MORE complex than the equivalent implementation using reflection?" And on that question I would say absolutely not! Runtime reflection is (to me at least) much more opaque, error prone and difficult to debug.

Re: Scala projects are difficult to maintain

#220

Earlier quoted context omitted.

I would say so. The language specification of Scala is much shorter than Javas. Having less features does not mean the language is easier to learn though. Scala has less features, but the ones it has do work well in combination with the others and are very general.

The specification of Brainfuck fits in two paragraphs, according to your definition, that should make it a very easy language to program in. The fact that Scala's features work well together is a myth that's been debunked over and over. Just look at the number of semantic meanings for "implicit" or the underscore character. Scala is just what happens when a language just adds every single feature under the sun with v…

Wait, so is it that Scala has too many feature or too few?
Post reply on HN