Martin Odersky did a fantastic job with Scala then, and also with Scala 3 IMO from a language design perspective. When I first got into Scala, I was blown away by the language features and the type system. It was the reason I got back into the JVM and the reason for getting into functional programming (not pure FP).
Scala is a great language, and functional programming (not pure functional) made me a much better programmer. And functional error handling is a fantastic way to model success and failure, whether you’re using Either or the newer Result type.
I have to both agree and disagree with some of the commenters here regarding why scala declined in usage. There are several reasons.
1. People just got fed up with the push toward pure FP and the complexity. Pure FP and category theory, and effect libraries are just not for the average audience.
2. Android support for Kotlin drastically reduced the momentum as well
3. Spark usage was pretty heavy driver for using Scala and I’m not sure about it’s used as much.
4. Scala became more and more niche as a result of item 1 above.
This being said, I switched to Kotlin for all server side work. I think a language and in particular the ecosystem, needs the vision/stewardship that can offer more practicality and balance in the language design, programming style, tooling, and frameworks. Kotlin just became a simpler language with better support for all of the above.
I can’t think of a better company to drive the development than Jetbrains. I don’t agree with all the choices, but Kotlin overall is a beautiful, simpler language, with all the practicality, and support needed to keep it going.
However, now that Java is making strides in the language features, as compared to historical improvements at the VM level, I’m curious to see how the market share for Kotlin outside of android is going to be affected.
Personally, I still prefer Kotlin for the practical FP support, Ktor as an HTTP server, and pretty good compatibility with Java. And lastly, I think there is enormous potential in multiplatform, as a strong alternative to typescript/react native for mobile.
Disclosure: I am biased as I’m developing some libraries and soon to be made (more) public server framework.
> However, now that Java is making strides in the language features, as compared to historical improvements at the VM level, I’m curious to see how the market share for Kotlin outside of android is going to be affected.
My employer has decided to abandon Scala, and they proposed Java as the language to head toward. I don't think Java's strides are fast enough to provide modern table stakes. In 2025, the big ones to me are:
1. null handling at the cultural and language level
2. abstractions over concurrency
For null handling, Java has Option, but you're just going to have to deal with the fact that basically any API or caller can give you null. This is not good enough in 2025.
For concurrency, Java has an excellent java.util.concurrent package (and the JVM is very good at concurrency in general). However, I've come to believe that it's a losing proposition to expect the average programmer to use concurrency primitives correctly, even at that level of abstraction. Every Java PR I review I have to add 20-30 comments about thread interruption, memory barriers, etc.
Structured Concurrency helps, but is new/in preview, and hardly helps with actually providing safer concurrency operations.
I think Java is doing the right things and the glacial pace of innovation at the language level is correct for protecting their users (contrast this with Scala 3...), but on the flipside I just think that it is hard to recommend Java vs C#/Kotlin.
Kotlin will always be a second language on the JVM, it isn't what Oracle, IBM, and others think about when designing runtime features, and eventually like all guest languages will face the problem to either exposed the platform features, or have multiple ways, with different semantics, to achive the same.
Virtual threads, versus co-routines, structured concurrency, SIMD/Vector, value class/records,....
It frankly doesn't matter in which markets C# isn't an option - if you're in one of those, well... then obviously don't consider C#. That doesn't somehow indict C# as a language which better makes it possible to write concurrent code. For a very large proportion of the population, you're picking a language and running some services on a cloud provider or machine you control.
The problem I'm citing in Java is not the performance, it's the semantics and having to explain what an InterruptedException is to every generation of programmers, including those who came before me. If you think virtual threads somehow do anything about what's difficult about concurrency on the JVM, we're talking on different wavelengths. Structured Concurrency is the TINIEST of baby steps and doesn't really do anything to change the experience, and it's only just now in preview, in the most recent LTS JVM? Hardly a solution.
It doesn't matter whether the JVM is developed with Kotlin in mind, as long as Kotlin continues to offer a better way to leverage what the JVM does have to offer. It's not some killer argument that Kotlin somehow can't be useful if the host platform isn't specifically developing their roadmap (especially because you can... just write Java, if you need it?).
Scala's demise likewise has nothing to do with whether the JVM is supporting Scala, and any suggestion that Java's language features have eliminated Scala's value proposition are similarly misplaced.
It matters, because these arguments are always done as if programming languages exist in a vacuum.
Any guest language on the JVM will trip on the InterruptedException just as well, it is called leaky abstractions for a reason.
People reach out to guest languages, as they think they don't have to learn the underlying platform, then they discover the hard reality to master two ecosystems.
Improvements on the platfrom language eventually always drive the guest languages away, because all guest languages either lose their value proposition, or use the platform to bootstrap their own ecosystem.
Turns out when they take second option, they open the door to having libraries that only work in one platform, and the usual #ifdef like complexity.
Kotlin has a better future than Scala, beyond the JVM, because papa Google has ensured it happens, at least as long as they care about Android.
No, it doesn't matter. You are advocating for the special case, not the average case, and it has no bearing on C#'s _general_ aptness that it can't be deployed somewhere. The same is true of Java! This is nitpicking with no justification.
> Any guest language on the JVM will trip on the InterruptedException just as well, it is called leaky abstractions for a reason.
They can (and do) reduce how often and where you have to interact with it. I at this point am not sure whether you are intentionally arguing from a position of ignorance or whether this is actual bad faith. Are you suggesting that abstraction is not useful or impossible? Yes _obviously_ InterruptedException is still on the classpath and in implementation code; that doesn't mean we should throw in the towel and interact with APIs that constantly throw it.
> Improvements on the platfrom language eventually always drive the guest languages away, because all guest languages either lose their value proposition, or use the platform to bootstrap their own ecosystem.
You have done nothing to address the issue that Java adopts new features extremely conservatively and slowly. I already used the perfect example that you gave of Structured Concurrency, which is not only not enough, but not even available, and ten years late. It is simply false that Java has done anything significant to compete with its guest languages. Javascript, yes! C#... debatable, but certainly better at it than Java.
> Turns out when they take second option, they open the door to having libraries that only work in one platform, and the usual #ifdef like complexity.
This is why I'm skeptical of multiplatform approaches such as Kotlin's, but that my suggestion that Kotlin is useful is not based on any degree of multiplatform support. Even at the end of the day if I thought Kotlin didn't have a future, my point is that that is table stakes level of abstraction in 2025 and Java ain't it.
1. There was never a push. Functional ecosystems are simply the ones that survived. You can't blame communities that keep the language alive for doing what they want, and not what you want. Without Typelevel and ZIO where would be Scala 3's adoption today?
2. Android has never been even remotely relevant to the space where Scala exists. And no, this was not a missed opportunity for the language. People who think Scala had a shot are completely delusional.
3. I'm personally convinced Spark was the worst thing that happened to the ecosystem as it brought a lot of attention, and indeed, drove adoption, only to result in an incredible amount of shitty code plagued by the worst annoyances in the JVM and big data space. Spark is the biggest open source project in Scala, yet Databricks doesn't seem to give a damn about the language and couldn't even be bothered shipping a Scala 2.13 runtime for years after its release. I sincerely hope Spark moves away from the JVM entirely.
Kotlin is really not any simpler especially with the constant feature creep that results in copying Scala features, only halfbaked. It's even less principled which is the biggest gripe against Scala having too many ways to do the same thing. There's nothing beautiful or practical about a language where people regularly write expression oriented code next to early returns.
Given that Scala-Android efforts predate Kotlin, Scala could have had a shot at Android if EPFL resources were allocated to it, like to Scala.js.
Kotlin is not simple at all, it has a lot of keywords for strange and very specific features and corner cases, it's hard to remember them all. Moreover, the Intellij Kotlin plugin is somehow slower than Scala's despite being a 1st party language and not having implicits, how they managed to achieve that is a mystery.
Right and if you know the first thing about Scala, Kotlin, Google and JetBrains, it should be clear Scala on Android was simply never going to happen, even if Typesafe somehow managed to find extra millions in funding and could allocate dozens of people behind it.
It certainly would, had Google decided that would happen, and support the ongoing existing efforts from the community.
If you know anything about Google politics, you would know Kotlin only took off because of a couple of folks on the Android Tools team doing free advocacy for JetBrains.
In an alternative reality, if those same persons had been Scala heads, Jetpack Compose would be a Scala DSL today.
Scala was a bad fit for the Android runtime and the SDK. On a $200 Android phone with 2015 specs the performance aspect was definitely not a trivial argument against Scala; Kotlin has perfect interop with very little overhead, no conversions between collections (often slow and immutable in Scala), a nullability story that doesn't box everything in Option, ...
And most Googlers do not like clever languages with bad tooling, especially the ones working to productize languages and toolchains for Blaze and other internal tools.
You will never get me to say anything positive about the Kotlin advocates on Android team.
It isn't only Scala, it is using Java 7 samples to sell Kotlin, the original language for Android, still used for the large majority of Android tooling, where your argument fails flat.
They have begrudgingly being updating Java support, up to Java 17, when Java 25 is the latest LTS, because that great Kotlin interop with Java is useless when Android loses access to the Java ecosystem that keeps moving forward regardless of Android.
Some of them even don't have any ideas how out of date their Kotlin "improvements" over Java are out of date.
I'm not defending JetBrains or Google's decisions. But I don't see why anyone should try to rewrite history.
Scala had a decade head start. Many people at Google are aware of Scala, some being former LAMP students or staff. Google doesn't simply add a language to their small list of sanctioned toolchains.
Kotlin was specifically designed to win the politics argument, using technical merits: full interop, gradual adoption, low overhead, ability to target outdated Java bytecode efficiently (Kotlin used to inline lambdas for Java 6 bytecode for instance, while Scala boxed everything before invokedynamic). It doesn't matter whether one approach is objectively right or wrong, Kotlin fitted the bill and Scala did not. More importantly, Kotlin fitted the bill on Google's server side too!
Then of course JetBrains was tasked to replace the IDE with Android Studio, they could put dozens people backing Kotlin as a first-class Android language, until Google adopted it officially.
But even if Typesafe had somehow stumbled upon $100M in funding to do the same thing, it doesn't change the fact that Scala never had a chance.
Kotlin won Android on internal Google politics, zero technical merit.
Feel free to write another long reply on how Kotlin is somehow special, going to replace Java, while the first iteration of Kotlin Native was a failure with a broken design on its reference counting memory approach, and there is still no KVM to replace the JVM in sight, despite such greatness as pointed out in Android circles.
I haven't defended Kotlin's approach in any way, I don't know why you want to put words in my mouth.
However if you don't see why Kotlin was well positioned, while Scala was not, then you clearly don't know much about either language.
Technical merit is subjective, but different design decisions can precisely be made to win politics or not, and JetBrains made the right ones, first to convince people internally (who knew about Scala, you know), then Google, as they were fairly well aligned.
I know enough about Google politics, and JVM ecosystem is part of my toolbox since 1996, starting with JDK 1.0.1, I have lived through all hype cycles of JVM guest languages since Beanshell was introduced.
> People just got fed up with the push toward pure FP and the complexity. Pure FP and category theory
Amen. My eyes start to glaze over whenever I read about covariance.
It's one thing if a feature works because of category theory, but if you just "feel like arrays should be covariant", and then the actual category theorists come along and can't work with its limitations, maybe give it a miss.
Also agree with some of the comments here that majority of articles about OAuth are incredibly verbose, but really hard to actually implement without concrete examples.
I personally think having Curl requests as part of the examples would solve this problem.
Nice idea and the site looks well done! Congrats on launching this. I played around the site a bit and with the different panels.. a few thoughts/questions...
THOUGHTS
1. Target: Is the market for enterprise/work or for consumer/personal use or does it not matter? Similar question for people, is it more for people who need diagrams in combination with notes and if so, are these mostly technical people who could author both the notes / diagrams and for non-technical people who would read/consume them?
2. All-In-One: The inevitable question/concern on a tool that combines many things into one, is that, it being good but not great at any one thing. This is something I'm also dealing with on one my projects. How do you address this concern?
3. Limitations: Are there any limitations with the note taking, or the diagramming capabilities compared to specialized products / apps like Joplin, UpNote, Bear, or Draw.io ?
QUESTIONS
1. Tab: Is a "tab" analogous to a "note" in other apps?
2. Panels: Are all the panels linked to a tab and is there a limit to the panels?
3. Folders: I didn't quite get it, but how are multiple notes organized into 1 collection?
4. Diagrams: Do you have an example of a sophisticated diagram made with your app?
I use diagramming quite often, but it's mostly for work purposes for technical software architecture diagrams, which I eventually embed into other wiki pages and/or git readmes. For personal use at home, I can't remember the last time I had to diagram anything. The first thing that comes to mind is how does the diagramming compare to something more specialized like draw.io. I can definitely see potential in this for work purposes.
Thanks! feedback greatly appreciated.
Answers, for Questions:
1. Cluster of 4 panels is a tab, it can be 4 streams of notes, or 4 different types of modes - Diagramming/Codes etc. Or even 1 note but whole organization is a tab.
2. There is a limit, yes, right now only 4 panels are workable.
3. You can have unlimited tabs within a collection, it is for the 'separation of concern' where you would want to separate your things completely.
4. I do for features in my day job as a dev, yes. But sophisticated - may be not, but they are small features.
Thoughts:
1. I had to personalize for set of people, coding editors aren't used by non technical works.
2. I'm personally looking for people's inputs on this, thanks! My focus on developers in one such start.
3. Also welcome all your input on this, apart from the aesthetics, I didn't see any limitations.
Nice work on this! I’ve looked into task queue libraries for Node and Java in the past. Yours looks straight-forward. A few questions:
1. What’s the error handling strategy for when a task/payload fails?
2. How exactly do delayed tasks work? For example, are you delaying execution until say 10mins later? How do you process delayed tasks in sequential timed order?
3. What kind of metrics/stats are available?
4. Is there a way pause and resume or is this the same as start and stop?
1. That's the part I'm not happy with, but currently I use the `@wakaq.after_worker_started` decorator to setup an error logging handler in each worker. It outputs to a file that gets aggregated for error reporting, but without examples most people wouldn't know to do that. Here's the code: https://gist.github.com/alanhamlett/365d48276ac054ae75e59525...
2. Delayed tasks are added to a Redis sorted set, where the eta datetime when task should run is the score. Then the sorted set is queried for all items/tasks between zero and the current time. That returns eta tasks which are ready to run. Those tasks are added to their equivalent non-eta queue at the front and executed by the next worker. Eta tasks might not run right at the eta datetime, but they shouldn't run too early if all worker machines have clocks synced with time servers.
3. wakaq-info prints all queues with counts of pending tasks and pending eta tasks. Throughput isn't printed and has to be calculated by sampling wakaq-info at least twice. You can also import info from wakaq.utils to use it from a Python script.
4. No built-in way to pause. I pause by sending a broadcast task to all workers, which sets exclude_queues to all queues and then restarts the worker. Then it only listens for broadcast tasks and can be turned back on with another broadcast task.
Some suggestions based on my own experience working on various projects/services/startups over the years…
1. “Avoid 100%”: By this I mean avoid 100% in that balance can be as little as reserving a minimum of 1% to X% of your available time on things unrelated to the startup (self care, family and friends, health and exercise, leisure, etc). I’ve met enough people that go a full 100% and let life pass them by.
2. Time off: Take a weekend, a week, what ever X time you need
3. Self-Care day: Dedicate a day or evening for yourself. I usually use Wednesdays and refer to them as no work Wednesdays. I focus on myself, spending time with people, errands, leisure, etc
4. Focus on other things. Funny enough I was surprised how much inspiration and ideas I got from doing things completely unrelated to my project/startup
5. Change: This is subtle but quite useful, make a change in your core responsibilities to a lateral role. As founders, we are typically generalists and do a lot of different things in the early stages. Sometimes you can become overwhelmed, stressed, just grinding work. If you can, change what you’re doing. Say instead of intense engineering, spend some time or stretch of time focusing on product, connecting with customers, ideation. Just anything other than the previous role.
6. Time and Place: I’ve always been a night person so my best work is at night, but I realized the type of work I do best at night is more creative, research oriented, ideation type work. It’s not hard problem solving, it’s more relaxed, care free, inquisitive, creative work. Understand when and in what setting you perform the best type of work.
I think the main differences Scala being much more of a functional programming language where as Kotlin is a bit of a balance between Java/OOP and FP and affects the complexity/learning curve of the respective languages.
OVERVIEW
- Scala is much more of a functional programming language
- Scala has a steeper learning curve
- Scala community/ecosystem leans much more towards FP
- Kotlin is like Functional Programming "lite"
LANGUAGE
- Scala: has higher kinded types
- Scala: has for comprehensions
- Scala: has type classes
- Scala: has built in support for monads
- Scala: has better support for encoding errors at compile time
MARKET
- Kotlin: has heavy usage on Android
- Kotlin: on the server side is pretty active too
- Kotlin: integrates nicely with java
- Kotlin: multi-platform support
Choosing Scala with the intent of only using the simpler parts isn't a path I've seen work out. Maybe with strong dev culture, documentation, and tooling that could work. My experience has been that you end up with more complex implementations than you wish you had to maintain. The other way to go is to hire for it--so everyone is competent and comfortable with that level, at which point it's typically not the subset. With that view I would only suggest Scala over say F# or OCaml if JVM compatibility was a requirement.
It's fine, actually. I've been working many teams over the last eight years using Scala. The important thing is to know where you _don't_ want to go and you'll be fine. Clean code is a developer's agreement.
> My experience has been that you end up with more complex implementations than you wish you had to maintain.
Don't you get that with any language? I for one always find myself in a battle against complexity, no matter the language.
There is a difference. The advanced Scala one may be simpler in concept if the high level concepts/idioms are known and a complete mystery if not. With less expressive languages the complexity is due to the volume rather than nature of code if that makes it any clearer.
Metaprogramming or code generation is similar. You can certainly make smaller, more sophisticated solutions with it. I would consider that has a comprehensibility cost and need some justification for its use, if not merely for academic/learning purposes. Maintainability could go either way depending on the situation and team composition.
This is some impressive stuff! Congrats on a sizable achievement. I just went through your website, have a few questions...
Questions:
1. SCALA: is the generated code ONLY scala? are other languages supported?
2. CODE-GEN: is it designed only for code generation for a target http framework or does it actually provide an "API Server" itself ( e.g. like graphQL )
3. COMPARISON: the list of frustrations with other solutions, listed in your intro/technology goals are somewhat high-level. what are the "leaky abstractions" or "non-deterministic behaviour"?
4. SETUP: does someone need to know scala to use this ? ( depends on #1 above )
5. DSL : is the protoforce code implemented as a DSL in Scala or its a "language" in itself?
6. IDE : how do you check/compile the code? does it integrated with an IDE?
As a Scala Engineer myself ( though I mostly work in Kotlin now for Android/Server ), this looks great, but most Scala engineers i've met are focused on Spark, and using Play Framework/Http4S, etc. How big is the actual market for Scala API tools?
3. Please take a look at the documentation, it has a good outline of the features supported. There are many features, most are well documented there.
4. No, not really. You can do with other languages, it provides both client & server sides, so no other language is needed. Again, you can still generate client side stuff for other languages and use them to connect to your server.
5. protoforce website was implemented using the protoforce DSL itself. The parser and transpilers are written in scala. The portal is written in typescript + react.
6. There is currently a sandbox at the website which you can experiment in. There is no currently integration with other IDEs, but language server can be added a bit later for VSCode for instance.
I’m working on a Kotlin Framework to build Apps, APIs, CLIs, Jobs and Mobile apps, it’s available at https://github.com/slatekit/slatekit with docs at https://www.slatekit.com Been at it for a several years on and off, I’m not sure what’s going to happen to it, but I am using it to build a mobile app and self hosted mobile backend.
