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

181–190 of 235 posts

Re: Scala projects are difficult to maintain

#181

Post by shagie »

cmrdporcupine wrote: post #171
dehrmann wrote: post #141

Earlier quoted context omitted.

I don't disagree, but Java keeps adding features that make it closer to Scala, and Kotlin is well-supported and has cleaner syntax, so you have better choices than C++. The space between C and C++ is too fragmented, and too many of the languages are niche.

Yes, I haven't been in the Java world for almost 10 years now, so I can't comment too much on that, but it seems like Java improvements & Kotlin have vacuumed up the reasoning for using something like Scala. When I used it 12 years ago, the core Java language itself was terribly anemic.

Java stagnated for a long time at 7. Java 8 really started the change and it has been moving forward at a good pace since then.

I'm going to say maybe too fast. Not that the changes aren't good (they are good) but rather that the pace of features from 8 to 11 and then 11 to 17 has been fast and trying to get old toolchains updated to 8 (yes, it pains me) - much less use the features that are present in 11.

While in the organization that I work in there was some "ok, we've got old things on the computers, update to the latest Java now?" was postponed until September so that we can say "Java 17 is the standard" and have that be our long term platform for awhile.

But there are a lot of people who are still writing code that would compile in 7.

Looking at the version history, 12 years ago would have been Java 6... there were a lot of good changes with collections in Java 7. https://www.oracle.com/java/technologies/javase/jdk7-relnote...

The try with resources and catches were the two big things that made 7 much better than 6 for me. And with 8 - https://www.oracle.com/java/technologies/javase/8-whats-new.... - while:

* Classes in the new java.util.stream package provide a Stream API to support functional-style operations on streams of elements.

is only a single bullet point, that's a big thing.

Re: Scala projects are difficult to maintain

#182

Post by paedubucher »

chriswarbo wrote: post #61
paedubucher wrote: post #50

I am really a beginner of both Scala and functional programming. I took the first Coursera course on Scala, and I got really frightened when I noticed that you can express many things in either the functional or in the object-oriented paradigm. One example is pattern matching vs. polymorphism. When you mix up those ideas throughout your code base, it might become really hard to understand. This is just a thought that…

FYI this is known as the "expression problem" https://wiki.c2.com/?ExpressionProblem

Wow, thanks! It's always good to see if one's intuitive concerns are actually well-known computer science problems.

Re: Scala projects are difficult to maintain

#183

Post by paedubucher »

blackoil wrote: post #93

As an old pragmatic, I believe for a new startup language of choice must be Java/C#. * Stable, Well understood language. * Rich ecosystem. * Fast enough. * Plenty of developers to hire from. * Scales well to large projects. No other language/ecosystem ticks all the checkboxes.

Go ticks all those boxes, including "easy to learn".

Re: Scala projects are difficult to maintain

#184

Post by eeperson »

hintymad wrote: post #158
anthonyskipper wrote: post #20

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 may have a contrarian opinion: a new language, beyond certain level, does not increase productivity tangibly for a large enough team. Specifically, Scala does not necessarily offer more productivity than Java. It is a pleasure to write program in a language with more powerful features, for sure. It's just that bottlenecks of project are usually not language features, but core algorithms, system designs, meticulous…

Can't language features help solve some of those problems though? Improvements in static typing can help with algorithm implementations, reduce the amount of testing required, and make conflicting requirements more obvious.

Re: Scala projects are difficult to maintain

#185

Post by dustingetz »

valenterry wrote: post #180
dustingetz wrote: post #84

The problem is that functional programming is a really good idea but nobody has figured out (yet) the specific industry applications where it makes possible new things that weren't possible before. Mapreduce was a big win but you can do it in java. Spark was a big win but you can drive it from python. How do you make a better CRUD app in Scala? Serving http requests but with monads is not the answer.

You could say the same about OOP though. Just like FP, OOP doesn't make new things possible, it just makes some things much easier.

java succeeded because of managed memory, which made it possible to build systems that didn’t randomly segfault by default

Re: Scala projects are difficult to maintain

#186

Post by valenterry »

hota_mazi wrote: post #136
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.

Why do you think Scala has more features than Java/Kotlin?

I think it's the opposite. For example null: where Kotlin has a special operator and semantics, Scala simply has the "Option" type in the std lib.

Re: Scala projects are difficult to maintain

#187

Post by ebruchez »

gher-shyu3i wrote: post #177
blacktriangle wrote: post #80

Earlier quoted context omitted.

I wouldn't blame the language, I'd blame the people who chose Scala. The impression I always had was that Scala was a research project into how various programming language features could live together and interact, hence their everything and the kitchen sink approach. From an academic point of view I think Scala was a huge success. That people chose to use Scala in production speaks more to how badly people hate Jav…

The ironic thing is, Java now has records (case classes in Scala) and pattern matching (fully fledged Scala-like pattern matching is in the works). It's better designed than Scala, and will be faster due to better integration with the JVM.

> better designed than Scala

How so? Do you mean Java in general, or just the pattern matching part? Can you provide an example where Java is "better designed"?

Re: Scala projects are difficult to maintain

#188

Post by hota_mazi »

valenterry wrote: post #186
hota_mazi wrote: post #136

Earlier quoted context omitted.

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.

Why do you think Scala has more features than Java/Kotlin? I think it's the opposite. For example null: where Kotlin has a special operator and semantics, Scala simply has the "Option" type in the std lib.

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

Re: Scala projects are difficult to maintain

#189

Post by jackcviers3 »

cmrdporcupine wrote: post #100
anthonyskipper wrote: post #20

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 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 6 year old version at this point.

If you don't want java to eat the features you use, use either the typelevel ecosystem or the ZIO scala ecosystem of libraries, use their respective preferred built-in DI methods (tagless final and ZIO environments, respectively).

If you don't mind eventually having java eat your features, go ahead and use the Lightbend ecosystem and buy the support license. If you don't want to buy support, the twitter/finagle ecosystem is basically the same without a support possibility. But within those there's definitely room for creative license.

All in all, the functional and typelevel subset works best as it's a tiny footprint of features and libraries, it doesn't leave any gray area for personal expression, and treats the language as its own language rather than clone - you - a - c++ - java - javascript - ruby.

Would I rather everything move to Mill? Yes. Is that ever going to happen, nope.

Re: Scala projects are difficult to maintain

#190

Post by nine_k »

gher-shyu3i wrote: post #178
nine_k wrote: post #121

Earlier quoted context omitted.

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

Pattern matching is (will be) better implemented in Java. It's fully fledged compared to Kotlin's implementation.

When will the last-argument-as-block be implemented in Java?

This one brilliant feature allows for easy DSLs without macros, parsing, or otherwise introducing new concepts to the language.

Post reply on HN