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…
Scala projects are difficult to maintain
201–210 of 235 posts
Re: Scala projects are difficult to maintain
#202Earlier 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?
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
#203Many 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…
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
#204Earlier 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"?
Re: Scala projects are difficult to maintain
#205Many 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…
Looks like you’ve chosen the wrong profession
Re: Scala projects are difficult to maintain
#206As 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…
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
#207As 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
#208JetBrains build Kotlin as a programming language for industrial projects - and it shows.
Re: Scala projects are difficult to maintain
#209Earlier 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.
Re: Scala projects are difficult to maintain
#210I'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.
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.