Why Scala is not popular? And very hard to find a complete tutorial? Everything online, including Udemy and YouTube is basic and doesn’t cover real-world applications. Unlike other programming languages (Java, Python, C#…)
1 Like
Welcome to Scala community,
Check out these online courses: Online Courses (MOOCs) from The Scala Center | Scala Documentation
1 Like
Java snobbery, perhaps?
I had one interview, long time ago, where I mentioned Scala experience. “I’m sorry” was the flippant response. And this was for a Python role.
I only program for myself these days. 12+ years of using emacs and writing my own extensions has made into a lisp guy. As such, my preferred language is Clojure.
Still, if forced to choose between Java and Scala, Scala wins easily.
I once got an email about a job “opportunity” that involved Scala. Problem is that it was taking entirely the wrong approach. The company/client had a Scala code base and wanted to translate it into pure Java. SMH.
3 Likes
That is hard to answer, there are probably a lot of factors.
One thing is that Scala is a very different language than most common ones, and a lot of folks don’t like to learn (and even worse forget) things.
There is also the constant impression that FP is just an academic fuss without use for writing “real software”.
And a bunch of extra stuff.
Still, finding jobs using Scala is possible.
Some resources that are more practical:
4 Likes
I have been using Scala since 2005, and while it is still my favourite programming language, there are many reasons not to like it.
- Poor backward compatibility, resulting in a complex artifact versioning system and other issues.
- Features like ‘implicit’ were poorly handled, abused, and oversold. Scala 3 has addressed this somewhat, but some of us remain unconvinced.
- Compared to Java, documentation has been poor, resulting in a frustrating developer experience by people spoiled by high-quality Java documentation.
- Trolling. I have been trolled too many times by Scala experts who cannot hear any criticism. I am not alone in this experience. While this has improved, it took too long.
- Using Scala effectively requires a lot more cognitive load than Java or Kotlin. In particular, working with a team of Scala developers with no team discipline makes code maintenance much more difficult.
a. I was on a team where one guy wrote all his Scala code using Haskell calling conventions for no reason other than it was fun for him.
b. If we had a competent team lead, he would have forced this guy to stop doing it… - Many companies and organizations have replaced Scala with Kotlin because “it has 80% of the power with 20% of the features.”
So, most of my Scala projects are personal projects where I can enjoy the beauty of Scala and not put up with other people’s abuse of Scala.
I have to say, Scala inspired Kotlin, and is certainly forcing Java to become a better programming language.
5 Likes
I like some of Kotlin, but it has flaws as well. Too many of the underlying Java components can be mutated behind our backs. Even if the Kotlin interface enforces immutability in Kotlin code.
1 Like
About the development job market.
It is extremely rare to find a demand for Scala developers, including Data Engineering (Spark). Most of the jobs ask for Python and Java. Unless Scala’s Community does something about it, I have a feeling Scala is going to die and disappear within 5 years.
I really like Scala. I had a job for about a year and half as a Scala developer. Scala would be my language of choice if I had not discovered Clojure. The two are very compatible in many aspects.
• Default immutability
• Methods/functions can be used to create new threads
• Both lead well into functional programming
1 Like
I agree with this post and even more! I started Scala with this course https://www.coursera.org/learn/scala-functional-programming. While my previous programming helped me appreciate it, I don’t think its a good introduction to a programming language.
People want to learn programming to solve problems first. Deep theoretical concepts like numbers as functions come later. Language designers should care for this defintely so that programmers can use this as simple possible ways. People do not learn all of a language and then start to code, it happens when your problem space grows.
Scala with its powerful syntax has a great potential to replace Python as simpler to use language for starters. But the conversation should start there. I liked this blog by Li Haoyi a great inspiration: com.lihaoyi Scala: Executable Pseudocode that's Easy, Boring, and Fast
3 Likes
Well, I always get inquiries for a Scala developer, so perhaps you are not looking in the right places or on the right lists. If you really do like Scala, I hope you find one of these positions.
1 Like
In 1970, at age 12, I learned programming in a high-school math class. Our teacher challenged us to solve our math homework with computer programs, and I was the only one to accept the challenge. It was a very good way to learn math.
Looking back, I was using BASIC, FORTRAN, Assembler, etc. 
Based on my Scala experience, I can imagine using a programming language like Scala to teach math, physics, and other subjects. Perhaps a DSL implemented in Scala?
The goal would not be to teach students to program but to teach logic, math, physics, and only enough programming to learn those subjects. NO IMPLICIT BULLSHIT PLEASE.
Given technology like GitHub Pilot, this could be a very effective learning environment.
Also, I took Coursera courses in Scala Programming and Reactive Programming, so now I know the power of good online courses.
1 Like
Unfortunately there is a chicken-egg problem there, many people who want to learn programming (in any language) don’t know how to solve problems. Because problem solving is not taught anywhere. Not in school, math class, or in programming books / courses. You are supposed to somehow “just know it”. When beginners get stuck they don’t know where to go to learn problem modeling, breakdown, solving and abstract thinking. The usual “advice” is to “keep doing it for a few years” and learn by osmosis.
I comment over there on Coursera forums a lot, and I see the issues you are mentioning. Of course part of the blame lies with the courses, but I think it’s a bit more complicated and not really limited to any language. I was heavily involved in an online curriculum which used many languages (involving lots of Python), but these problems were universal.
I don’t think this “replacement mentality” that is common in the programming world is helpful either. Programmers love to do these language (or IDE / editor) wars. Why would a starter care about any of that? I don’t think Scala should “replace” Python, it’s great to have both, and I hope both continue to do well.
It’s quite a sad state of affairs that numbers and functions are considered “deeply theoretical” today. They are the exact opposite. Back in the day we learned them in elementary school. It was standard like reading and writing. Today, on Coursera people don’t know what a set is, and course creators (who are much older) simply assume that they do (because they were educated decades ago). Attitudes from both the top and the bottom need to change. To learn the basics of problem solving, some “deeply theoretical” stuff is unavoidable, because they are foundational.
Math education became so much worse worldwide, even in industrialized countries, over the last few decades. There is also a strong anti-math attitude (I’m not saying you) coming from part of the programming community, and math people are not fond of programming culture either. So we are kind of screwed from both sides.
The external sources of our problems won’t get fixed by waiting, complaining, or taking one side. We simply need to take charge, jump over the math-programming cultural gap, and fill the gaps in our knowledge (which are not our fault), as much as possible. My default recommendation is Susanna Epp’s Discrete Math book which I think is the best for that, and I’ve written solutions for the whole book. The book covers everything: problem solving, abstract thinking, math, programming, chips, circuits, algorithms etc. So it really treats things in a unified manner, as they historically used to be (there was no distinction between math and programming).
Happy New Year! 
I hope we can see theory / practice, math / programming in a more unified way this year. 
I hope this does not come across as condescending or arrogant.
4 Likes
Yeah, this is an interesting point. I’ve been saying pretty much forever (15 years?) that you don’t need to (and usually shouldn’t) teach someone all of Scala upfront in order for them to become an effective application programmer – but that’s only true if the business logic doesn’t abuse the library-level language features. Without a measure of team discipline, it’s not hard to wind up with a codebase that is fairly impenetrable to a junior engineer.
I wonder if there’s anything we could do about that? Conceptually, it’s a style issue, so it leaves me wondering whether we could use tooling that enforces feature usage control for a given project – essentially, a linter that says, “you shouldn’t be defining something that complex here”. Not sure it would help in practice (teams that would make use of it often enforce these conventions informally in PR review), but worth pondering.
I’m afraid I have to agree – we oversell that course to beginners. I tried to use it to teach an intro-to-Scala class at work a couple of years ago, and we gave up after a few weeks: it was just all wrong for the purpose. It’s a good college-level class on FP, but that’s not what people are usually looking for to get started on the language – there are many better alternatives at this point.
It’s a lot like The Red Book in that respect: quite useful if and only if you’re prepared to put serious time and thought into it, but a terrible way to get your foot in the door, at least for most folks who are trying to learn Scala for their day job.
(In practice, we switched over to Essential Scala to start with, which proved far more effective for getting the junior engineers up and running reasonably quickly, and then continued with Scala With Cats and Essential Effects – that proved to be a pretty great syllabus to get them fully up to speed.)
2 Likes
I agree with most of your post, but I get the impression that you don’t understand the purpose and value of implicits (“NO IMPLICIT BULLSH*T PLEASE”).
I understand that implicits were overused and abused a bit in Scala 2, but they do serve a useful purpose. You would not expect to have to explicitly convert an integer to a floating-point number, for example.
I use implicit classes all the time to keep my code better organized. For example, I have case classes that represent aircraft trajectories (with tolerances that can vary along the route) for a research prototype of an air traffic control concept that I am developing. Part of the code is the actual operational code that is intended to ultimately be used in the field (after a major code review and possible rewrite, of course, but that is beside the point here). Another very large part of the code is dedicated to visualization, plotting, and analysis. That part of the code would not be a part of an actual operational system – so I don’t want to clutter the operational part of the code with it. If I did, it would just make the operational code that much harder to understand. So I use implicit classes to implicitly and seemlessly extend the operational code with the visualization and analysis code.
Without implicits, this separation of function would not be as easy or convenient to achieve.
2 Likes
I get the impression that you don’t understand the purpose and value of implicits (“NO IMPLICIT BULLSH*T PLEASE”).
I was saying in the context of teaching children logic, math, science, etc., implicits are not necessary, and are toxic in that context.
I do understand the purpose and value of implicits, which is why they are toxic in the context provided.
Teaching advanced high-school students programming, there might be some use to teaching implicits, but probably not.
As an aside, in Scala 3, implicit is effectively a deprecated feature because even the Scala Architects realized the original feature was defective.
1 Like
Yes and no – it’s important to frame this accurately, and it sounds like y’all are talking past each other.
implicit as an explicit language feature is now somewhat deprecated, because the word was focused too much on the implementation rather than the reasons for using it.
As a tool, it’s now arguably even more important than it was in Scala 2 (we’ve gained one long-desired new implicit feature); what changed was mainly the surface syntax, to focus on the use cases (eg, type classes, context passing) rather than the machinery.
In terms of the old Odersky levels, I think of it as having shifted levels. At the library-author (L) levels, you still want to be pretty well-versed in what’s going on under the hood with implicits. But the application coder (A) levels can now mostly focus on those use cases and not so much about “implicits” per se.
2 Likes
it sounds like y’all are talking past each other.
At the risk of talking past people again, I won’t argue with
As a tool, it’s now arguably even more important than it was in Scala 2 (we’ve gained one long-desired new implicit feature); what changed was mainly the surface syntax, to focus on the use cases (eg, type classes, context passing) rather than the machinery.
because I personally resent all the pain that implicit caused me in the past, but more importantly, I am not a Scala Architect and don’t have strong technical opinions to make a counterargument. I have not done enough Scala 3 to form any opinion on given, using, and summon; although I believe people when they tell me this is better than implicit.
In terms of
In terms of the old Odersky levels, I think of it as having shifted levels. At the library-author (L) levels, you still want to be pretty well-versed in what’s going on under the hood with implicits. But the application coder (A) levels can now mostly focus on those use cases and not so much about “implicits” per see.
Yes, I agree profoundly, which is why when I was suggesting using Scala as a learning language for young students of logic, math, science, physics, etc., it is simply inappropriate to use implicit in this context, or even given, using, and summon.
As an aside, in JCP 446, Scoped Values are explained in such a way that is reminiscent of implicit, given, using, and summon. I do understand the value of such things, but I don’t always agree with the application of those things. There is more than one way to skin a cat…
1 Like
I should have been more positive rather than focusing on the one minor point of concern about your post.
Yes, I would love to see Scala become a widely used “executable pseudocode” for math, science, and engineering. With the right libraries, it could become a viable replacement for Python and Matlab – with superior performance and scalability.
1 Like
This reminds me of Scott Wlaschin’s talk:
Thirteen ways of looking at a Turtle
I believe Scala is far more interesting as a language than 99% of the tasks one is typically asked to do in a 9-5 job. You can spend days on end pondering higher-kinded types and the expression problem, while all the business requires is a simple report. Those bored by the intellectual void of most commercial programming started to play around in Scala. Scala is like a powerful flashlight, encouraging discovery, intellectual curiosity, and freedom. People on the JVM found answers to problems they hadn’t even heard about .Naturally, businesses didn’t appreciate that too much. They mostly need boring languages that suit their boring needs, to be solved with boring programming. Their priority is a moderately new-ish language and a focused workforce. I think that’s why functional programming has always been a European thing. The big US corporations never embraced FP (MS and F#), and India will likely follow in lockstep with the US market. India supplies the backbone for the globalized, cheap programming workforce. If a language hurts profits, which Scala likely did (you can become Azure certified for a moderate fee and watch free tutorials on YouTube sponsored by the same corporations that issue those certifications), it won’t stand a chance in this economy.
And then there is also the data science camp, which didn’t care for using code repositories, let alone monad transformers.
2 Likes
Here’s my take on what I think are the 4 major impediments to making Scala popular:
- No decent IDE (no offense to the developers of Metals or IDEA who try their best). Personally I still dream of a Scala-only IDE, and call me old-fashioned but I do care about the “Integrated” part.
- SBT is a nightmare yet still the de facto build tool
- Little effort is made to integrate with Python (despite the excellent but dying ScalaPy). Whether we like it or not Python is here to stay and has so many useful libraries. And if you can’t beat it, make it easy to wrap around it (like we do we scala.js)
- FP purism puts off people. This is why I personally like https://www.lihaoyi.com/'s ecosystem.
Formerly 5: It was difficult to do basic things in the past, but at least the Scala Toolkit is trying to remedy that now.
2 Likes