36 ms·

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 c

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.

EdwinLarkin 6y ago
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.
- wealthyyy 6y ago
  Jony Ive - Introducing Swift Actors .......
- Grustaf 6y ago
  Then it's lucky that 1 billion people use those OS:es. The wealthiest 1 billion at that...
- skohan 6y ago
  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.
  - pjmlp 6y ago
    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.
    - skohan 6y ago
      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.
      - pjmlp 6y ago
        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.
        frou_dh 6y ago
        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.
machineko 6y ago
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)
Someone 6y ago
“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 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.
drmidnight 6y ago
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.
- anonymouse008 6y ago
  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
  - drmidnight 6y ago
    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.
    - anonymouse008 6y ago
      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...
      - drmidnight 6y ago
        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.
staplung 6y ago
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.
- liuliu 6y ago
  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).
- saagarjha 6y ago
  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.)
rozap 6y ago
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.
- slavapestov 6y ago
  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.
  - nine_k 6y ago
    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.
- infogulch 6y ago
  It seems like the problems of memory ownership and the first simple solution to it -- borrowing -- are fundamental to computing architecture.
- zamalek 6y ago
  > 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.
favorited 6y ago
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.
eternalban 6y ago
> 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.
jayd16 6y ago
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.
jojobas 6y ago
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.
- drmidnight 6y ago
  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.
- kevbin 6y ago
  > 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.
- user-the-name 6y ago
  I have not seen any "much better choice". Swift is one of the best languages I have ever used on any platform.
eyelidlessness 6y ago
> 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?
- Ndymium 6y ago
  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 https://en.wikipedia.org/wiki/History_of_the_Actor_model
  - eyelidlessness 6y ago
    Thanks for the correction, I didn’t know that!
dwaite 6y ago
> 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.
- skohan 6y ago
  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.
dwaite 6y ago
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.

EdwinLarkin 6y ago

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.

wealthyyy 6y ago
Jony Ive - Introducing Swift Actors .......
Grustaf 6y ago
Then it's lucky that 1 billion people use those OS:es. The wealthiest 1 billion at that...
skohan 6y ago
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.
- pjmlp 6y ago
  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.
  - skohan 6y ago
    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.
    - pjmlp 6y ago
      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.
      - frou_dh 6y ago
        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.

machineko 6y ago

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)

Someone 6y ago

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

drmidnight 6y ago

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.

anonymouse008 6y ago
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
- drmidnight 6y ago
  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.
  - anonymouse008 6y ago
    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...
    - drmidnight 6y ago
      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.

staplung 6y ago

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.

liuliu 6y ago
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).
saagarjha 6y ago
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.)

rozap 6y ago

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.

slavapestov 6y ago
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.
- nine_k 6y ago
  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.
infogulch 6y ago
It seems like the problems of memory ownership and the first simple solution to it -- borrowing -- are fundamental to computing architecture.
zamalek 6y ago
> 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.

favorited 6y ago

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.

eternalban 6y ago

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

jayd16 6y ago

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.

jojobas 6y ago

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.

drmidnight 6y ago
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.
kevbin 6y ago
> 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.
user-the-name 6y ago
I have not seen any "much better choice". Swift is one of the best languages I have ever used on any platform.

eyelidlessness 6y ago

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

Ndymium 6y ago
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 https://en.wikipedia.org/wiki/History_of_the_Actor_model
- eyelidlessness 6y ago
  Thanks for the correction, I didn’t know that!

dwaite 6y ago

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

skohan 6y ago
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.

dwaite 6y ago

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.