Live data from Hacker News

Scala projects are difficult to maintain

mungingdata.com

201–210 of 235 posts

Re: Scala projects are difficult to maintain

#201

I've been looking for a video/presentation from one of the main Scala contributors before he left the team. I think I saw it about 8 years ago. It was highly critical. One of the main slides the stood out was discussing something like 20 or 30 different kinds of "types" in Scala. I cannot find it anymore, it may have disappeared with the political "drama" I've heard happened within Scala that included attempts to bla…

You're thinking of Paul Phillips https://www.youtube.com/results?search_query=paul+philips+sc...

Re: Scala projects are difficult to maintain

#202

Earlier quoted context omitted.

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?

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.

Re: Scala projects are difficult to maintain

#203

Many people talk about Java, Go and similar, contrasting it with Scala, but I think it misses one crucial point. Java and Go are in many ways "done" languages. They evolve very little. Correct me if I'm wrong, but I don't think Go changed significantly since 1.x. Java hasn't been evolving almost at all until recently, and the changes introduced now are still conservative, and it will take ages before the ecosystem ca…

> 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 learned Scala! it shaped my perspective to combine programming paradigms and pick best practices from each one rather than sticking to a single paradigm. But for work that I wanna last long enough, I can't accept it, as there is no realm of calmness in view. 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!

I think the value that Scala brings into industry is what that prevents it from becoming the rival to others.

Re: Scala projects are difficult to maintain

#204

Earlier quoted context omitted.

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"?

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

Re: Scala projects are difficult to maintain

#205
post #203

Many people talk about Java, Go and similar, contrasting it with Scala, but I think it misses one crucial point. Java and Go are in many ways "done" languages. They evolve very little. Correct me if I'm wrong, but I don't think Go changed significantly since 1.x. Java hasn't been evolving almost at all until recently, and the changes introduced now are still conservative, and it will take ages before the ecosystem ca…

> 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

Re: Scala projects are difficult to maintain

#206

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…

> "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.

This is a gross programming fallacy.

Yes, you'll learn the language at the superficial level. But learning the ecosystem, best practices, that takes years.

Unless your project is short lived or something trivial, in which care you won't care. But if it's going to live for a long time and will have a major impact, the decision to hire programmers that have 0 experience in your target language will bite you in the butt, years later.

Re: Scala projects are difficult to maintain

#207

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".

Does it? Does it have a production ready ORM (such as Hibernate or SQLAlchemy) or solid cross platform GUI libraries? (this is a big hit against C#, too, by the way) :-)

Re: Scala projects are difficult to maintain

#208
After being a big fan of Scala about 10 years ago, I think that Kotlin is better suited in almost all cases. Kotlin is much easier to learn (especially if you know a similar language like Java, C# or TypeScript), much easier to read and understand and has much better long term stability. The support in IntelliJ is also better. Scala causes performance issues from time to time in IntelliJ and there are some language constructs that the IDE doesn't really understand in all cases.

JetBrains build Kotlin as a programming language for industrial projects - and it shows.

Re: Scala projects are difficult to maintain

#209

Earlier quoted context omitted.

> 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"?

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.

Re: Scala projects are difficult to maintain

#210
post #62

I've been on C# for over a decade and I'm still very happy with it. I think it's highly underrated in the startup space. When helping start my current startup, one of the founders asked why I chose C# as he was asked by others why we'd pick that language/stack as it's not common for SF startups. I told him that it's less about the language and I could do just about anything with it. It's turned out great and of all t…

C# is definitely not sexy, but it is well documented, and there is plenty of help. I don't see why more companies go this route (not just C#, but any language that fits this). Boring is good when you have a short timeframe and it has to work well with minimal fuss.

"Boring" languages almost always equal more boilerplate.

Personally, I'll take an expressive, GC'ed language, but write "boring"-ish code when I'm on a short time-frame and I have few developers.

EDIT. Just realised this sounds needlessly antagonistic; the point I'm trying to make is that "boring" is too coarse a measurement. Java 1.8 is more "boring" with it's required explicit type declarations, but I would /always/ pick a newer Java version to avoid the boilerplate.

Post reply on HN