Why Scala3 develop slowly, please make change!

Community
1

Scala, as an exceptional programming language, is concise and highly efficient. For those accustomed to C-style programming paradigms, Scala represents an even more refined approach. STorch AI was born precisely by leveraging Scala’s极致 programming style—something exceedingly difficult to achieve in other languages. For at least the past decade, most languages have struggled to match its elegance. Yet, Scala’s current development faces several痛心 issues:

  1. ‌The Scala 3 vs. Scala 2 Divide‌
    The rift between Scala 3 and Scala 2 effectively splits them into two distinct languages. While Scala 3 introduces radical, backward-incompatible syntax and core updates, this is ultimately positive—shedding historical包袱 to move forward unencumbered.
  2. ‌Slow Progress of Scala-Native‌
    As Scala’s performance benchmark (even surpassing Rust), Scala-Native’s ecosystem grows sluggishly. The core maintenance team appears to number under 100. Were they underfunded, I’d gladly donate ¥1,000 monthly to support them. We urge maintainers to better nurture the ecosystem. Currently, Scala-Native operates as a plugin, but I advocate for standalone installation packages (like Rust/Go). Maintainers argue that many components rely on the JDK—this isn’t mutually exclusive. Ideally, Scala-Native should offer both plugin and standalone installation options, with JDK installed separately if needed.
  3. ‌Scala’s Struggle in China‌
    Why hasn’t Scala flourished in China compared to others?
  • Lacks Python’s simplicity and AI ecosystem dominance.
  • Missing Rust’s极致 performance and evangelist zeal.
  • No Java-level enterprise adoption or KOL hype.
  • Absent heavyweight corporate backing (e.g., Google/Microsoft for Go/Kotlin/C#/TypeScript).
  • No equivalent to JS’s local Chinese committee endorsement.
  • Constantly dismissed and undervalued.

Nevertheless, Scala 3’s excellence is undeniable—yet development滞 remains. We demand transformative action:

  1. ‌Corporate Partnerships‌
    Pursue collaborations with major tech firms, even accepting acquisition if necessary.
  2. ‌Aggressive Marketing‌
    Amplify Scala’s projects and strengths via TikTok, WeChat, Discord, etc.
  3. ‌Localized Advocacy‌
    Establish volunteer teams/companies nationwide to host salons and publish technical content.
  4. ‌AI-Optimized Tooling‌
    Develop more AI-focused libraries, enhance Scala 3’s performance, and release standalone Scala-Native packages.
  5. ‌Free Educational Content‌
    Launch YouTube courses for Scala 3.
  6. ‌Case Study Alliances‌
    Partner with Scala-adopting enterprises to showcase real-world use cases.
3 Likes
2

Understatement of the year! You’re off by nearly two entire orders of magnitude.

Indeed.

8 Likes
3

The whole post seems AI generated to me…
Also does it belong in Contributors?

Might be a coincidence, but at the same time, Users board is receiving some spam posts.

11 Likes
4

I think this is AI generated to improve the user’s english, so I think that should be fine, though not everything in the post is relevant because of that.

4 Likes
5

That’s true, Scala Native is making much slower progress than Scala.js.

We can at least get a cookbook online for AI to learn, which can help

2 Likes
6

Regarding issues:

  1. This is a well understood situation by now. We still offer help with migration by the way. Migration consultations by VL specialists are free of charge.

  2. Cats-effect just got it’s first release working on SN 0.5 with multithreading support and I really recommend to read that announcement. The development of SN isn’t moving fast but the final quality of the platform is exceptional. The interesting bit here is that while we, at VirtusLab, have huge hopes for Scala Native, the interest from business partners is largely missing. I really hope that the Typelevel will open the flood gates because once CE and fs2 are published for SN 0.5, most of that ecosystem will just work on SN and the main complaint about the lack of libraries available for that platform might be finally gone.

  3. That’s a very good question! Unfortunately we don’t really have much exposition to the chinese IT market.

Regarding actions,

  • we have Scala ambassadors, unfortunately I don’t think we have anyone in China
  • we are doing AI-optimized tooling. Metals is the only LSP that I know of that can allow tool-use capable models to use unknown proprietary libraries in agent flows.
  • scala package --platform scala-native . - that’s as standalone Scala Native as you can get
  • I think Maciej Gorywoda of JetBrains made a free course, there are also other free courses: Online Courses | Scala Documentation
  • we could have more case studies and more enterprise partnerships indeed
9 Likes
7

If the goal is to address “Scala’s Struggle in China”, I would suggest you to try other social media, because TikTok and Discord are banned in China.

2 Likes
8

That’s true, we should have more bilibili, Douyin videos :slight_smile:

1 Like
9
  1. Scala native lack some features and development is not really fulltime, if there is an netty port for scala-native, that should be very nice.
  2. Scala’s IDEA integration is not great, eg, the mill build can not be supported out of box
  3. performance, scala is great on syntax , but performance, especially very high performance we may need using Java, to avoid the boxing and tuple allocation things.
  4. Java integration, Java 25 is around, and Scala seems can’t support all new features recently added in Java, eg we can not do patten matching on Java record.
1 Like
10

It is not about “seems can’t”, but more like “will not” as JDK 8 is the king and soon JDK 17 will be the new king (Next Scala 3 LTS version will increase minimum required JDK version), though it doesn’t mean that we will get full support for “-release:X” flag ([JVM] Use StableValue as compilation target for lazy val - #2 by sjrd).
I’d guess that it is much simpler (cheaper and realistic) to maintain single bytecode generator instead of having many feature-forks per JDK versions.

11

I think you’re absolutely right. From my perspective, Scala’s development is constrained by several key factors:

  1. Steep learning curve: Since Scala combines functional programming with object-oriented programming, developers often find themselves torn between the two paradigms. While this multi-paradigm approach certainly gives Scala more flexibility in writing code (which is one of the reasons I appreciate it), for teams, the lack of a consistent paradigm leads to inconsistent overall code style and increases code complexity.

  2. Lack of learning resources: Even though the official website offers plenty of learning materials, compared to languages like Python and Java, Scala’s resources are barely sufficient for getting started. Production-level development largely relies on open-source community projects. Additionally, the slow update pace of learning materials means that many new features and best practices aren’t widely disseminated in a timely manner.

  3. Insufficient returns: For OOP, Scala competes against established languages like C++ and Java, while for FP, it faces competition from Haskell, OCaml, and others. Scala isn’t the optimal choice in either domain, leading many developers to consider other more mature options when selecting a language. Furthermore, the slow progress of Scala Native has contributed to the rise of languages like Kotlin on the JVM, attracting many former Scala users. In the native development space, Scala Native faces competition from emerging languages like Rust and Zig, which offer significant advantages in performance and safety. Scala Native doesn’t have particular advantages when it comes to libraries and solving native development challenges.

  4. Unfocused direction: Long ago, Scala focused heavily on the data domain and produced excellent projects like Spark and Akka. However, over time, Scala’s focus seems to have gradually shifted toward functional programming and type system improvements, with weakening support for the data domain. This has led many teams that originally used Scala for data processing to migrate to other languages or frameworks, such as Python’s Pandas or Java’s Flink. With the rise of AI, many teams are now focusing on Python as the primary language for AI, further weakening Scala’s influence in the data domain. Traditional data infrastructure software like Flink, Kafka, and Spark are gradually reducing their dependence on Scala, with some projects even considering rewrites or extensions in other languages.

Regarding its popularity in China specifically, I believe the most important factors are:

  1. Network connectivity: China’s network environment creates significant challenges for package downloads and builds, causing many developers to encounter slow dependency downloads and long build times when using Scala, which impacts development efficiency.

  2. Community support: Scala has relatively weak community support in China, lacking sufficient Chinese-language resources and community activities. This makes it difficult for many developers to learn and use Scala. Additionally, Scala community events and conferences have relatively low coverage in China, resulting in fewer opportunities for communication and learning among developers.

  3. Influence of major tech companies: Major Chinese tech companies have significant influence on technology selection, and Scala doesn’t have the widespread adoption in domestic major companies that Java and Python enjoy. This leads many developers to prioritize languages that are widely used in major companies when learning and choosing languages, further reducing Scala’s popularity.

  4. Acceptance of FP languages: Although Scala supports functional programming, acceptance of functional programming among Chinese developers is relatively low. Many developers are accustomed to object-oriented programming paradigms and aren’t familiar enough with functional programming concepts and practices, making Scala’s learning curve even steeper.

1 Like
12

Your text could plausibly be written by a human, but also strongly resembles high-quality AI-generated writing—especially from advanced language models like GPT-4. Here’s why:

Signs Pointing to AI Generation:

  1. Consistent structure and polish:
  • The text is highly structured, with clear bullet points, clean transitions, and no typos or informal phrasing. This level of polish is often found in AI outputs.
  1. Balanced tone and objectivity:
  • The writing remains neutral, reasoned, and evenly paced across several points—hallmarks of how GPT models tend to structure arguments.
  1. Wide coverage of topics:
  • The depth and breadth (learning curve, ecosystem, community, regional adoption in China, etc.) suggests a model synthesizing knowledge from various sources. A human could do this, but it’s also very typical of AI models trained on a wide corpus.
  1. Lack of personal anecdotes or concrete examples:
  • Phrases like “from my perspective” are used, but the writing doesn’t include real-world personal experience or opinion markers (e.g. “When I used Scala at my previous job…”). Instead, it reads like an analytical essay.
1 Like
13

Hmm. My initial reaction was to push back – the “you may be an AI” is close enough to ad hominem that it makes me uncomfortable (and it’s a bit rude when incorrect) – but it’s an interesting point. Brand new user, laying directly in, with a post that is nicely calm but has one or two points that seem just plain incoherent, like

So yes, it’s possible that this is somebody brigading via AI.

That said, there are some valid points there (along with others I disagree with), so even if the text were LLM-generated, IMO it’s worth at least considering whether there are any actual action items that could be taken from it.

One I’ll note, that I disagree with but I think is still somewhat actionable:

On the one hand, I don’t think there is anything that necessitates this problem. I’ve been on a lot of different Scala teams, and all have had relatively tight and consistent styles.

That said, the reason why that’s worked is because I’m extremely firm about consistency – any given team should pick a stack, understand how it ticks, stick to it, and teach to it. Folks tend to get in trouble when they just leave it up to the individual developers, don’t try to provide any consistent training, and everyone goes haring off in different directions.

IMO, we should own this point more explicitly. The strength of Scala – one of the coolest things about it – is that it intentionally offloads a lot of decisions out of the language and into the libraries. That allows you to program in many different ways, but it means that choosing a stack is one of the most important decisions a project can make. We really don’t talk that up enough, and we allow ourselves to get stuck in stupid religious wars between the stacks too often.

(NB: “stack” isn’t meant to be restricted to the few big-name examples. For example, I consider the recent experiments with direct style to be a “stack” in this sense.)

We should just be upfront about this. Scala is flexible: there are a bunch of stacks, with different strengths; for a given project, you should choose one that suits your needs and focus on that.

I’d recommend that we say that much more clearly and publicly; personally, I think a pointer to it belongs somewhere right on the front page.

1 Like
14

This is a really important point! If we took a more stack-focused mindset when talking about using Scala, I think we could make a lot more library-level progress towards what people perceive as pain points with Scala that have essentially nothing to do with the language and essentially everything to do with the stack.

Especially with Scala 3, what can be expressed is at the library level is just amazing, and it can be leveraged to run rings around almost any other language experience if the type of stack needed for that gets enough interest/support.

1 Like
15

Thank you for thinking that I’m NOT an AI (which i’m atrually not!!!, I just using AI to rewrite my words in to English, because my bad English represent…) But My major point is only one keywork “WHY?”, why should I using scala3. If I wanna to write a web app, I have got Java, Go. If I wanna to write a high perfomace lib, I have got c, c++ even zig. If I wanna memory safe, I can use Rust. On the data processing, I cound use Python with C++. If there is a Native Mobile Client, maybe swift, kotlin even C#, dart with flutter always on the table. Why Should I?

That I think is the most aruggent thing that SCala3 or whole Scala economy shuold anwser. Flexible seem not enouth for me to talk to my team for using scala to write some
useful lib, or put it into production.

The second thing that I’m considing is What I got compare What I cost. I knewn Scala in my collage which is about 3 or 4 years before. And I’m new for a programmer, which just learned the C and Java. And I stucked in Scala because it’s beauty and powerful. I even picked building Spark App as my final project for graduate. But still, I cannot say I’m familiar with scala, becuse there is changed fast in this year, and it’s breakable changes! My coworker will not change there major programming language just for some beauty. They write Bash long rather than rewrite it as Python, using Java instead of Scala. Beacuse there is a pattern they have been trained, they have been taught, OOP even how to build software, we focus more efficiency in China, or we just need a reason that change the language that I have been familiar.

So that’s why I post the above posts, I do wanna let more and more people to use scala, but if I gonna pick a major programming, I would pick python or java even go rather than scala.

1 Like
16

Well in that case I’m sorry for suggesting you were. But to be totally honest your initial post did not read as an AI translation to me, but as though someone simply let a GPT generate an answer to the opening post of this topic.

17

I should note: my primary argument for using Scala isn’t that it’s elegant, or flexible, or anything like that. It’s that good Scala code is more maintainable than any other language I’ve found.

I mean, I’ve been programming professionally for 40 years; I’ve worked in 2-3 dozen languages for work in that time, and probably noodled with as many again. I was entirely polyglot for most of my career; I didn’t settle down on one primary language easily.

But good, idiomatic Scala code tends to wind up more expressive, and better-factored, than the results I’ve had in any other language. The result is that it’s easier to maintain and evolve a codebase in the long haul.

To me, there’s nothing more important. Some years back, I reified that as my personal First Law of Programmming:

Writing code is easy.
Maintaining code is hard.
So focus on making your code maintainable!

Everything else is commentary. It takes some effort to train up a team so that the quality of the code is reasonably solid and consistent, but the payoff is big if you want to have a large-scale, long-lived project that continues to evolve.

16 Likes
18

But good, idiomatic Scala code tends to wind up more expressive, and better-factored, than the results I’ve had in any other language. The result is that it’s easier to maintain and evolve a codebase in the long haul.

I can’t stress how that is right and important. We are maintaining and evolving Rudder for 15 years now, and it’s still solid and easy to do so. And it’s on a big part because scala is extremely helpfull for that.

We did several massive refactoring, like touching 30% of the code. Not only were they possible at all without sunking in months of impossible wake-a-moke games, but they want well.

So yeah, big up for scala maintanibility.

9 Likes
19

I’ve heard Sun invested 500M $ solely on marketing on early stages of Java. IMO Scala 3 is quite mature and stable now and really needs:

  1. New people
  2. Marketing campaigns backed by huge investments. It will bring new people
  3. Cooperation with real businesses. Solving business issues will bring investments to the table

And given the next tech revolution - languages working best with AI will shine, other will slowly die

These strategic decisions should be made at some point.

And I like the point about targeting China, but IMO - the one who targets India wins

20

even accepting acquisition if necessary

No, I do not agree with this. Corporate backing would be appreciated but they should be partnerships. Languages like Python and Rust with independent foundations similar to the Scala Center do just fine, on the development front without any acquisition.

We need corporate backing/sponsorship, and not corporate oversight.

8 Likes