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

221–230 of 235 posts

Re: Scala projects are difficult to maintain

#221

Post by valenterry »

hota_mazi wrote: post #213
valenterry wrote: post #202

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…

Scala is one of the more misunderstood languages, partly due to its higher learning curve compared to most language.

The implicits you mentioned are a good example. It is one feature and consists of two parts:

1. Implicits at use-site: they define that a not explicitly provided value can be filled in implicitly by the compiler

2. Implicits at definition-site: they mark those values that the compiler is allowed to fill in at use-site when a value is not explicitly provided

That's all there is to it and one without the other would be utterly useless, so it really is _one_ feature.

But that one feature can be used for multiple things and I assume that this is what you meant. For example, they can be used for method extension syntax (which is a distinct feature in Kotlin) or derivation (e.g. serialize a structure into json, which in Java is usually done with reflection or annotations) or ad-hoc polymorphism (emulating typeclasses similar to Haskell).

Mind that these use-cases were not foreseen when Scala was created! But because implicits are such a powerful language feature, Scala can now have method extension syntax without any changes in the language (well, besides some minor optional syntactic sugar, but that's it).

Java cannot easily have this syntax and Kotlin only has it because it was added from the beginning.

Implicits are a beautiful example how a well thought and flexible language feature covers multiple features of other programming languages at once.

The underscore character is a different thing, because that isn't really a language feature, it is syntax. But I agree that it is overused in Scala and is quite confusing in the beginning.

Re: Scala projects are difficult to maintain

#222

Post by DizzyStatement »

Well, in my humble opinion, I believe most people that choose scala, thinking of it "the better java" usually gets frustrated, especially when they start off using the "cool" stuff people say on twitter.

Tbh, I've been programming in scala for 5 or 6 years now and have never worked with "proper" FP libraries like cats or zio. All the companies I've been working with, have used the lightbend stack, so basically play framework, which is easy to learn for someone coming from java/spring and the most different, Akka streams.

One day one of my java colleagues started an argument saying scala was too complex etc etc. I asked based on which code? He mentioned scalaz. So tell me what the hell someone who has never programmed in scala before was doing looking at scalaz code? No wonder why a novice would think of it.

The bottom line is that if you are new to scala and/or has no experienced developer nearby but still want to try out scala, just stick with the standard library and use play for your rest services. When you are confident enough with the language, if interested, have a look at the FP libraries.

Re: Scala projects are difficult to maintain

#223

Post by tormeh »

gher-shyu3i wrote: post #212
RoyBro wrote: post #209

Earlier quoted context omitted.

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.

One of the benefits of Scala's willingness to break bytecode compatibility all the time is that whenever Java/JVM implements a Scala concept, Scala switches to the Java method under the hood. Whenever the JVM gets Java-specific optimisations, Scala will use those. That's honestly pretty cool.

Re: Scala projects are difficult to maintain

#224

Post by ttymck »

I am an order of magnitude more productive in Scala, compared to python. The compiler does so much for me, I can focus on just writing my domain.

Frankly, I think Scala is just good at exposing weak programmers and teams with poor discipline. I've seen far worse codebases in python where there's no disciple: all methods are public, monkey patch classes at runtime, etc.

I think articles like this are so common because Scala is easy to pick on. "Implicits are bad" is more interesting than "Implicits have a very specific usefulness", but Implicits are peculiar and unique to scala so the language gets lampooned. "Private methods make code more maintainable" may be just as true, but no one says Python is universally hard to maintain -- so long as the person behind the keyboard knows what they are doing.

Re: Scala projects are difficult to maintain

#225

Post by dwhitney »

weatherlight wrote: post #89
dwhitney wrote: post #59

Earlier quoted context omitted.

I think mixing the OO and FP is the crux of the problem. Type inference and subtyping (class based inheritance) don't mix well, and often require type annotations to help the compiler when types get somewhat complex. Eventually you develop an instinct for it, and it's not a problem, but the road to developing that instinct is littered with torn out hair. (edit: spelling)

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.

I agree you should avoid inheritance, but it’s the fact that Scala supports inheritance that makes type inference difficult (also null). Type inference in Haskell is much better, for example. I saw a great presentation on the topic by Thomas Wies. Here’s a paper he wrote if you are interested https://cs.nyu.edu/wies/publ/finding_minimum_type_error_sour...

Re: Scala projects are difficult to maintain

#226

Post by millerm »

nine_k wrote: post #121
foobarian wrote: post #104

Earlier quoted context omitted.

Recent Javas made many QoL improvements to remove some of the complaints IMO. And there are more neat improvements coming (already there?) with 15 and 17.

Also, Kotlin is a rather nice and much less radical "better Java", well-supported, but mostly popular on mobile.

Kotlin is by far my favorite language-to-date. I moved my dev team to it years ago, it's all server side. We still have over a decade's worth of Java code to maintain, but anything new is in Kotlin (even in the legacy applications, we just add Kotlin). So nice. Makes me happy when other people get onboard and say "oooh yes, this is much better than our legacy Java". I was a HUGE Java proponent from 1999 to around 2010, when I started really getting annoyed that the language was missing so much that other languages had. Eventually we tried Scala, too complex to deal with in large teams to get everyone onboard, Clojure was a pain as everyone tried to be as clever as possible (and errors were awful, tooling was painful as not everyone wants to use emacs), then Kotlin came around and we never looked back.

Re: Scala projects are difficult to maintain

#227

Post by AzzieElbab »

thinkharderdev wrote: post #219
AzzieElbab wrote: post #192

Earlier quoted context omitted.

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

Implicits are just typed globals that you have explicitly ask for. Scala’s flexibility is the problem, we make scala code look like Haskell, or strange Java, or Idris. Very few people actually write scala sticking with their own pl linguistic baggage instead

Re: Scala projects are difficult to maintain

#228

Post by fulafel »

gher-shyu3i wrote: post #212
RoyBro wrote: post #209

Earlier quoted context omitted.

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.

They have in practice been slower because they try to be higher level, more ergonomic languages than Java. There aren't many performance-first JVM languages yet I think (Fortress maybe? They cited JVM problems when they wrapped up though).

Re: Scala projects are difficult to maintain

#229

Post by hderms »

jackcviers3 wrote: post #189
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's how it is successful. HN said my post was too long, but here's my rebuttal to the op and it pretty much goes along with what you said: https://gist.github.com/jackcviers/a7e74a3ad0a57f6ab97afd25c... If you are in the databricks Spark ecosystem -- stick to using the Databricks style and Spark libraries. Don't bring in anything that isn't in that ecosystem, because it runs way behind standard scala -- it's on a…

Some of the twitter ecosystem works fines with typelevel style. Finch, in particular, comes to mind

Re: Scala projects are difficult to maintain

#230

Post by hderms »

eternalban wrote: post #170
fctorial wrote: post #155

Earlier quoted context omitted.

> I used to do the switch the superclass at loadtime to experiment with adaptable programs. This probably falls in undefined behavior territory. What kind of errors did you get when something went wrong?

It is not undefined behavior. Bytecodes are modified via custom CL and superclass was swapped from e.g. Object to something else. As for errors, honestly its been 23+ years so don’t really remember. Naturally you can’t just swap any random class - it has to be correct e.g. can’t have an override method in the child that has no corresponding method in the super. And if memory serves, you can also play this trick using…

I've definitely experienced some scary bugs caused by runtime bytecode injection (from a tracing library). I didn't bother tracking it down further than identifying it was at the intersection of some slightly strange type and the tracing. Caused VM errors when this method was called but only when the tracing was configured.

Not saying it's not interesting to experiment with things like that, but there are non-trivial associated, if you ask me, to depending on it in production.

Post reply on HN