RxAnything makes any language unreadable. RxJava is the bane of my existence.

I find Rx to be super clear usually. What problems have you run into?

Combine (Apple's Rx framework) is pretty understandable/usable as well.

In my opinion it's just easy to do wrong. Most uses I've seen (at least in java land) are attempts at non-blocking io which ends up turning the whole application into observables from bottom up. Which in turn makes your app hard to debug and reason about.

When done right, when you actually need the observer pattern, and use it as an event queue I'm sure it's probably amazing though.

Those are good points but I agree with the other commenter that these are just difficulties with asynchronous programming generally. I like that Rx makes reasoning about those issues more straight forward and something you must handle instead of something that will bite you later if you didn't think through it.

this is the problem with async programming in general not just rx. Relevant read:

https://journal.stuffwithstuff.com/2015/02/01/what-color-is-...

Yes I know about colored functions. I'm looking forward to loom and virtual threads on the jvm to solve that.

BUT it doesn't change the fact that Rx is hard to implement correctly and is often misused when you don't need the observer pattern.

When was the last time you compiled Swift code? Xcode's new(er) build system has solved many of the scaling issues that affected the previous system, to the point where it scales linearly (on large enough projects) even on a 28/56 Mac Pro, and my 10/20 iMac. Additionally, with cmake's native Swift support in 3.18(?), the scaling should be more solved across platform as well. There's certainly nothing in the language itself that prevents scaling builds, only the compiler and build systems.

The debugger is still rough, true, but improving. Apple just isn't spending the resources needed to bring lldb up to a great experience in a timely fashion.

Yesterday!

Swifts build system can split off enough threads to consume all of your CPU cores, and batch mode did improve things, but it's not actually doing so efficiently. There is a trade off between total compute time used and number of threads used. In compute time consumed, swift is the most efficient when it's single threaded in WMO mode, but this means you can only compile in parallel with separate modules that don't depend on each other. And even then it's not a very fast compiling language itself, multithreading issues notwithstanding

Maybe something has changed recently, but as far as Xcode 12 goes, I haven't noticed much of a difference. I last checked deeply with swift 4.

More details here: https://github.com/apple/swift/blob/master/docs/CompilerPerf...

> You're also effectively limited to xcode & apple desktops

Swift supports LSP now, so you can use VS Code if that's your thing.

But what is going to build your iOS/macOS application, the application of %99.9 of swift code? It's only going to build on macOS unless you are willing to illegally virtualize macOS on non-apple hardware.