The linked post talks about concurrency not being a focus until Swift 6 at the earliest. Personally, I don't want to make a commitment to server-side Swift until after that dust has settled.

I've recently started to investigate web frameworks for swift, and specially the concurrency part. So just to clarify something : current swift web frameworks ( and ios apps for that matter) rely on grand central dispatch, which is a decent library for spawning work on work queues, managed by the OS, and dispatched on OS threads.

This type of model is fine and has worked quite well in the past. It is not event loop like node, nor light threads ( like go), nor actors like erlang, but it does work fine. And since swift is fast, it'll probably work just a fine as your python / ruby / node backend.

What we're looking for for the future of swift is something better / safer than that. But my personnal conclusion is that it shouldn't prevent you from building regular webservice api with this language.

> current swift web frameworks ( and ios apps for that matter) rely on grand central dispatch, which is a decent library for spawning work on work queues, managed by the OS, and dispatched on OS threads.

Imho that's just the description of event loop(s). There's a central queue, to which you post work (e.g. in the form of function objects or closures), which will get dequeued and executed in a serialized fashion. The thread look like while ((func = dequeue()) != null) { func(); }. That's the event loop.

The difference to node is that you have multiple of these event loops, which are referred to by queue name. In javascript there's only one single implicit loop. If we look at javascript which webworkers we also get multiple loops and queues (one in each worker). However those are more strongly isolated (no shared memory) than eventloops in multithreaded environments.

How much work is expected from the developer point of view? I'd love to have an alternative to Go, but no concurrency for me kills Swift right of the gate for server stuff.

At the moment, it's mostly the framework's job. You write your handler and call the libs for interacting with i/o.

Posting a job ( aka function call) on a queue for async programming is also very very easy.

There's nothing like coroutines or channels though. So you're back to mutex and OS thread constraints in terms of the number of spawnable threads.

Thanks for that explanation... so in short is not ready yet. Go's channels is what makes it seamless. So few choices for solid concurrency today.

Agreed - I'd love to see it more widely adopted. It's a great language.

Once both ABI stability and a native concurrency model have been implemented, Swift would be in an even stronger position to take on these languages. I'm not sure that's the sole reason a stronger push hasn't been made yet, but waiting another few years to go after this goal would in some ways be tactful.

It's not just about a framework. Some marketing/evangelism is needed. Those factors were major contributors to the rise of Go.

And the Swift community itself needs to work on making it officially available on more platforms. Officially, the only non-Apple platform that is supported is Ubuntu -- not Linux, Ubuntu. It runs on other distributions, but having “official” support for more platforms would be a big step towards acceptability. Most people I've talked to still consider Swift on Linux an experiment. Even C#/.Net Core seem to be more popular on Linux.

Having Windows support would make the language more acceptable by cross platform developers -- leading to more high quality libraries being written.

With a name like 'vapor', I thought this was some sort of joke. But this looks like fun! https://vapor.codes. An example from that page:

  import Vapor
  
  let drop = try Droplet()
  
  drop.get("hello") { req in
      return "Hello, world."
  }
  
  try drop.run()

Hey, I'm using Vapor (in production). It's really great to work with and moving fast - feels like the early days of rails. There's a real technical advantage to having the brevity of swift (like ruby) but with the type checking of the compiler. I actually migrated this app from Node.js and it's faster and easier in almost every way (notably lack of 3rd party libraries).

I've been sort of going back and forth on what I want to work on as a side project, but server side Swift stuff is definitely an option. I love the language, and think it could end up being a really strong competitor in that space. At the moment it's just barely viable though, sadly.

This cliche statement feels trite for such a large project. I'd understand it for a 1000 line JS library, but it makes no sense for a complex language ecosystem that requires multiple full time engineers to maintain.

It isn't my intention to sound "trite". I've personally contributed a little bit to Swift. You don't have to be a compiler genius to help out - you can contribute to Swift Foundation which is almost entirely Swift code and would directly improve cross-platform support.

I would also note that saying "I wish more effort were being made" is a bit entitled when you're talking about an open source project. No one working on any open source project owes you anything. If you want the project to get better then find a way to contribute.

> I would also note that saying "I wish more effort were being made" is a bit entitled when you're talking about an open source project. No one working on any open source project owes you anything.

no, "i wish" just means "i wish". it doesn't imply anything like "being owed".

being "open source" doesn't establish carte blanche to oblige everyone to labor on the project if they dared to have a thought or opinion.

> If you want the project to get better then find a way to contribute.

there are thousands of projects i'd like to see get better. not everyone has the time, ability, desire or capacity to implement everything they've ever wished for. this is just silly.

> I am talking about "official" support here

You can take a look at what IBM has been doing in this space, but in general I'm not sure what you are asking for. Do you expect Apple to release a fully-baked Windows port?

It's a free project that is open-source. Cross-platform support will come from contributions by individual developers, testers, and documentation writers, or companies who find some strategic value in supporting it.

Sitting back and saying "I wish" seems a bit entitled, no? I'm not being glib, I really am saying if you want to see better Swift support on platform X then start contributing. Swift Foundation needs help filling out implementations on Linux and Windows. For the more adventurous you can contribute directly to the standard library or compiler.

Since when did wishing for something mean someone is entitled to something?

“I wish it would stop raining.”

“I wish they'd launch it soon.”

Do any of these statements mean the speaker is entitled to something? Since when did wishing for something become a bad thing?

I am not expecting Apple to release anything. I am hoping for swift.org to one day proclaim that the toolchain and the libraries are available on Windows and other platforms. What I am expecting Apple to do is get behind its own language. I mentioned in another post in this thread -- it is not just about technical work. A lot of it has to do with marketing/evangalism. While individual contributors can help, it takes the backing of large company to get something adopted at a large scale. Why do you think Go succeeded while languages like Nim, D etc are not being adopted as well? What I expect from Apple is to spare a couple of people for the purpose of giving talks, writing blogs etc in addition to working on Swift -- something like what Rob Pike et al have been doing for Go. From what I understand, Apple writes a lot of their backend stuff in Java. Perhaps they could start investing in Swift on server side and open source some of the frameworks/libraries they come up with?

> I really am saying if you want to see better Swift support on platform X then start contributing.

I want to get Swift adopted at my workplace for the next project we are working on. I should tell the management I'll start working on it as soon as I get Swift ported to the platform I use. It would go down really well.

What makes you assume I am not contributing in whatever way I can?

> You can take a look at what IBM has been doing in this space, but in general I'm not sure what you are asking for.

IBM has done some good work, alright. But they are the only ones. A lot more work is required If Sipwift were to become a mainstream language.

I already use Rust for some stuff, but Rust and Swift don't compete in the same domain -- despite some overlap. Rust is more for Systems Programming whereas Swift is geared towards Application Programming. Of course, you could use them in each other's domains, but there will be challenges.

Are all of your comments about Rust?

There's a reason a meme exists about Rust afficionados on HN.