Hacker News Reader

Comment by the_duke | Hacker News Reader

I love actors, but baking them into the language like this seems like the wrong approach to me.

The language should provide all the necessary abstractions to create an isolated context. Actors can then "just" be a default abstraction provided by the standard library.

Side note: has the Swift cross platform support improved? I was very much looking forward to using Swift as a general purpose language, but Apple didn't seem very interested in making it a true first class cross platform language. I believe IBM also dropped their "Swift for the server" efforts a while ago due to similar concerns.

View on HN

but..the "provide all the necessary abstractions to create an isolated context" is the hard part. It trickles into every part of execution. How do you do isolated contexts without saying any process can be preempted at any moment? How do you isolate things when there's shared memory? To do this right you end up with something like Erlang which makes a lot of sacrifices in order to get there, though you have a fighting chance at dealing with concurrency. And if you bolt it on to the runtime without those pieces in place you end up with something like Akka which has tons of gotchas and ends up being way more confusing than just programming the way the JVM wants you to.

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.

There are also the various static checks that prevent you from accessing actor-isolated state outside the actor, or passing non-Sendable state across actor boundaries. It's not clear how a general language extension mechanism could implement those.

I wonder if Rust can do that, by using data lifetimes incompatible between actors, thus protecting them from being passed around beside sending.

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.

It seems like the problems of memory ownership and the first simple solution to it -- borrowing -- are fundamental to computing architecture.

> How do you isolate things when there's shared memory?

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 have some personal Swift-on-the-server projects deployed in "production" (as in, I use them every day, but I'm the only user) and it works great for me. They're running in Docker containers deployed to Heroku; there might be better ways to deploy it, but I'm not a backend engineer anymore so this is as much as I knew how to do.

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

> The language should provide all the necessary abstractions to create an isolated context. Actors can then "just" be a default abstraction provided by the standard library.

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.

While it takes some work I have successfully run Swift code on the usual suspects (iOS/Mac) as well as Windows, Android and Linux.

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

What are you using for GUI libraries? Or are these mostly accessed from the command line?

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

I've actually been developing my own UI library backed by SDL. It currently uses a DSL-like system similar to SwiftUI. I just spent some late nights working on a "hot-reloading" system, though it only works on Mac/Linux currently.

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

That’s pretty dang cool! I’d love to contribute, if you’re open to it.

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

Could always use some help. It's still in it's infancy right now, very much a PoC to see if it was worth attempting. Once it gets to a good enough state I will make the repo public and let you know. Props to

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.

> What are you using for GUI libraries? Or are these mostly accessed from the command line?

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'd be EXTREMELY interested in knowing more about that. I'm currently developing an app on iOS in swift, in the hope of porting the model layer to other platforms such as android (i don't mind redevelopping the UI).

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 ?

I don't have any write-ups from myself. I was planning on eventually posting something, I have a lot of notes to sort through.

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

I was going to agree but looking at the proposal I don't.

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

> Side note: has the Swift cross platform support improved? I was very much looking forward to using Swift as a general purpose language, but Apple didn't seem very interested in making it a true first class cross platform language. I believe IBM also dropped their "Swift for the server" efforts a while ago due to similar concerns.

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.

I think part of the issue here is that Swift is radically more difficult to compile compared with other languages. At least the last time I checked, which was several years ago, Swift was using a number of slightly-modified versions of libraries compared to what you would get from a standard package manager, so setting up the environment to compile swiftc on an arbitrary Linux distro was no easy task.

“has the Swift cross platform support improved?”

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 "official" Swift LSP was begun in 2018 but there doesn't seem to be much going on there these days. The readme still says "SourceKit-LSP is still in early development, so you may run into rough edges with any of the features." That hasn't changed since the first commit. I can't help but feel that part of the problem is that the language is too complicated.

sourcekit-lsp is actually pretty light-weight implementation as it shares the same sourcekit code with Xcode. VSCode's sourcekit-lsp integration is OK to me.

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

sourcekit-lsp ships with Xcode and has gotten much better. The first release would hang for minutes the moment you imported Foundation; these days it doesn't really hurt performance at all. (I use it in Sublime Text, FWIW.)

In addition to broader abstractions making code more readable and providing developers with less footguns in getting the isolation wrong, it also gives the compiler more opportunity to both default to safety (such as with structured concurrency proposal) and optimize protection and object allocation/retention patterns.

> baking them into the language like this seems like the wrong approach to me

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

The actor model didn't originate in Erlang and AFAIK the developers of Erlang only accidentally implemented it, learning of it later. Wikipedia[1] has history of the actor model from the 70s when Erlang was developed in the 80s.

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

Thanks for the correction, I didn’t know that!

Yeah.I would say the Swift ecosystem is too detached from different platforms than iOS/macOS.

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

Jony Ive - Introducing Swift Actors .......

Then it's lucky that 1 billion people use those OS:es. The wealthiest 1 billion at that...

I think "useless" is way too strong here. Swift doesn't have the same community support outside of Apple platforms as something like Rust and Go, but it's a very capable general purpose language with plenty of platform-agnostic packages available if you look for them. Also the C interop is great, so you have access to the last 50 years of prior art.

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.

With the small detail that nowadays Microsoft is heavily commited to make C# and all the libraries that aren't using Windows specific APIs work with the same level of support across all platforms.

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

Oh I totally agree that C# has a much better cross-platform story than Swift.

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.

Kind of, Swift doesn't exist in isolation, there is competition to think about and unless we are speaking about iOS devs using Linux servers, there is very little business value not to chose some other technology with a stronger cross-platform support.

Yep, it sure seems like professional adoption of Swift on alternative platforms is microscopic outside of people who were already iOS/macOS developers. I don't think this is what they had in mind when Lattner somewhat-seriously talked about the "World Domination Plan" in the earlier days.

Its okish on ubuntu and wsl but windows still lag hard. Worst think is very narrowed libaries working only on apple devices even most cool open source projects are just locked and are looking only on apple ecosystem (dont get me wrong its huge enough to just ignore other ecosystem at the moment sadly)

Why would anyone want Swift on other platforms?

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.

Personally I find it to be a nice blend of language features that I really enjoy. It's expressive and readable.

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.

> Why would anyone want Swift on other platforms?

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.

I have not seen any "much better choice". Swift is one of the best languages I have ever used on any platform.

Reply on news.ycombinator.com