6 ms·

It looks like a really well thought out language, and the willingness to break some things that looked like C holdovers in 3.0 for future clarity is also intere

by kev009 10y ago

It looks like a really well thought out language, and the willingness to break some things that looked like C holdovers in 3.0 for future clarity is also interesting. 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.

Scarbutt 10y ago
I'm wondering if Swift will hit a sweeter spot than Go I think Swift will be a Go killer.
- spriggan3 10y ago
  How does Swift handles concurrency ? does it have CSP with channels, and a select statement ? because if it doesn't it's not going to kill anything.
  - chrisamanse 10y ago
    Swift has Grand Central Dispatch (GCD) for running concurrent code
    - wlesieutre 10y ago
      (But only on OS X and iOS)
      - chrisamanse 10y ago
        Yes, currently. But in the link, it states that "For Linux, Swift 3 will also be the first release to contain the Swift Core Libraries." And GCD (or libdispatch) is part of the Swift Core Libraries :)
      - lobster_johnson 10y ago
        Isn't libdispatch fully implemented on Linux and *BSD?
  - stepanhruda 10y ago
    It doesn't right now, you are dependent on grand central dispatch. Adding concurrency features to the language will be a focus in Swift 4. Here is a document describing the current state of concurrency in the language: https://github.com/apple/swift/blob/master/docs/proposals/Concurrency.rst https://github.com/apple/swift/blob/master/docs/proposals/Co...
    - austinz 10y ago
      To be clear, that document contains brainstorming by some core Swift team developers. It's neither implemented in Swift nor officially accepted as a guideline for future development.
      - stevetrewick 10y ago
        "The implementations of the thread-safety layer, the thread verifier, and programs that use the three concurrency libraries are available in the concurrency git branch."
        austinz 10y ago
        "This is a proposal and not a plan of record." Not only that, the git feature branch, if it ever existed, doesn't anymore.
      - stepanhruda 10y ago
        Oops, thanks, I should've been clearer.
    - stevetrewick 10y ago
      Thanks, I'm going to have to take a long hard look at that and the repo. I've just spent a couple of weeks abstracting over async in Swift [0] and where I ended up looks a lot like that - to the point where some of the primitives have identical type sigs (mainly because the patterns used here are not novel - promise/future, async/await, etc). Be great to see this as a core language feature! 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
  - zzzcpan 10y ago
    CSP with channels in Go is just a fancy locking mechanism, something that Rob Pike and co wanted to experiment with, and a marketing feature, of course. Nothing more. They don't really work that well. Their limitations, verbosity and quite complex implicit behavior makes them hard to use for high level things. I think mutexes are more widespread and more encouraged already in Go, than channels. So, idiomatically and in the standard library Go doesn't handle concurrency well at all, on the opposite, it has the worst kind of concurrency - shared memory multithreading. And anything can be better than that. Even a wrapper around synchronous APIs ;) 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.
    - lobster_johnson 10y ago
      I agree. I've found Go channels to be disappointing in practice. There's lots of PR but little criticism of something so key. 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.
      - danappelxx 10y ago
        I think that Go's biggest mistake was making goroutines multithreaded. Libmill takes a much safer approach by making everything still run on one thread (and by taking advantage of libmill, Venice brings a similar scheme but with the added safety).
  - donut2d 10y ago
    Check out VeniceX[1]. It provides Go-style concurrency. The same group[2] that is working on this is also working on a GCD based concurrency library but the name escapes me at this time. [1]: https://github.com/VeniceX/Venice https://github.com/VeniceX/Venice [2]: https://github.com/Zewo/Zewo https://github.com/Zewo/Zewo
    - danappelxx 10y ago
      Yeah, it's very cool stuff! Would just like to add that VeniceX is actually single-threaded, so it's more safe than Go's. It's similar to libuv in that way, but since it doesn't use callbacks it's much nicer.
  - jaegerpicker 10y ago
    Built-in, it's threading and Grand Central Dispatch. However there are a shit of good quality libraries available for swift. PromiseKit being the one I'm most familiar with. There are others that offer CSP and channels. Also Swift 4 will contain it as a native part of the language.
- kartickv 10y ago
  The practical side of me welcomes a language that can be used both on the client and server, and on both Apple and non-Apple platforms. 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.
hellofunk 10y ago
I'm curious how Swift is getting adopted on Linux and what success folks are having in writing Linux command-line apps or other apps?
- pjmlp 10y ago
  IBM is betting on it as a programming language for enterprise applications. Expect a Swift EE coming from them. Microsoft also acknowledged that Swift support is the top request for their iOS bridge.
  - codeOfRobin 10y ago
    They already built a flask type server side framework : https://github.com/IBM-Swift/Kitura/ https://github.com/IBM-Swift/Kitura/
- deleted 10y ago
  [deleted]
- donut2d 10y ago
  I've built a few simple apps running on Linux that have worked great. 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/ https://github.com/Zewo/Zewo/ [2]: https://github.com/VeniceX/Venice https://github.com/VeniceX/Venice [3]: https://github.com/open-swift/docs https://github.com/open-swift/docs
- tannernelson 10y ago
  2nd most starred web framework for Swift: http://github.com/qutheory/vapor http://github.com/qutheory/vapor Works on linux.
yokohummer7 10y ago
> It looks like a really well thought out language 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.
- cies 10y ago
  You say > 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.
  - TillE 10y ago
    There are at least a few aspects of the language (eg, the special case for the first argument passed to a method) which would be completely bizarre decisions if not for the Objective-C compatibility requirements. Though I think they're tweaking that a bit.
    - donut2d 10y ago
      > special case for the first argument passed to a method 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.
ebbv 10y ago
I've written a fun little OS X/iOS game in Swift 2.0 and found the language incredibly satisfying. Swift 3.0 seems to bring a ton of improvements including some of the bugbears I encountered during that first project. 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?"
- AsyncAwait 10y ago
  I actually find Swift and Rust to be pretty similar in how they approach things from the end-user perspective, (I think of Swift as application-level Rust), it's just that Rust targets a different market which involves quite a bit more complexity in its domain, which is reflected in the language where needed.
brudgers 10y ago
My intuition is the Swift ecosystem will struggle against conflation with particular platforms, i.e. iOS and OSX. This struggle is common among languages: C# with Windows and JavaScript with the browser come to mind. Historically, C faced similar association with the Unix platform. Language platform conflation makes it difficult to parse information from blogs, books, and StackOverflow: the worst offender of course is Javascript where the presentation may be based on jQuery or NPM dependencies even for things practical in vanilla Javascript [or rather ECMAscript]. 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.
- npalli 10y ago
  Apart from swift on iOS/mobile which is gigantic, you are underestimating the push for Swift by enterprise players (IBM,SAP..). The next big frontier for enterprise applications is cloud, IoT and of course mobile (buzzwords or not). Java is increasingly being used by Oracle to extract revenue, there is no guarantee they will not change their mind and start charging fees from future versions as their other businesses (database, apps etc.) shrink. 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 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.
mlsarecmg 10y ago
I don't know - this is a language that can't easily handle concurrency. Instead you mess around with dispatchers. And then you're dealing with thread-unsafe structures, objects, arrays, etc. 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.
- donut2d 10y ago
  I don't have much experience, but I think the VeniceX packages from Zewo answer the concurrency issues quite well. https://github.com/VeniceX/Venice https://github.com/VeniceX/Venice
  - proyb2 10y ago
    and Vapor web framework include Venice.
- zepto 10y ago
  This is inaccurate. There is no term in either Swift, or the Objective-C runtime named 'dispatcher', which makes it seem like you are unfamiliar with the platform. 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.
- jaegerpicker 10y ago
  As others have said this is misleading and inaccurate. GCD, which will be cross platform as of swift 3, is very pleasant and robust to work with and abstracts the threads, mutexs, and dispatchers away from the developer. PromiseKit and Venice are third party libs that also provide other better concurrency patterns.

by kev009 10y ago

Scarbutt 10y ago

I'm wondering if Swift will hit a sweeter spot than Go I think Swift will be a Go killer.

spriggan3 10y ago
How does Swift handles concurrency ? does it have CSP with channels, and a select statement ? because if it doesn't it's not going to kill anything.
- chrisamanse 10y ago
  Swift has Grand Central Dispatch (GCD) for running concurrent code
  - wlesieutre 10y ago
    (But only on OS X and iOS)
    - chrisamanse 10y ago
      Yes, currently. But in the link, it states that "For Linux, Swift 3 will also be the first release to contain the Swift Core Libraries." And GCD (or libdispatch) is part of the Swift Core Libraries :)
    - lobster_johnson 10y ago
      Isn't libdispatch fully implemented on Linux and *BSD?
- stepanhruda 10y ago
  It doesn't right now, you are dependent on grand central dispatch. Adding concurrency features to the language will be a focus in Swift 4. Here is a document describing the current state of concurrency in the language: https://github.com/apple/swift/blob/master/docs/proposals/Concurrency.rst https://github.com/apple/swift/blob/master/docs/proposals/Co...
  - austinz 10y ago
    To be clear, that document contains brainstorming by some core Swift team developers. It's neither implemented in Swift nor officially accepted as a guideline for future development.
    - stevetrewick 10y ago
      "The implementations of the thread-safety layer, the thread verifier, and programs that use the three concurrency libraries are available in the concurrency git branch."
      - austinz 10y ago
        "This is a proposal and not a plan of record." Not only that, the git feature branch, if it ever existed, doesn't anymore.
    - stepanhruda 10y ago
      Oops, thanks, I should've been clearer.
  - stevetrewick 10y ago
    Thanks, I'm going to have to take a long hard look at that and the repo. I've just spent a couple of weeks abstracting over async in Swift [0] and where I ended up looks a lot like that - to the point where some of the primitives have identical type sigs (mainly because the patterns used here are not novel - promise/future, async/await, etc). Be great to see this as a core language feature! 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
- zzzcpan 10y ago
  CSP with channels in Go is just a fancy locking mechanism, something that Rob Pike and co wanted to experiment with, and a marketing feature, of course. Nothing more. They don't really work that well. Their limitations, verbosity and quite complex implicit behavior makes them hard to use for high level things. I think mutexes are more widespread and more encouraged already in Go, than channels. So, idiomatically and in the standard library Go doesn't handle concurrency well at all, on the opposite, it has the worst kind of concurrency - shared memory multithreading. And anything can be better than that. Even a wrapper around synchronous APIs ;) 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.
  - lobster_johnson 10y ago
    I agree. I've found Go channels to be disappointing in practice. There's lots of PR but little criticism of something so key. 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.
    - danappelxx 10y ago
      I think that Go's biggest mistake was making goroutines multithreaded. Libmill takes a much safer approach by making everything still run on one thread (and by taking advantage of libmill, Venice brings a similar scheme but with the added safety).
- donut2d 10y ago
  Check out VeniceX[1]. It provides Go-style concurrency. The same group[2] that is working on this is also working on a GCD based concurrency library but the name escapes me at this time. [1]: https://github.com/VeniceX/Venice https://github.com/VeniceX/Venice [2]: https://github.com/Zewo/Zewo https://github.com/Zewo/Zewo
  - danappelxx 10y ago
    Yeah, it's very cool stuff! Would just like to add that VeniceX is actually single-threaded, so it's more safe than Go's. It's similar to libuv in that way, but since it doesn't use callbacks it's much nicer.
- jaegerpicker 10y ago
  Built-in, it's threading and Grand Central Dispatch. However there are a shit of good quality libraries available for swift. PromiseKit being the one I'm most familiar with. There are others that offer CSP and channels. Also Swift 4 will contain it as a native part of the language.
kartickv 10y ago
The practical side of me welcomes a language that can be used both on the client and server, and on both Apple and non-Apple platforms. 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.

hellofunk 10y ago

I'm curious how Swift is getting adopted on Linux and what success folks are having in writing Linux command-line apps or other apps?

pjmlp 10y ago
IBM is betting on it as a programming language for enterprise applications. Expect a Swift EE coming from them. Microsoft also acknowledged that Swift support is the top request for their iOS bridge.
- codeOfRobin 10y ago
  They already built a flask type server side framework : https://github.com/IBM-Swift/Kitura/ https://github.com/IBM-Swift/Kitura/
deleted 10y ago
[deleted]
donut2d 10y ago
I've built a few simple apps running on Linux that have worked great. 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/ https://github.com/Zewo/Zewo/ [2]: https://github.com/VeniceX/Venice https://github.com/VeniceX/Venice [3]: https://github.com/open-swift/docs https://github.com/open-swift/docs
tannernelson 10y ago
2nd most starred web framework for Swift: http://github.com/qutheory/vapor http://github.com/qutheory/vapor Works on linux.

yokohummer7 10y ago

> It looks like a really well thought out language 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.

cies 10y ago
You say > 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.
- TillE 10y ago
  There are at least a few aspects of the language (eg, the special case for the first argument passed to a method) which would be completely bizarre decisions if not for the Objective-C compatibility requirements. Though I think they're tweaking that a bit.
  - donut2d 10y ago
    > special case for the first argument passed to a method 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.

ebbv 10y ago

I've written a fun little OS X/iOS game in Swift 2.0 and found the language incredibly satisfying. Swift 3.0 seems to bring a ton of improvements including some of the bugbears I encountered during that first project. 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?"

AsyncAwait 10y ago
I actually find Swift and Rust to be pretty similar in how they approach things from the end-user perspective, (I think of Swift as application-level Rust), it's just that Rust targets a different market which involves quite a bit more complexity in its domain, which is reflected in the language where needed.

brudgers 10y ago

My intuition is the Swift ecosystem will struggle against conflation with particular platforms, i.e. iOS and OSX. This struggle is common among languages: C# with Windows and JavaScript with the browser come to mind. Historically, C faced similar association with the Unix platform. Language platform conflation makes it difficult to parse information from blogs, books, and StackOverflow: the worst offender of course is Javascript where the presentation may be based on jQuery or NPM dependencies even for things practical in vanilla Javascript [or rather ECMAscript]. 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.

npalli 10y ago
Apart from swift on iOS/mobile which is gigantic, you are underestimating the push for Swift by enterprise players (IBM,SAP..). The next big frontier for enterprise applications is cloud, IoT and of course mobile (buzzwords or not). Java is increasingly being used by Oracle to extract revenue, there is no guarantee they will not change their mind and start charging fees from future versions as their other businesses (database, apps etc.) shrink. 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 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.

mlsarecmg 10y ago

I don't know - this is a language that can't easily handle concurrency. Instead you mess around with dispatchers. And then you're dealing with thread-unsafe structures, objects, arrays, etc. 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.

donut2d 10y ago
I don't have much experience, but I think the VeniceX packages from Zewo answer the concurrency issues quite well. https://github.com/VeniceX/Venice https://github.com/VeniceX/Venice
- proyb2 10y ago
  and Vapor web framework include Venice.
zepto 10y ago
This is inaccurate. There is no term in either Swift, or the Objective-C runtime named 'dispatcher', which makes it seem like you are unfamiliar with the platform. 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.
jaegerpicker 10y ago
As others have said this is misleading and inaccurate. GCD, which will be cross platform as of swift 3, is very pleasant and robust to work with and abstracts the threads, mutexs, and dispatchers away from the developer. PromiseKit and Venice are third party libs that also provide other better concurrency patterns.