Swift was designed to do everything - one language to rule them all. To quote from Apple's Swift page: "Swift is a successor to the C and Objective-C languages."

My guess would be that the webcrawler was started before Swift was allowed to escape from the Developer Tools enclave.

Doing everything is not the same as doing everything well.

Surely you agree that languages designed with one purpose in mind (a la Go and networking/server development) can reasonably do better at that purpose than an explicitly general-purpose language?

Just to be clear, I prefer Swift to Go in general. However, between the two, I would personally prefer to use Go for the development of network utilities.

I'm not saying it's a good idea, I was just responding to your assertion that Swift was designed only for writing user-facing applications. That is not the case - this is Apple's planned replacement for low-level code as well as apps. It is this design requirement which drove Swift's abandoning Objective-C's dynamic bindings etc.

> Surely you agree that languages designed with one purpose in mind (a la Go and networking/server development) can reasonably do better at that purpose than an explicitly general-purpose language?

I don't think that's a given. Just because a language is more special-purpose, doesn't mean that a more general purpose language can do the same things as seamlessly as in the other language (maybe they would have to define an embedded DSL, but that might be simple). Maybe the special-purpose language decided to commit to certain things in its domain - like certain concurrency features - and make it "first class", since that was its intended domain. But then maybe that concurrency feature wasn't that useful and a more general purpose language - which had to keep its options open since it was general purpose - could express other alternative features more easily.

Can you explain what that means? Which language features is Swift missing?

It's a perfectly reasonable general purpose language. However, it doesn't have a low-overhead green thread mechanism, and the standard library has no particular emphasis on network tools.

Even as an outspoken critic of go, I recognize that it has quite a strong networking toolset.

Swift is a general purpose language. I fail to see what it lacks.

So are Python and Ruby, but most people will agree that those are unsuitable for certain types of highly concurrent and performance sensitive network applications.

Using the right language for a particular domain can save you a lot of headache. Go is open source and a relatively proven choice, compared to Swift.

Python and Ruby aren't a suitable comparison, because they lack AOT compilers to native code as part of their canonical implementation, which is not the case for Swift.

As for access to the language implementation, Swift is Apple's creation.

The argument you made was that "Swift is a general purpose language.". Since both Python and Ruby are generally considered general purpose languages, they _are_ suitable for comparison to Swift in the exact sense that you chose to describe Swift.

I'm not trying to tell you that you are wrong. I'm just saying that your reasoning is flawed, and your arguments don't really support any particular conclusion. "Swift is a general purpose language." - OK? "I fail to see what it lacks." - Noted.

Let's only compare with native, canonically AOT compiled, general purpose languages, though. All of a sudden there are a lot of questions. Why didn't they write it in C? Why didn't they write it in Delphi? Fortran? Forth? The answer is of course that beyond being a native, canonically AOT compiled, general purpose language, different languages have different constructs and models of particular patterns that make them more or less useful for different kinds of tasks and development models.

Apple seemingly recognized that Swift was less useful than Go for the particular task at hand, and while we can't really know for sure if this was a matter of performance, development speed, personal preference of the developers etc, we can probably assume that the choice was based on taking several such quality dimensions into consideration.

I would expect Swift to have comparable performance to Go since it's a C like compiled language. Where it doesn't, Apple should probably dog-food it so they can find any deficiencies.

Network latency and distribution notwithstanding, one of Go's core goals is low-overhead concurrency. I'm not sure how GCD compares in Swift because I haven't spent a ton of time in it yet, but that could be a point of contention, particularly in a web scraper.