What is the problem with that though? I honestly wish they moved the async key word to the front `async func ...` but given the relative newness of all of this I've yet to see anyone get confused by this. The compiler also ensures everything is used correctly anyway.
The problem is that that the Swift function signature is telling you that someone else needs dealing with async suspension and exception handling, clearly not the same semantics.
In a sense it is telling someone else that yes, but more importantly, it is telling the compiler. I am not sure what the alternative is here, is this not common in other languages? I know Java does this at least. In Python it is hidden and you have to know to catch the exception. I'm not sure how that is better as it can be easily forgotten or ignored. There may be another alternative I'm not aware of?
Isn’t the Go version also forcing the callers to deal with the errors by returning them? The swift version just lets the compiler do it rather than manually returning them.
And sometimes you even have to use the return value the way the function annoates as well instead of just pretending it's a string or whatever when it's not! Having the language tell me how to use things is so frustrating.
Kotlin has become a pretty big and complex language on its own so I'm not sure this is a good counterexample.
The fundamental issue is that fixing Scala 2 warts warranted an entirely new compiler, TASTy, revamped macros... There was no way around most of the migration pains that we've witnessed. And at least the standard library got frozen for 6+ years.
However I agree that the syntax is a textbook case of trying to fix what ain't broke. Scala 3's syntax improvements should have stuck to the new given/using keywords, quiet if/then/else, and no more overloaded underscore abuse.
One impressive thing for us is that the changes to macros were hardly an issue. We'd been trending off macro-heavy libraries for a while, and our Scala 3 adoption has not really been harmed by the new macro system.
Scala 2's syntax is mostly Java/C-style with a few peculiarities.
Scala 3's optionally allows indentation based, brace-less syntax. Much closer to the ML family or Python, depending on how you look at it. It does indeed look better, but brings its share of issues.[1] Worse, a lot of people in the community, whether they like it or not, think this was an unnecessary distraction on top of the challenges for the entire ecosystem (libraries, tooling, ...) after Scala 3.0 was released.
My personal take is this would be like JavaScript adopting an optional Coffeescript[1] syntax. It's so different that it seems odd to make it an option vs a new language, etc.
That shouldn't be the case. There's an extension to VoWiFi to support SMS over IP. With 2G and 3G going away it's not like your carrier has a choice anyway.
Scala CLI should have happened 5 years before, but honestly sbt has improved a lot, the DX is mostly fine since the 1.0 release and it's maintained plugin compatibility for 8+ years.
Gradle is worse on several dimensions, which didn't really hurt Kotlin's adoption, nor seems to fundamentally bother Android developers (ok, they have little choice here).
Gradle is only still around thanks to Android, thankfully I have moved away from Android projects.
No need to read about how Kotlin is going to take over the world, while comparing it to samples written in Java 8, or the whole tooling infrastructure mess that needs to be changed, sorry improved, for each Google I/O, or stable Android Studio releases that crash on first use after upgrade, while "fixing" Gradle DSL changes.
I'm not advocating for Gradle either, but you already pointed out why the build tool being bad is relevant for Scala and not for Kotlin - Android developers have enough other reasons that they're going to use Kotlin, even though Gradle sucks. Scala developers... don't, and so just another straw stacked on a camel's back, so to speak.
I'm not saying it played no role, but I think sbt's negative impact is overblown.
Maven is old and the DX isn't particularly stellar either. User friendly build tools are a relatively recent development in the programming language landscape. Hell, until uv, Python managed to be much worse than anything on the JVM.
I work at a company that used to do a lot in Scala, and I've seen the decline first hand. Lack of investment in basic upkeep and maintenance is the real killer. Bitrot hurts in Scala more than in Java. And sbt is not the biggest offender there.
I also work at a company that used to do a lot in Scala, and have seen the decline firsthand. Who's anecdata is better?
I think a lot of posters make the mistake of saying "$otherLanguage has it worse." That's irrelevant! If otherLanguage is an incumbent, they can afford to have it worse. I don't think it's debatable that sbt harmed adoption in the first place and continued to represent a barrier to Scala's adoption for years, and it doesn't matter how good maven is or isn't.
The degree to which is certainly always going to be up for debate; as mentioned before, there are many factors, but sbt was not a nonfactor.
My point is that the decline is multi-factorial, as usual.
Scala needs some investment and commitment, you need a least one person who knows what they're doing: enforce a reasonable coding style, keep dependencies aligned and up to date, enable all the automated checks and linting, ...
Usually, when this is in place, then sbt is mostly a non-issue. You onboard a junior, they follow established practices, that includes the build. Sbt plugins are in fact a good way to standardize builds in a corporate setting.
Scala CLI was made for students and people who come from the outside. Sure, sbt is scary to them. But in the grand scheme of things, that's not what matters. Industry adoption doesn't really depend that much on the "zero to hello world" experience.
Case in point: several big Scala shops use Bazel. Bazel is 100x scarier than sbt and requires a bigger upfront investment.
Bazel being used by some companies is not vindication that sbt wasn't a significant source of friction, just another arena where sbt was considered less fit for the job (whether one could argue sbt should have been able to do the job would certainly be context-dependent).
If you work on internal libraries and apps, on a team with established practices, sbt shouldn't be a regular source of friction. It's really not that hard to define re-usable templates (you can even use Giter8!) for the typical multi-module build in a work setting. 99% of my projects either publish libraries to an internal Maven mirror, or packages apps with the native packager plugin, often OCI images nowadays. Sbt can be easily bootstrapped behind a Maven Central mirror entirely, you just need a single bash script. Sure the Maven and Gradle integrations in IntelliJ IDEA are more polished, but I'd pick sbt over these two without thinking, even for pure Java projects. Nowadays Mill is even better in many cases.
And the fact Bazel rules exist for a language doesn't say much about its native toolchain really. Large scale polyglot codebases and especially monorepos don't play nice with common tooling. But anyway you're missing my point. Developer friendly toolchains are the exception, not the norm. There's some impact on industry adoption, but not a huge one all things considered. Otherwise nobody would have touched Python before 2024.
I think we're simply going to have to agree to disagree.
Your position presupposes quite a bit of "systems already in motion" to make the point that there isn't friction. Except... there is, and _somebody_ has to maintain your builds, and handle all those fun deprecations like when the integration test project gets removed and the syntax gets updated. These things aren't stable, untouched pieces of your services over time, and I want everybody on my team, not just some experienced Scala developer who has already performed the rituals required to understand and establish practices for sbt, to contribute.
And what about the onramp to Scala? I'm certainly not relying on a team of established practitioners to pave the way when I'm learning a new language. We're talking about a dying language, I think it's silly to dismiss this.
> But anyway you're missing my point. Developer friendly toolchains are the exception, not the norm. There's some impact on industry adoption, but not a huge one all things considered. Otherwise nobody would have touched Python before 2024.
And you continue to miss mine - incumbent languages can afford more friction than niche languages. Python or Java's ability to have mediocre dev experiences do not have much bearing on how impactful Scala's is (though frankly, Java is not really worse than Scala in my opinion, and trendwise I think we see sbt displaced by java tools or mill more than maven or gradle in the reverse, so the industry tends to agree).
And again, if there's nobody that can maintain sbt builds you're screwed anyway. This is precisely what I said earlier: bitrot and lack of upkeep are the real killer. Sbt is the least of your worries in such scenario. There's no way a team of inexperienced Scala developers can bootstrap a greenfield project unsupervised, unless they're committed to a slow and painful onramp period. Sbt is just one small variable here.
For the sake of argument, imagine Scala had had the best build tool of the entire programming landscape in the past two decades. This would change nearly nothing to the current situation and Scala 3's adoption.
Scala 3 really landed at a bad time as the hype behind Spark, Akka, Play had already weaned off. Typesafe was struggling financially, and didn't back Scala 3 then (that went to VirtusLab).
Typelevel and ZIO really put a lot of effort to release many libraries on day 1 despite the hurdles with the 3.0 release, because these communities are alive and healthy. Yet Odersky is on a small crusade against monadic effect systems, which discouraged a lot of good people. On top of that there are neverending feuds and US politics...
Akka's demise started before the license change. It's an incredible piece of software but as it turns out, not so many people need stateful cluster sharding. Modern cloud architecture and simpler streaming libraries have made the Akka toolkit irrelevant to many use cases.
You're right about Spark and the next logical step will be removing the JVM from the equation entirely, which is already ongoing (see Photon or Comet).
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.
I haven't seen separate APNs for RCS here†. Since the iOS support, what "offered by the carrier" means in most the world is only (de)registration through IMS service entitlement. Unlike the Google Jibe / Messages pairing done OTT using an SMS token to check your phone number, which is still the case in a lot of countries. Once the registration established, it's plain data traffic to Google servers.
† Here = "global" RCS, de facto controlled by Google. I haven't checked carrier settings for RCS islands such as the deployment in China or Korea.
