it seems like these fundamentals are in tension, and tradeoffs need to be made, which just means that there won't be a one size fits all paradigm. maybe someone will create something that is truly magic and does everything, but more likely they're trying to sell you something.

I also don't see why a namespace, like that of a function, won't be enough isolation from peeking between actors.

Somehow Scala got Akka, the actor framework, without having to tailor the language for that.

That's precisely what actors aim to solve. Actors pass messages, not memory.

> Akka

If you look at an actor framework built in a feature-rich language (Orleans), that problem isn't apparent at all. Even Rust, with all the ownership complexity, manages to do elegantly handle actors, without an explicit plan to do so. Your critique is more relevant to Java than actor libraries.

I haven't tried it on Windows yet, but I know that it is officially supported now.

A stated goal is static, compile time, prevention of concurrency error. You can't do that with a concurrency library unless you restrict yourself to purely deterministic code.

If you ditch Foundation and rely on C libs you are able to use it pretty much anywhere.

In my own experimentation, I’ve seen some success with Vapor 4 and PlotHTML

In theory any C based UI libs that support those platforms should work as long as they can be called from Swift.

The most difficult thing I’ve done with Swift/C was packaging a Python interpreter inside a Mac app with a few lxml dependencies called with PythonKit. Might not begin to scratch the surface of what you need though...

Nice job embedding Python in Swift. I haven't done Python, but Wren and Gravity were pretty challenging to get working right. I was going to use a scripting layer for the UI, but eventually came up with a solution that allows for Swift to be used. I sort of mimic the system Apple uses for Playgrounds/Live Preview in Xcode.

I'm not a Swift user, but the approach I've seen is people using it to run a localhost HTTP server for a HTML+JS frontend.

i have been carefully avoiding any objective-c code so far, but i must admit i haven't been to careful with foundation dependencies.

Do you have a blog post explaining what you did and what limitations you encountered ?

You can find some info by searching, there has been a few attempts to get it running on Android. Also just searching around github will net some other attempts.

The foundation dependency is the biggest problem. You can check out https://github.com/apple/swift-corelibs-foundation which gets rid of the objc runtime dependency for other platforms, though you will find yourself writing implementations for each eventually.

I would say if you are going to stay with just Android/iOS to look into maybe moving to Kotlin or C for your common layer and then call it from Swift. Kotlin multi-platform also has been improving recently.

EDIT: Also look at the Swift github, there are some docs about different platforms. https://github.com/apple/swift/blob/main/docs/Android.md

"Actor" in this case is more like a new access modifier than another type.

I don't see how you could really do this in a standard library as cleanly.

The reality is that the ability for this to happen _always_ depends on the motivation of parties to make it happen. With a proprietary language/compiler, you are at the mercy of the owner while with open source you can contribute the changes - but in either case you can't will other parties to see the business value and do the work for you.

There are still first-party projects to help with Swift on the Server (which is necessarily cross-platform), swift has official containers on docker hub, there is and Apple does contribute to these efforts. X86 Ubuntu, Centos and Amazon Linux are part of Apple's official CI, while the community contributes CI for various other chip architectures, Android, and Windows.

However, the bulk of Apple's investment in Swift is obviously in their own interests - just like any other open source contributor. IBM and Google both stopped contributing officially, but from what I've seen it appears that has more slowed community work than stopped it.

That’s hard to answer without a “since when”, but the answer probably is “yes”. See https://swift.org/platform-support. There are Windows binaries now, for example.

Many of Apple’s libraries aren’t available on non-Apple platforms, though, so many would say it hasn’t improved enough to be competitive with other languages.

The only issue for me is that I don't use Swift Package Manager, hence, the build system (Bazel) integration is simply not there (the BSP support from sourcekit-lsp is dead).

Wasn’t it baked into Erlang (well, OTP, but like there’s a distinction), where the model originated?

[1] https://en.wikipedia.org/wiki/History_of_the_Actor_model

It's a nice language but useless if you want to use it as a generic purpose tool.

I think the argument is vastly overstated that Swift is not useful without Apple frameworks. It's similar to C# - you have the language, and then you have Windows APIs. Nobody would argue that C# is "useless" outside of Windows.

Compare Swift on Windows versus .NET (VB, C#, F#) on macOS.

My only point is that that the argument I seem to see often that Swift is not useful outside of macOS/iOS because you don't have SwiftUI/CoreData/whatever is not a good argument.

From the start it seemed to be mostly a product of NIH and the necessity to move away from Objective C while keeping some compatibility. Other platforms tend to allow you much better choices.

If you can find a language that you actually like to work in then why not use it on other platforms?

The dependencies really come down to the Apple frameworks. Ditch those and it's no different than any other general purpose language.

Myriad reasons. If—for whatever reason—someone likes to program in Swift, having high-quality implementations available on various platforms is a win.

> Other platforms tend to allow you much better choices.

This assumes an objective measure of programming language goodness. Whether a language is better than Swift is an opinion. Opinions vary.