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

101–110 of 235 posts

Re: Scala projects are difficult to maintain

#101

Post by foobarian »

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…

There is a tendency I observed in engineers to not want to appear dumb. This is a recipe for disaster when coupled with a deep language like Scala, because nobody wants to solve problems the simple way, and Scala gives a tremendous amount of rope. That's why I think it's only a suitable choice for very experienced or disciplined teams, with a strong consensus on style or any DSLs. I can see average enterprise shops lacking these things and ending up with suboptimal results if Scala is used.

Re: Scala projects are difficult to maintain

#102

Post by camjohnson26 »

dcolkitt wrote: post #98
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? Typescript? C++1x?

Python, Ruby, JavaScript

Re: Scala projects are difficult to maintain

#103

Post by orwin »

taeric wrote: post #78
commandlinefan wrote: post #25

Earlier quoted context omitted.

I mean I feel like I should love Lisp the way I feel like I should love Scala - int he abstract I do, but practically neither is my go-to.

Fair. I didn't know if there was any practice overlap. For me, lisp is bigger in the meta programming. Really pulls the covers back on how things relate. Not just in how to put the code together, but how to look at the data. Scala was my first big intro to category theory. Helped me see relations in some higher ideas. Many, though, are hard to see a priori.

The issue i have with metaprogramming (lisp or elixir but also C++ macro) is that it is easy to forget, unlike most programming principle. It require you to twist your mind, and if you stop for two-three years, it require efforts to put your head back in that space.

Re: Scala projects are difficult to maintain

#104

Post by foobarian »

blacktriangle wrote: post #80
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 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…

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.

Re: Scala projects are difficult to maintain

#105

Post by jdmichal »

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.

This is my philosophy:

Data types are object-oriented. They are responsible for ensuring that their internal state is consistent, and nothing more. They may inherit if it makes sense, but it usually doesn't and most of the time aggregation is more appropriate.

Business rules are functional. There's just a bag of composable, pure functions that take the various data types and perform validations, transformations, etc.

External services, such as a database, are contractual. This would be an interface in Java or C# defining the required operations of the service. This allows manipulation of these external services during testing. Unit testing would mock them; integration testing would not.

Workflows or services are procedural. They combine everything else into an actual use-case. They read in a linear flow of what needs to happen when to meet the use-case.

Re: Scala projects are difficult to maintain

#106

Post by hurril »

Akronymus wrote: post #81
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…

Pretty much a noob at FP in general: Wouldn't f# solve the FP and OO integration?

I did Scala for ten years and've been at it with F# for a year and a half now. I do miss some very powerful features of Scala such as HKT and "typeclasses" occasionally but overall it works very well.

Sure, Scala is complex but I find that there are a few misunderstandings here.

Java, for instance, _requires_ that you use a number of supporting tools for it to be useful these days. You need a container, you need quite extensive testing and you need quite the advanced build tools. Sure, these have all been around long enough these days to not be what we think about when we compare Java to other things, but they're implicitly also Java. I can't speak for Go because I've not looked at it.

But Scala has strengths that means that you don't need to have _external_ tools and libraries for those things. That strength is types which means that the compilers is going to want to "pick a fight" with you to a very much higher frequency. That is a pain. The reason that we're here talking about that pain with Scala is that you don't think about that in your Java project anymore because you use heuristics and sandy heads instead.

Another thing is that I think that Scala gives you a big fat revolver to shoot yourself in the foot with. Java has a bb-gun so no matter where you aim it, you're not going to accomplish a lot.

Over to F#: I'm going to claim that the .NET toolchain is superior to the JVM ones. The CLI tools and paket runs circles around the POS that is SBT.

Re: Scala projects are difficult to maintain

#107

Post by mumblemumble »

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.

If the list is meant to be universal, I would strike the last two from it, and clarify that "fast enough" means, "Fast enough for the problem you're trying to solve."

Working from the bottom: Scaling well to large projects is only a concern if you expect your individual projects to become large. I've worked on monoliths, and I've worked on systems that follow more of a Unix philosophy. In the former case, we had one project with a 7 digit line count. In the latter case, it was rare for a single application's codebase to grow to more than a few thousand lines of code.

"Plenty of developers to hire from" is often optimizing for the wrong problem. In many lines of business, domain expertise is a much more valuable skill, because it can only be developed through years of first-hand experience. A new programming language, on the other hand, can typically be taught to a reasonably skilled programmer in no more than a couple weeks.

Also, when you're just starting out, the single best programming language you can pick is the one that the people actually starting the business already know the best. They will not have senior mentors to help them learn the best way to use a new language.

Finally, "fast enough" is not a single target or a strict hierarchy. I used to work at a shop where we used Python, C#, and C++. Only C++ was fast enough, performance-wise, for some problems. Only Python was fast enough, productivity-wise, for other problems. C# covered the (large) middle ground.

It's also not a strict hierarchy. At my current job, I'm in the middle of a project to replace some Java components with Python. Java has not proven to be fast enough, performance-wise, for this particular problem, while Python gets us there with room to spare.

Re: Scala projects are difficult to maintain

#108

Post by a4isms »

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.

An evergreen conversation:

"I love C++." —Alice

"Oh? Which C++?" —Bob

Every successful C++ team defines its own C++ subset.

Re: Scala projects are difficult to maintain

#109

Post by nowherebeen »

mumblemumble wrote: post #95
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…

Yes. That's pretty much how the Scala project I was working on ran itself aground. Everyone got so caught up in flexing at each other that solving actual business problems became a secondary priority.

This points to a culture problem more than the language itself though.

Re: Scala projects are difficult to maintain

#110

Post by nine_k »

blacktriangle wrote: post #80
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 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…

Indeed, Scala looks like a language research project, more like Perl and Haskell. You definitely can use all of them in production and benefit from that, but you need both mastery and restraint in using such a language.

Golang is the opposite: it takes the ideas from 1980s with some early 1990s (Pascal, Modula-2, Oberon; CSP; garbage collection) and executes them to near perfection. It even ignores some of the obvious faults in ergonomics (if (err != null) return err; everywhere) to keep things dead simple and reasonably performant. It's much harder to write incomprehensible code in Golang, even if you try, so lack of mastery and restraint would have much less catastrophic consequences than in a highly expressive language like Scala (or e.g. C++).

Post reply on HN