hocuspocus

EPI is the interface and it's built upon SEPA and TARGET standards.

Wero is the implementation. I think it makes sense to provide a turnkey solution to all participating banks, so that we don't have 100+ versions of the same app.

Countries that don't want to trust EPI (or simply outside the Eurozone) are able to take the same path as Bizum in Spain, and make their domestic solution interoperate with EPI instead of replacing it.

Completely false. They don't apply to 3-party systems.

Some of these are 40+ years old.

It makes sense to build upon modern SEPA payment rails and focus on mobile wallets. Europe has always been on the forefront (Swish, Vipps, ...) and we have entire generations of consumers who barely if ever use plastic cards.

Aren't stablecoins better for that? Especially when the current US government is seemingly OK with a very centralized entity holding over $100 billion in T-bonds, backing a coin that's mostly used for pig butchering scams and sanction evasion. No need to pretend blockchains are remotely useful with such actors (BNB comes to mind too).

These job portals (SwissDevJobs.ch, GermanTechjobs.de, etc.) are incredibly self-selecting.

I don't know any half-serious company posting ads there. And I'm not even talking about top tier or second tier tech companies, just tech adjacent employers paying market average.

Same with recruiting agencies matching people with startups. There was talent.io (not sure if it went under or re-branded) sharing ridiculous salary reports.

I'm all for transparency, but if your customer portfolio is literally paying bottom quartile salaries, I don't think this helps anyone.

Mostly the latter. Scala 3 is almost completely irrelevant to the big data space so far. Databricks took six years before upgrading their proprietary Spark runtime to Scala 2.13. Flink dropped the Scala API before even moving to 2.13. I don't know if Scio will seriously attempt the move to Scala 3. All of them suffer from Twitter libraries being abandoned, which isn't insurmountable, but an annoyance still.

And I don't think it matters anymore. I predict that the JVM will eventually be out of the equation. We're already seeing query engines being replaced by proprietary or open source equivalents in C++ or Rust. Large scale distribution is less of a selling point with modern cloud computing. Do you really need 100 executors when you can get a bare metal instance with 192, 256 or 384 cores?

People want a dataframe API in Python because that's what the the ML/DS/AI crowd knows. Queries and processing will be done in C++ or Rust, with little or even zero need for a distributed runtime. The JVM and Scala solve a problem that simply won't exist anymore.

More like 10. The Scala ecosystem was still really rough in 2011, remember how many companies got burnt trying to follow Twitter's footsteps (cf. the infamous Yammer testimony).

I've onboarded experienced and inexperienced developers to fairly big Scala codebases for the best part of a decade and I can't think of a single time symbolic operators were brought up as a source of complexity of confusion. Sbt deprecated <++= 10 years ago.

He won't: https://bsky.app/profile/eed3si9n.com/post/3mdgbjkg4ck23

Scala's decline started before Scala 3, which brought its share of breakage (sometimes for dubious reasons, like the new syntax) but also fixed many warts. Tooling has improved a lot lately, but it's too late.

> if you are not bound to the JVM I really don't understand why you would go with Scala today.

Scala's metaprogramming abilities coupled to a powerful type system are still unmatched. Among mainstream languages, only TypeScript gets somewhat close. For your typical service oriented architecture, libraries such as Tapir or ZIO HTTP are pretty nice. I haven't found anything as pleasant in other languages.

That said if an LLM can write 95% of your code today, this point is a bit moot, sadly.

Unlikely, iOS still doesn't support RCS in most European countries.

So, no. MMS is increasingly being discontinued in several regions, and RCS support is extremely patchy worldwide, especially on iOS.

Message payloads go directly to Google servers, there's no difference in practice.

Carriers handle IMS registration, that's it. And not even in all cases.

It's indeed hard to overstate how much Google fumbled the bag given their position. Early Android adopters came from GMail and almost invariably used GTalk on desktop. We had video chat over 3G in 2011 before iOS. But somehow they had to rewrite the app and try to ship an half-assed SMS integration in Hangouts as reaction to iMessage. Google should really have tried buying WhatsApp more seriously, at least we'd have seen some real competition between WhatsApp and FB Messenger.

> I won't be shocked it it will be treated as a carrier with licenses et al.

So, the way it works:

The GSMA isn't some kind of monolithic entity with a great deal of power. Industry players with aligned interests come together, form groups and agree on specs and roadmaps. Technically, RCS should be mandatory with 5G. In practice, it took a great deal of time before a country actually enforced that (China).

Google has seemingly been at the helm of the RCS work group since 2015~2016 with the Jibe acquisition first, then the spec revamp, a.k.a. Universal Profile. RCS was essentially a zombie initiative after ~2012, Google saw an opportunity and filled the void. Telcos aren't stupid, they saw P2P messaging being wiped out by OTT services, and SMS is good enough for A2P. There was little incentive for them.

Now, after a lot of failed experiments, and pivoting from a semblance of federated network to a protocol almost controlled end-to-end, Google got what it wanted: iOS support in North America. The rest of the world is mostly lost to WhatsApp and friends anyway.

Carriers that are on board with Google need to enable the standard registration mechanism used by the iOS client. It shouldn't be a big deal by the way, IMS is central to 4G/5G deployments for VoLTE, VoWiFi, SMSoIP, ... but this changes one important thing from a legal standpoint: now the service isn't provided by Google through an ad-hoc client (Google Messages), but by your carrier.

That said, Google can sell SaaS solutions to carriers. It's up to them to comply with local laws when they decide to provide RCS, regardless of the backend.

I think the EU has bigger fish to fry with the DMA. But Google's tactics might eventually come to someone's attention, as they essentially cornered carriers into adopting Jibe, or giving up on RCS. Somehow the only country that didn't let that happen is South Korea.

Moreover Android could separate the RCS client frontend and backend, like it does for SMS and MMS. But realistically most OEMs don't seem to care, and third party SMS apps are fairly niche.

US and about 180 other countries too.

RCS networks outside Jibe:

- China

- South Korea

- Japan with +Message, on its way out for Jibe

- Jio in India (very strange case as Android subscribers can use Google Messages on Jibe)

Global RCS == Jibe.

Google killed off all interconnected hubs.

The iOS client sends an app attestation token during registration.

Jibe could let any compliant client connect doesn't mean it does in practice. Case in point: Harmony OS.

Re: lawful interception, when carriers switch to IMS registration (as required by Apple) they should also get access to Jibe's standardized API for law enforcement tools (there's a spec for that, I forgot its name). However, just the fact RCS payloads are E2EE in Android-to-Android communications (and soon Android-to-iOS too, hopefully) might already be illegal in some places.

Google flip-flopping around its mobile IM strategy for a decade and then around carriers with RCS is getting harder and harder to understand. Pulling the rug under carriers in developing countries, who weren't interested in the drug dealer marketing tactics, is only going to solidify Meta's dominance, as doing business with WhatsApp has proven to be a much safer and saner bet all along.

This seems very specific to a few regions, India mostly.

Google is doing a really good job catching and blocking spam as far as I'm concerned. Even scammers aren't trying their luck over RCS in any way significant compared to Telegram, WhatsApp, or even iMessage.

> LineageOS, GrapheneOS, /e/, and all the others could build their own RCS client. They may not be able to register with Google, but they can make an RCS app nonetheless.

Building a spec compliant RCS client for the love of the game, I guess.

> but there's no need to pay Google a dime to make use of the RCS for Business specs.

Assuming we're talking of global RCS and not domestic deployments (China and Korea mostly) you pay Google indirectly in all cases as Jibe is monetized via A2P revenue share.

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.

Not defending Go's braindead error handling, but you'll note that Swift is doubly coloring the function here (async throws).

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.

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.

- [1] https://alexn.org/blog/2025/10/26/scala-3-no-indent/

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.

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.

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.

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.

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 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.