I'm wondering if Swift will hit a sweeter spot than Go (GC, weird takes or delay on things like packaging, generics) and Rust (complexity) for userland systems software.
Outside of Google, using Go tends to be a decision made among a wider range of technical options whereas Swift is very often "not-ObjectiveC." To put it another way, Google created Go as an inhouse alternative for applications where Python, C++, or Java might have been the choice previously. A wide language range: even more considering the range of Java alternatives [Scala, Clojure] on the JVM.
A third factor I see with Go is the Clojure effect. The median Computer Science and Engineering knowledge in its community tends to be high relative to languages chosen based on platform limitations, institutional standards, or "this is the language I know".
I've left out Rust because I don't see it as likely to achieve the scale of adoption of Go or Swift...and saying that I should clarify that I think that platform binding, and a few billion platforms at that, will mean Swift is likely to instantiate more lines of code than Go. Clarifying further, I think Rust's adoption will be a matter of power law distribution not technical shortcomings.
The major enterprise players are not going to let Java (with Oracle stewardship) continue to be the language for the next generation of enterprise platforms and be at Oracle's mercy. Swift is open source and apple enterprise agnostic, easy to see other enterprise players pile on this language. IBM and SAP already on board. If you remember, this is how Java came to dominate enterprise space. Don't be surprised if Google release some sort of compatibility layer for Android.
[Case for bringing Swift on the Server by IBM]
https://www.infoq.com/presentations/swift-server
You are also overestimating Go's influence. It has been five years since the language release, it seems to have settled as a niche language like Clojure and topped out. Unless some major platform adopts it, it will remain a niche area. It certainly hasn't replaced (or even come close to) Python, C++, Java in any sense.
I'm tracking a list of companies that use go: https://quicknotes.io/n/1XB0-Companies%20using%20Go. I stopped adding to it because at this point it's everyone and his mother.
If you go to https://triplebyte.com/ycombinator-startups#q=&page=0&refine..., which is a list of YC companies where you can filter by technology they claim to use, Go is currently ~4.3% (30 startups out of 697).
If you narrow that to just San Francisco, it's 19 out 258 i.e. ~7.4%. I consider SF a leading indicator i.e. other parts of the country and the world will follow that usage growth.
I grant you that it's still far behind Python/Ruby/JavaScript/Java, but those things have exponential growth for a long time and 6 years is early. Those other languages took 10+ years to establish mainstream presence.
Judging by many metrics (number of significant software like Docker or Juju or CockroachDB, number of jobs available, number of Go-related conferences and meetups and their size), Go is easily past "niche language" like Earlang/Haskell and even Clojure and Scala (both of which riding JVM wave) and well on its way to be a peer of Python/Ruby/Java in the next 5-10 years.
1. At Tiobe, it is now at #42. It was language of the year in 2009 and has been slowly moving down
http://www.tiobe.com/tiobe_index
2. At redmonk programming language rankings, it has been hovering around #15 for more than a year
http://redmonk.com/sogrady/2016/02/19/language-rankings-1-16...
http://redmonk.com/sogrady/2015/01/14/language-rankings-1-15...
http://redmonk.com/sogrady/2015/07/01/language-rankings-6-15...
3. Look at jobs on dice.com same number of jobs for golang and clojure. I have been tracking them occasionally and they seem to around the same since last year.
dice.com
Your use of Docker as a datapoint is interesting, while it is written in golang, far more people use it as a sysadmin tool. So why is that a factor for golang usage? That is a general issue though, lot of infrastructure might be written in golang (and should be) but that doesn't mean there will be golang jobs.
As for taking 10+ years to establish mainstream, things move faster nowadays so unless there is a established or rapidly growing platform exclusively for golang, I wouldn't necessary bank on it becoming hot in another 5-10 years just because it has been around.
To the degree IBM and SAP drive enterprise languages I suppose their consultants and sales staff could go whole hog behind Swift as a long term strategy. I'm not sure I see the same strong parallels with Java, I remember Sun playing a role that uniquely leveraged its hardware and software synergy. Redhat played a role there too: there having being at least as much Java as an alternative the Microsoft stack as a dictate of blue suit consultants.
Which makes me wonder if the rationale for Swift's adoption based on open source is significantly more compelling than predicting the adoption of C# on a similar basis or a case that the adoption of the opensource .NET as the replacement for the JVM. I suppose it's that I'm not sure I see IBM and SAP as having orders of magnitude more influence on enterprise or tools selection than Microsoft or that I see top down implementation of consultant recommendations as dominating bottom up decisions by small teams.
Of course, predictions are hard particularly about the future and your mileage may vary.
IBM/SAP swift support looks like riding along with marketing of Apple/OSX/ios. These tech consulting giants will definitely make a top-down push for swift but grabbing developer mindshare might not be so easy. At least IBM swift on server support looks Websphere like play. At one point it was a big business or may be still is but given alternative huge number of developers will prefer alternative.
Unlike Java/Swift which are often introduced or talked by executives at Oracle/Apple, Go is not a corporate mandated language and Google execs do not talk about it like android. Google I/O does not have any Go specific talks. The biggest Go conf is organized by 3rd party.
Go influence need not be over or under emphasized. Hugely influential cloud based projects such as Docker/rkt/etcd/kubernetes/juju and many more are written in Go.
It's probably mostly personal preference, but I prefer Swift's approach to things over Go or Rust. Go in particular does a lot of things that I personally find obnoxious (capitalization of method names indicating exporting instead of using a proper keyword I find particularly egregious, but I also find the := assignment operator annoying as well.)
Swift is the first language I've learned in a while that had way more "OH yeah that's awesome!" than "What?! Why did they do that?"
Well, I think it could have been more cleanly designed if it was able to abandon the burden of Objective-C interoperability. (But Apple can't do this, obviously.) The standard libraries could have also been much cleaner if it didn't rely on NextStep. Also, I don't personally like the dichotomy of value types and reference types, but YMMV.
> it could have been more cleanly designed if it was able to abandon the burden of Objective-C interoperability
You mean this for the language itself and not the (standard) libraries; right?
> The standard libraries could have also been much cleaner if it didn't rely on NextStep.
I agree.
Are you talking about the weirdness where the first argument doesn't require a label? If so, that decision has been made explicit in the last few dev snapshots of 3.0. Basically, if you don't want to require a label when call a function/method then it must be made explicit.
I think Swift will be a Go killer.
Here is a document describing the current state of concurrency in the language: https://github.com/apple/swift/blob/master/docs/proposals/Co...
Not only that, the git feature branch, if it ever existed, doesn't anymore.
At least now we can see stuff coming, I had just finished writing unit tests for my OAuth library when Apple rolled an implementation into iOS.
[0] I'm aware of PromiseKit and co (and read a bunch of their sources), but I didn't feel like I had a good conceptual grasp on their implementation until I could create something similar and understand how it works and how to use it to solve my actual problems. Often I'll bin my own implementation afterward and use an extant library, so this is almost - but not entirely - quite unlike NIH.
Edit:punctuation
It doesn't mean, of course, that Swift or any other language will be a Go killer. It means that most people never write complex concurrent programs to begin with and don't really care about good concurrency models. Sadly or luckily, this applies to people, who design languages as well, so concurrency tend to be a hype-driven mess. The only known exception is Erlang, where the whole language was designed to solve concurrency problems.
The fact that they are implemented using mutexes is, from my admittedly limited, non-concurrency-expert perspective, inexplicable. The simplest use case, an unbuffered channel, should be trivial to implement using CAS. There's a bunch of research on implementing robust queues using CAS.
Then there are the various ugly edge cases: Closing a closed channel is an error (now you have to implement your own refcounting implementation if you want to hand out a single channel to multiple consumers), receive on nil channel blocks (means you can't use nil as a signal to mean "I've closed the channel"), etc.
I really like GCD's style of enqueueing concurrent tasks, which I think is a concurrency model that often works more naturally than channels. A major difference between GCD and goroutines is that you can specify what queue to use. I'm looking forward to see what they come up with for Swift.
[1]: https://github.com/VeniceX/Venice [2]: https://github.com/Zewo/Zewo
Also Swift 4 will contain it as a native part of the language.
The idealistic side of me notes that Swift seems like a far more complex language than Go, so if Swift kills go, it will be bittersweet.
Microsoft also acknowledged that Swift support is the top request for their iOS bridge.
Check out Zewo[1]. They've been doing a lot of great work to make Swift 3.0 on the server work really well. Also, check out VeniceX[2] for concurrency and Open Swift[3] for cross project standards[3].
[1]: https://github.com/Zewo/Zewo/ [2]: https://github.com/VeniceX/Venice [3]: https://github.com/open-swift/docs
http://github.com/qutheory/vapor
Works on linux.
This is such a critical thing with todays interconnected apps that i have no idea how they did not worry about it from the start. Having had the pleasure of dealing with threads, mutexes, dispatchers, execution-contexts and the like there is no way i'd pick up a language that hasn't evolved in that regard, especially on a server. Even Javascript has this figured out with stage-3 async/await.
There are dispatch queues, and the whole purpose of them is to abstract away threads and locks. Using them does not require you to use threads, mutexes or execution contexts.
Yes, it would be better if Swift incorporated language level concurrency, but it isn't a priority because the platform provides a good solution.