hocuspocus

Nuclear waste is a nice problem to have, and fairly simple compared to most pollution sources associated with our lifestyle.

No need to worry though, on the current trajectory I doubt our civilization will have the opportunity to deal with it.

You're just supporting my point.

Many European countries do install AC actually, poor ones at that, so it'd be a valid point because yes, it's that easy.

Both sides of the same coin, I'd be surprised if Databricks wasn't looking into getting rid of the JVM entirely.

The data processing space is increasingly tangled with ML and AI, Python on top of C++ and Rust libraries makes sense, keeping the JVM to orchestrate tasks and shuffle data around, not so much.

Right, especially if you were burned by Scala, Kotlin is even less principled, and lately has grown in complexity, partly thanks to re-inventing several Scala features, only worse.

I also talk to pure Java teams, that never considered anything beyond the typical Java/Spring/Hibernate, they won't even have a look at slightly more modern approaches (Quarkus, Panache, build-time annotation processing and native images) despite jumping on new version of Java rather quickly. They couldn't care less about guest JVM languages.

Roughly speaking I believe that developers who enjoy Scala won't go a lesser language, that looks similar on the surface but specifically takes away what makes Scala special. Then people who dislike it will just stick to the most vanilla Java stack, which benefits from being literally one of the most popular choice on Earth.

Of course there are a few people doing Android or KMP, or who think Kotlin is in the right spot on the backend. But usually they aren't coming from Scala.

How's that relevant to people moving away from Scala?

Which moderators exactly? That hasn't been the stance of people in the Scala Center, Typesafe/Lightbend, VirtusLab and SoftwareMill.

ScalaZ is old news and if you went there (on IRC at the time) you knew exactly what you wanted. It doesn't excuse people being assholes, and the Typelevel schism happened partly because of that. Since then people on Gitter and now Discord have been nothing but kind and welcoming to newbies. Same in the ZIO community.

Of course, people building FP libraries will defend their ways. Odersky doesn't build the library ecosystem, and without the FP community Scala 3 would pretty much have killed the language entirely, as nothing else was ready until a few years later. It makes sense that people keeping the main open source communities alive have a bigger presence in the broader community, it's almost tautological.

I haven't seen a huge deal of momentum around Li Haoyi's libraries for instance, they're very much used in their narrow scope, but there's no ecosystem per se. Even his own build tool struggles there despite the technical merits, and he's been advertising Mill non-stop in the past years.

You can't force people to buy into your way of doing things. If there was space for a great non-functional landscape built in Scala then it would exist. Nobody stops you from building and gathering with like-minded people.

Not only it happened at the worst possible time, but some pain points are entirely self-inflicted, like the braceless syntax hurting tooling and fragmenting the community for very little reason.

But in my opinion Databricks implicitly saying "no thanks" for the foreseeable future did a lot of damage here. Databricks didn't even bother bringing their proprietary runtime to Scala 2.13 until last year. Scala 3 is not entirely out of the question but it's taking forever, and at this point users can seriously ask themselves if Spark will actually stay relevant that long.

I try to keep track of teams moving away from Scala at my company and among my friends and acquaintances, and I know a lot of key people in the community.

Scala to Kotlin stories are extremely rare.

Kotlin is almost non-existent in the data processing world (Spark, Flink, Kafka streams...)

Kotlin's presence in the average CRUD web app or more complex SOA doesn't overlap with Scala that much, as someone who enjoyed the paradigms available in Scala would definitely not move to Spring, and frameworks such as Ktor or http4k are pretty niche. I've seen people move to modern Java, Rust (a lot actually), even Go despite the language being at the other end of the spectrum. But Kotlin, not really.

I'm pretty sure most companies don't care nor are aware about the community drama. Arguably Rust is worse, and it doesn't impact its uptake.

Scala was sold through Akka and Spark, solving pretty complex technical challenges that are less relevant nowadays. In fact if you can avoid Akka and Spark, do.

A lot of companies followed the hype without investing in the developer experience. Tech debt hurts more in Scala than in a bigger, slow moving language. After typical turnover, you get teams inheriting unmaintainable codebases. This leaves a bad impression. It can be avoided, Twitter built world-class SOA with Finagle, as well as a complete layer of libraries on top of Hadoop, at a time where the Scala ecosystem was even rougher.

The fact Databricks doesn't care much about the language also did tremendous damage, forcing the community to cross-build against very outdated versions of Scala.

In short, Scala was never a better Java and adopters who thought otherwise invariably got burned.

I wonder how you see 10x more Clojure news.

Scala's usage is stagnant or declining, but Clojure has always been tiny in comparison. It doesn't even register in most rankings (TIOBE, StackOverflow) which is also confirmed by hard numbers e.g. GitHub statistics.

In Scala, .sc is used for worksheets and inconsistently for scripting, see https://scala-cli.virtuslab.org/scripting for instance.

Java LSPs are essentially the same approach, headless Eclipse JDT or NetBeans.

While Metals for Scala was an overhaul from the former Eclipse plugin (and Ensime) plus early experiments embedded in the Scala 3 compiler. And Metals v2 is yet another rewrite.

Metals is architectured in a completely different way, see the BSP: https://build-server-protocol.github.io

No I'm not.

Ask anyone who tried to dispute a purchase that happened within the EEA, whether online with SCA or card present with PIN, card issuers often tell you to deal with the merchant directly. The interchange cap has significantly reduced revenue made on card payments, they have an incentive to avoid unnecessary manual work.

I've never used iDEAL but I assume the confusion comes from the fact checkout widgets (e.g. from Adyen) are transitioning from iDEAL to "iDEAL | Wero". I assume UX is the same, i.e. scan a QR code with your mobile wallet app?

If I understand correctly it's developed by the same people: Payconiq.

Which is pretty much the case with Visa and MC too. There's little card payment fraud in Europe thanks to mandated strong authentication, and very low transaction fees as interchange is capped by the EU; card issuers don't initiate chargebacks so easily.

I'm on DC5 since I lived in Korea when signing up, but I cannot say I've noticed many outages.

Easy and approachable sound pretty subjective to say the least; feature and syntax wise, Swift has become an absolute monster of a language. Rust's tooling and ecosystem are ahead and these points matter to me more than the raw syntax in the age of LLMs.

Almost exactly the same (or worse) can be said about Google's E2EE RCS, but somehow Apple decided to publicly back the initiative. Most people would much more benefit from 1) a faster and broader rollout 2) every other feature in recent versions of the spec, rather than getting a false sense of privacy, yet we're getting a barely compliant RCS client stuck in 2019, plus performative E2EE.

SEPA transfer fields need to follow a standard. I think it's fine, we shouldn't put more control and censorship there (try to put Daesh membership fee if you want to get your account locked...)

However a chatbot should absolutely not be able to display arbitrary and clickable links outside a pretty tight whitelist (like, the bank FAQ).

I was a teenager when Switzerland introduced the mandatory ID check, in 2003 or 2004 iirc.

My carrier added 10 CHF credit to my prepaid plan for the trouble.

It's still fairly easy to buy a Lycamobile SIM/number that was enabled with a fake or stolen ID. Consequently some banks and services ban entire number ranges, which is not only ineffective but also affects people who committed the sin of keeping their first phone number even after moving to a proper postpaid plan...

Bilateral agreements were signed in 1999 and freedom of movement enacted in 2002 so you must not have looked very hard. Also claiming that immigration from a country like Portugal was hard before FoM is extremely funny given the number of Portuguese immigrants in Romandie.

Words have a meaning and bringing diplomatic permits to the topic when they follow their own rules and are specifically outside any immigration quota is not particularly helpful.

You're throwing a lot of words that you don't understand nor have much relevance to the topic.

Before bilateral agreements and the freedom of movement, not Schengen which was ratified much later and is completely irrelevant here, you needed a work permit, not a visa (lowercase), which anyway at CERN is the equivalent of a diplomatic permit given to all international and tax-exempt NGOs in Geneva/Switzerland. And of course you lose your CDL permit quickly after your contract expires.

Getting a B permit before FoM would specifically not have been as hard for you as for someone from another continent.

Schengen is not FoM. Visa isn't an acronym. And CERN workers are on diplomatic permits anyway.

FoM doesn't require to stay in Schengen-Dublin though.

To be fair that's not specific to SVP's populist initiatives, the parliament pushes bills with nonsensical names all the time.

Yes. We can cap non-EU/EFTA immigration to zero but that's relatively small anyway. Getting out of Schengen-Dublin and more importantly the Freedom of Movement of workers would basically unravel all bilateral agreements.

And now with LLMs, writing glue in Rust is cheap.

The ML/AI ecosystem is a minefield, and pure Rust rewrites (Candle, Burn, ...) are still immature and incomplete. But I'm pretty sure we're eventually going to see the same uptake that's already happening in the data processing world.

LLMs are leveling the developer experience and productivity in a way that makes Python's strengths almost irrelevant, while it's still suffering from bad tooling (even with uv and friends) and poor performance.

AI/ML: interfacing with C++ libraries directly (or in Rust) is now a real option. For everything else, even 5 years ago I wouldn't have used Python, now there are even fewer reasons to do so. As far as I'm concerned the remaining use cases are notebooks and one-shot scripts.

Which is precisely a reason for not using Python, despite LLMs being good at it.