12 ms·

Introducing Swift Service Lifecycle

qalmakka 6y ago
Maybe if swift had something like rustup, people would consider it more when developing for Linux. Also other popular languages like Rust and Go work well even on weird architectures and little known operating systems, while Swift does not even properly support Windows or FreeBSD. It always felt to me that Apple doesn't really care that much about making the language popular outside of the Darwin family. Swift is not even in the default repositories of most distributions, for instance.
- skohan 6y ago
  It's worth noting that wider support (including official Windows support) is a stated goal of the next language version: https://swift.org/blog/5-3-release-process/ https://swift.org/blog/5-3-release-process/
  - pjmlp 6y ago
    That is just a tiny step, when the majority of available libraries only have the Apple eco-system in mind. Swift is a very nice language, but one is better served with it if their main market is Apple platforms. Just like .NET Core, regardless of how much commitment Microsoft is putting into it, remains a subset of the .NET community at large, the so called dark matter developers.
    - turbinerneiter 6y ago
      The nature of Open Source means that any interested party contributes to the project the features it is interested in. Apple is interested in running Swift on OSX and iOS. Goolge is interested in running Swift on Linux servers to do to Machine Learning. Windows support has to come from whomever is interested in it. Neither Apple nor Google have a big interest in that. Same with other stuff. I, for example, am interested in using Swift with GTK+. I don't expect Apple or Google to work on that.
      - pjmlp 6y ago
        Google's interest on Swift isn't that much reflected outside when Tensorflow 2020 conference did not spend 1 second on Swift, not even to write a tiny status update blog post. Yet they had enough C++, Android, Python and JavaScript to talk about. C++, Python, Julia, R own Machine Learning. I don't miss Swift on Windows, the JVM and .NET stacks offer plenty of choice, including better GPGPU support across multiple OSes.
        AlphaSite 6y ago
        I think it died the moment Chris Latterner left.
      - coldtea 6y ago
        >The nature of Open Source means that any interested party contributes to the project the features it is interested in Yes, but the reality of Open Source is that unless money are paid, it often goes nowhere for big projects (that need lots of work to port/create libs/etc).
        turbinerneiter 6y ago
        How is that a _but_ to my comment? The interested party is the one who pays for the development of the feature they want, mostly by paying a developer to do it.
        Redoubts 6y ago
        The "but" is that a million developers somewhat interested in the language but for the lack of platform support wouldn't sum to a relevant interest. I think that's a shame, but still truth.
        coldtea 6y ago
        >How is that a _but_ to my comment? You wrote: "The nature of Open Source means that any interested party contributes to the project the features it is interested in" And my comment essentially means: Yeah, BUT this "nature of Open Source" is just a mere potentiality. The fact that FOSS allows "any interested party can contribute" means nothing if there's no interested party with deep pockets (or time/skill to contribute).
    - skohan 6y ago
      Why is the relative size of the apple-oriented community relevant? I'm not saying it's the current status quo, but if the server-side Swift community reaches a critical mass where it's easy to get support, and there are plenty of libraries available, it doesn't matter one bit if the iPhone developer community is still 10x larger. This would be like saying coconut is unsuitable for use in pina colladas because it's much more prevalent as an ingredient in curry.
      - pjmlp 6y ago
        Because a language is not an island and the competition is tough. Anyone betting their money on Server side Swift better have a solid story to sell to upper management, why they did not went with Go, Java, .NET, C++20, Rust, OCaml, ..... Right now the only solid story is for Apple shops to share their client code with the server.
        skohan 6y ago
        ROR made Ruby into a mainstream language from a single success story and a usable tool. Swift already has a much bigger developer base, there's no reason it couldn't succeed in other markets as well given the right catalyst.
        mantap 6y ago
        Apple has a bigger developer base but they are captive users. I'm not saying swift isn't good, but nobody actually chooses to use it. They use because it is the language for making iDevice apps. The problem is that if people are only using a language because they have to, then they are not as incentivised to create the open source projects that swift needs. Ruby had a large number of very enthusiastic users, that's what made the difference.
        skohan 6y ago
        I think you're describing a chicken-and-egg problem, and you're overstating the extent to which a gap exists in terms of library support. Swift has a very capable standard library, a high-quality, officially supported networking library, and fantastic C and Python interop which can fill a lot of the gaps to the extent they exist. Even in its current state, I can imagine Swift being productive in something like server-less development, where it would offer a nice strongly typed alternative to scripting languages which currently dominate the space. Swift has a lot of intrinsic features which would make it nice to use for server-side development, and I'm sure it would find plenty of users if there were a strong success story to point to. Given the number of users, I'm not convinced the absolute number of Ruby users in 2009 was larger than the number of "swift enthusiasts" today.
  - ceo_tim_crook 6y ago
    swift always feels years behind, I'm not convinced they will ever get the basics right outside of ever shrinking apple land
- saagarjha 6y ago
  > Also other popular languages like Rust and Go work well even on weird architectures and little known operating systems As someone working on porting “everything” to a decidedly not weird architecture and a very well known operating system, I chuckle a bit because neither language works right now. Not even their dependencies work. It’ll be a while before they will be supported. (Swift works perfectly, but it would be unfair to compare it because it had a strong investment made in it to work…)
  - hellofunk 6y ago
    > decidedly not weird architecture and a very well known operating system Can you say which ones? It's hard to place your comment without details.
    - tomstuart 6y ago
      The context implies it’s macOS on Apple silicon.
      - qalmakka 6y ago
        In that case the comment makes no sense - the details of AArch64-based Macs have been made public just a few weeks ago. It takes a while to do port and test for a new platform, even if iOS was already supported.
        jpace121 6y ago
        It’s implied the OP isn’t considered part of the “public” for this issue.
        saagarjha 6y ago
        No, I learned of it the same time you did, although I had a fairly good idea about when this was coming for a few years ;) And while I have a bit of additional information now, it's nothing that would really be useful for porting.
- jfkebwjsbx 6y ago
  Swift, Rust nor Go provide support for exotic targets. If you want code to work in actually "weird architectures and little known operating systems", then your only option is C (or weird dialects of "C" in some cases). At least that was how things were around >10 years ago, not sure about the current state of things. Anyone can chime in? Do embedded vendors etc. provide proper forks of newish, modern compilers?
  - pjmlp 6y ago
    C++, Oberon, Ada, Pascal, Basic Java, are also options, depending on what exotic hardware you mean. https://www.mikroe.com/compilers https://www.mikroe.com/compilers https://www.astrobe.com/default.htm https://www.astrobe.com/default.htm https://www.ptc.com/en/products/developer-tools/apexada https://www.ptc.com/en/products/developer-tools/apexada https://www.ghs.com/products/ada_optimizing_compilers.html https://www.ghs.com/products/ada_optimizing_compilers.html https://www.aicas.com/wp/ https://www.aicas.com/wp/ https://www.microej.com/product/vee/ https://www.microej.com/product/vee/
  - qalmakka 6y ago
    Even excluding extremely exotic targets, the list of platforms supported by Rust and Go is vastly larger than Swift. For instance, there's no official support on FreeBSD, and FreeBSD 1. uses LLVM for everything 2. has a userland really similar to Darwin, so there are very few excuses to not allocate even a small amount of man power to port it. If you add third-party ports and implementations, the list of platforms supported by Go and Rust increases exponentially; see for instance Tiny Go and the ongoing port of Rust to the Xtensa-based ESP32. > Anyone can chime in? I work in embedded and as far as my experience goes nowadays unless you go on extremely limited environments, the embedded chips I mostly see or develop for are either ARM (v7, like stuff from Nordic or the STM), or ESP32 (Xtensa). Every once in a while I have to work on some older projects which were based on Atmel or PIC, or very very very rarely MIPS. It's certainly not like it was before; nowadays you can buy chips like the ESP32-WROVER which have relatively lots of RAM and storage for an absurdly cheap price. They run pretty well even if you opt for using C++17 and complex libraries.
- jamil7 6y ago
  I like Swift a lot but Apple seems to be focusing on cross-platform within their ecosystem only, the fact that it runs elsewhere almost feels like a side effect. If your goal is sharing some cross platform code then I feel like you're better served by Rust / Go / Kotlin Native / C++ as these languages are making / have made and effort in that space.
skohan 6y ago
That's a neat idea, thanks to named parameters and an expressive type system, I can see how Swift could be a good fit for tasks typically handled by config files. Also having a turing complete language available to customize behavior could have some interesting use cases.
RcouF1uZ4gsC 6y ago
>Shutdown sequences include freeing up resources that hold on to file descriptors or other system resources that may leak if not cleared correctly. Startup workflow is important, and it is nice to have an abstraction that makes it easier. I am less convinced that shutdown workflow is important, and may be more trouble than it is worth. On modern operating systems, the OS will handle process shutdown and clean up system resources such as file descriptors etc. In addition, with things like the OOM killer, etc, the process may not have a chance to actually clean up. Trying to engineer graceful shutdowns is extra code with subtle edge cases (like circular dependencies), and generally, less well tested and exercised. Finally, the operating system needs to be robust against leaking resources due to processes crashing, anyway. So on the balance, I think it is worthwhile to do a startup workflow and engineer your service so that you can always crash safely without messing up your system or leaking resources.
- liuliu 6y ago
  Agree in principle (you shouldn't rely on shutdown sequence to do correct thing). It is still nice to have a grace shutdown option. For some cases, it is just a little bit "nicer". Imagining you have one service instance need to shutdown for either migration or maintaince, it is just a bit nicer to report to your service discovery manager that this instance will go offline. While service discovery manager will eventually figure it out by its own through heartbeat monitoring, proactively notifying the service discovery manager would reduce a little bit on the failed retries etc.
- jfkebwjsbx 6y ago
  There are resources that won't be cleanly cleared on crash. Others won't be removed at all. There is also the debugging analysis and the monitoring sides of it too. Thus avoiding shutdown logic is sloppy engineering to say the least. Same for ignoring the need to design the system to avoid crashes to begin with, including OOM ones. This has nothing to do with ensuring your system is OK on crash, which is another side of robustness.
  - hamandcheese 6y ago
    If there are resources that won’t be cleared on crash, then how can you say a system is OK to crash?
_pmf_ 6y ago
That's the kind of language integrated cross-cutting DI that I always wanted.
pornel 6y ago
It's interesting that this gets an official blessing. It isn't something integrated with the Swift language, just a bit of code that could be a regular package.
- jmull 6y ago
  I think they are trying to establish a common approach to foundational concerns. That makes sense to me, though I see the risk. There's a big benefit to the community as a whole if standard concerns are handled in a common: developers will become experienced with them and understand them in deep ways. Tooling can target them. Documentation and other learning materials can become wide and deep. The risk is that potentially better approaches have a very high hurdle to overcome the "official blessing" to become more than a niche option. That's good and fine for alternatives that are only incrementally better or better in some ways worse in others. But sometimes a significantly lacking "official" approach holds back an overwhelmingly superior non-official approach. Hopefully the Swift Server Work Group will keep that from happening or at least not for too long.
ralmidani 6y ago
Swift as a language/ecosystem does seem to check all the boxes in contrast to other modern, mainstream languages; it looks, to me at least, like a much more ergonomic alternative for building applications compared to Rust and Go. It's considerably faster and more type-safe than Python and Ruby. And it has a drama- and shenanigans-free licensing model that I personally am much more comfortable with as opposed to the shitshow that is Java (and, to a lesser extent, .Net). I've been reading lots of Swift docs/articles, and made quite a few book purchases from raywenderlich.com and hackingwithswift.com. My "gut feeling" tells me making the investments to become proficient in Swift, and eventually mastering it, will pay off big time. As a web-focused developer, I must admit I found Objective-C and UIKit intimidating, but with SwiftUI, Apple seems to be lowering barriers to entry; if you know something like Ember, Vue, React, or Angular, you won't struggle too much trying to grok SwiftUI. With Vapor becoming a mature framework, and Apple giving its official blessing for the development of server-side Swift libraries and tools, it does seem like we may soon reach critical mass on the server, and there is a lot of appeal in being able to consolidate and develop with one language across the stack. If we can get a Swift-to-Kotlin compiler and a Swift-to-JS compiler (there are already Swift-to-HTML DSLs, and I have been experimenting with a Swift-to-CSS DSL - with my limited proficiency in the language - and it does not seem totally impractical), it's not unreasonable to imagine Swift becoming a "rule them all" language (I remember reading somewhere that Chris Lattner said his goal with Swift was "Total World Domination" and didn't think it was that far off, but can't find the source now).
- abjKT26nO8 6y ago
  On the other hand, Swift changes so frequently that book authors teaching the language can't keep up with Apple to write up-to-date books. By the time a book comes out covering version N, we're a couple months away from version N+1. In this situation I can't trust I will be able to buy a book, learn the language and become comfortable with it before there is a new version with major changes. It's a very moving ground. As for performance, it would be cool if every single thing wasn't behind an atomic reference counter, making it slower than even garbage-collected Go: https://media.ccc.de/v/35c3-9670-safe_and_secure_drivers_in_high-level_languages https://media.ccc.de/v/35c3-9670-safe_and_secure_drivers_in_... (the relevant part starts at 33:06).
ksec 6y ago
The first thing that caught my attention; Tom Doron is a member of the Swift Core Team and the Swift Server Work Group. He manages a team working on server-side Swift libraries at Apple. Server Side Swift ? At Apple? I thought IBM gave up on working Server Side Swift and that was it.
- shehryarrr 6y ago
  IBM stopped working on their own framework Kitura. Vapor has become the dominant framework since then and Apple is still investing more in making server-side Swift better. I have heard rumors that Netflix is running some services using server-side Swift, obviously unconfirmed.
- trevor-e 6y ago
  I think Apple is pushing for the same thing that helped NodeJS get really popular: using the same language across your entire stack. In a perfect world Apple can have their devs use Swift to build an iOS/macOS app or help out with server-side code also written in Swift. For a company their size it could really pay off. I think Google had the same vision with Go but ultimately failed (imo). As an iOS developer I'm really excited to use Swift more and more outside of app development. edit: to clarify a bit more, I think Apple's vision is a lot more than just being able to build a small web app in Swift. They really want to build _everything_ with it.
  - pjmlp 6y ago
    Google had no vision with Go, it was just a group of well known developers in the UNIX world that got fed up waiting for their C++ compile times, with a supporting manager that decided to fund their work. Google is pretty much Java and C++ alongside their infrastructure, and OSes. K8s prototype was started in Java and migrated to Go after some Go aficionados joined the team. Besides k8s, you have Google download service (because someone from Go team bothered to port the service to Go), gVisor, parts of Android GAPI, the new internal Android build system, gVisor, and Fuchsia TCP/IP stack that apparently should be rewritten in C++/Rust. And that is about it, as much as it comes outside.

Maybe if swift had something like rustup, people would consider it more when developing for Linux. Also other popular languages like Rust and Go work well even on weird architectures and little known operating systems, while Swift does not even properly support Windows or FreeBSD. It always felt to me that Apple doesn't really care that much about making the language popular outside of the Darwin family. Swift is not even in the default repositories of most distributions, for instance.

skohan 6y ago
It's worth noting that wider support (including official Windows support) is a stated goal of the next language version: https://swift.org/blog/5-3-release-process/ https://swift.org/blog/5-3-release-process/
- pjmlp 6y ago
  That is just a tiny step, when the majority of available libraries only have the Apple eco-system in mind. Swift is a very nice language, but one is better served with it if their main market is Apple platforms. Just like .NET Core, regardless of how much commitment Microsoft is putting into it, remains a subset of the .NET community at large, the so called dark matter developers.
  - turbinerneiter 6y ago
    The nature of Open Source means that any interested party contributes to the project the features it is interested in. Apple is interested in running Swift on OSX and iOS. Goolge is interested in running Swift on Linux servers to do to Machine Learning. Windows support has to come from whomever is interested in it. Neither Apple nor Google have a big interest in that. Same with other stuff. I, for example, am interested in using Swift with GTK+. I don't expect Apple or Google to work on that.
    - pjmlp 6y ago
      Google's interest on Swift isn't that much reflected outside when Tensorflow 2020 conference did not spend 1 second on Swift, not even to write a tiny status update blog post. Yet they had enough C++, Android, Python and JavaScript to talk about. C++, Python, Julia, R own Machine Learning. I don't miss Swift on Windows, the JVM and .NET stacks offer plenty of choice, including better GPGPU support across multiple OSes.
      - AlphaSite 6y ago
        I think it died the moment Chris Latterner left.
    - coldtea 6y ago
      >The nature of Open Source means that any interested party contributes to the project the features it is interested in Yes, but the reality of Open Source is that unless money are paid, it often goes nowhere for big projects (that need lots of work to port/create libs/etc).
      - turbinerneiter 6y ago
        How is that a _but_ to my comment? The interested party is the one who pays for the development of the feature they want, mostly by paying a developer to do it.
        Redoubts 6y ago
        The "but" is that a million developers somewhat interested in the language but for the lack of platform support wouldn't sum to a relevant interest. I think that's a shame, but still truth.
        coldtea 6y ago
        >How is that a _but_ to my comment? You wrote: "The nature of Open Source means that any interested party contributes to the project the features it is interested in" And my comment essentially means: Yeah, BUT this "nature of Open Source" is just a mere potentiality. The fact that FOSS allows "any interested party can contribute" means nothing if there's no interested party with deep pockets (or time/skill to contribute).
  - skohan 6y ago
    Why is the relative size of the apple-oriented community relevant? I'm not saying it's the current status quo, but if the server-side Swift community reaches a critical mass where it's easy to get support, and there are plenty of libraries available, it doesn't matter one bit if the iPhone developer community is still 10x larger. This would be like saying coconut is unsuitable for use in pina colladas because it's much more prevalent as an ingredient in curry.
    - pjmlp 6y ago
      Because a language is not an island and the competition is tough. Anyone betting their money on Server side Swift better have a solid story to sell to upper management, why they did not went with Go, Java, .NET, C++20, Rust, OCaml, ..... Right now the only solid story is for Apple shops to share their client code with the server.
      - skohan 6y ago
        ROR made Ruby into a mainstream language from a single success story and a usable tool. Swift already has a much bigger developer base, there's no reason it couldn't succeed in other markets as well given the right catalyst.
        mantap 6y ago
        Apple has a bigger developer base but they are captive users. I'm not saying swift isn't good, but nobody actually chooses to use it. They use because it is the language for making iDevice apps. The problem is that if people are only using a language because they have to, then they are not as incentivised to create the open source projects that swift needs. Ruby had a large number of very enthusiastic users, that's what made the difference.
        skohan 6y ago
        I think you're describing a chicken-and-egg problem, and you're overstating the extent to which a gap exists in terms of library support. Swift has a very capable standard library, a high-quality, officially supported networking library, and fantastic C and Python interop which can fill a lot of the gaps to the extent they exist. Even in its current state, I can imagine Swift being productive in something like server-less development, where it would offer a nice strongly typed alternative to scripting languages which currently dominate the space. Swift has a lot of intrinsic features which would make it nice to use for server-side development, and I'm sure it would find plenty of users if there were a strong success story to point to. Given the number of users, I'm not convinced the absolute number of Ruby users in 2009 was larger than the number of "swift enthusiasts" today.
- ceo_tim_crook 6y ago
  swift always feels years behind, I'm not convinced they will ever get the basics right outside of ever shrinking apple land
saagarjha 6y ago
> Also other popular languages like Rust and Go work well even on weird architectures and little known operating systems As someone working on porting “everything” to a decidedly not weird architecture and a very well known operating system, I chuckle a bit because neither language works right now. Not even their dependencies work. It’ll be a while before they will be supported. (Swift works perfectly, but it would be unfair to compare it because it had a strong investment made in it to work…)
- hellofunk 6y ago
  > decidedly not weird architecture and a very well known operating system Can you say which ones? It's hard to place your comment without details.
  - tomstuart 6y ago
    The context implies it’s macOS on Apple silicon.
    - qalmakka 6y ago
      In that case the comment makes no sense - the details of AArch64-based Macs have been made public just a few weeks ago. It takes a while to do port and test for a new platform, even if iOS was already supported.
      - jpace121 6y ago
        It’s implied the OP isn’t considered part of the “public” for this issue.
        saagarjha 6y ago
        No, I learned of it the same time you did, although I had a fairly good idea about when this was coming for a few years ;) And while I have a bit of additional information now, it's nothing that would really be useful for porting.
jfkebwjsbx 6y ago
Swift, Rust nor Go provide support for exotic targets. If you want code to work in actually "weird architectures and little known operating systems", then your only option is C (or weird dialects of "C" in some cases). At least that was how things were around >10 years ago, not sure about the current state of things. Anyone can chime in? Do embedded vendors etc. provide proper forks of newish, modern compilers?
- pjmlp 6y ago
  C++, Oberon, Ada, Pascal, Basic Java, are also options, depending on what exotic hardware you mean. https://www.mikroe.com/compilers https://www.mikroe.com/compilers https://www.astrobe.com/default.htm https://www.astrobe.com/default.htm https://www.ptc.com/en/products/developer-tools/apexada https://www.ptc.com/en/products/developer-tools/apexada https://www.ghs.com/products/ada_optimizing_compilers.html https://www.ghs.com/products/ada_optimizing_compilers.html https://www.aicas.com/wp/ https://www.aicas.com/wp/ https://www.microej.com/product/vee/ https://www.microej.com/product/vee/
- qalmakka 6y ago
  Even excluding extremely exotic targets, the list of platforms supported by Rust and Go is vastly larger than Swift. For instance, there's no official support on FreeBSD, and FreeBSD 1. uses LLVM for everything 2. has a userland really similar to Darwin, so there are very few excuses to not allocate even a small amount of man power to port it. If you add third-party ports and implementations, the list of platforms supported by Go and Rust increases exponentially; see for instance Tiny Go and the ongoing port of Rust to the Xtensa-based ESP32. > Anyone can chime in? I work in embedded and as far as my experience goes nowadays unless you go on extremely limited environments, the embedded chips I mostly see or develop for are either ARM (v7, like stuff from Nordic or the STM), or ESP32 (Xtensa). Every once in a while I have to work on some older projects which were based on Atmel or PIC, or very very very rarely MIPS. It's certainly not like it was before; nowadays you can buy chips like the ESP32-WROVER which have relatively lots of RAM and storage for an absurdly cheap price. They run pretty well even if you opt for using C++17 and complex libraries.
jamil7 6y ago
I like Swift a lot but Apple seems to be focusing on cross-platform within their ecosystem only, the fact that it runs elsewhere almost feels like a side effect. If your goal is sharing some cross platform code then I feel like you're better served by Rust / Go / Kotlin Native / C++ as these languages are making / have made and effort in that space.

skohan 6y ago

That's a neat idea, thanks to named parameters and an expressive type system, I can see how Swift could be a good fit for tasks typically handled by config files. Also having a turing complete language available to customize behavior could have some interesting use cases.

RcouF1uZ4gsC 6y ago

>Shutdown sequences include freeing up resources that hold on to file descriptors or other system resources that may leak if not cleared correctly. Startup workflow is important, and it is nice to have an abstraction that makes it easier. I am less convinced that shutdown workflow is important, and may be more trouble than it is worth. On modern operating systems, the OS will handle process shutdown and clean up system resources such as file descriptors etc. In addition, with things like the OOM killer, etc, the process may not have a chance to actually clean up. Trying to engineer graceful shutdowns is extra code with subtle edge cases (like circular dependencies), and generally, less well tested and exercised. Finally, the operating system needs to be robust against leaking resources due to processes crashing, anyway. So on the balance, I think it is worthwhile to do a startup workflow and engineer your service so that you can always crash safely without messing up your system or leaking resources.

liuliu 6y ago
Agree in principle (you shouldn't rely on shutdown sequence to do correct thing). It is still nice to have a grace shutdown option. For some cases, it is just a little bit "nicer". Imagining you have one service instance need to shutdown for either migration or maintaince, it is just a bit nicer to report to your service discovery manager that this instance will go offline. While service discovery manager will eventually figure it out by its own through heartbeat monitoring, proactively notifying the service discovery manager would reduce a little bit on the failed retries etc.
jfkebwjsbx 6y ago
There are resources that won't be cleanly cleared on crash. Others won't be removed at all. There is also the debugging analysis and the monitoring sides of it too. Thus avoiding shutdown logic is sloppy engineering to say the least. Same for ignoring the need to design the system to avoid crashes to begin with, including OOM ones. This has nothing to do with ensuring your system is OK on crash, which is another side of robustness.
- hamandcheese 6y ago
  If there are resources that won’t be cleared on crash, then how can you say a system is OK to crash?

_pmf_ 6y ago

That's the kind of language integrated cross-cutting DI that I always wanted.

pornel 6y ago

It's interesting that this gets an official blessing. It isn't something integrated with the Swift language, just a bit of code that could be a regular package.

jmull 6y ago
I think they are trying to establish a common approach to foundational concerns. That makes sense to me, though I see the risk. There's a big benefit to the community as a whole if standard concerns are handled in a common: developers will become experienced with them and understand them in deep ways. Tooling can target them. Documentation and other learning materials can become wide and deep. The risk is that potentially better approaches have a very high hurdle to overcome the "official blessing" to become more than a niche option. That's good and fine for alternatives that are only incrementally better or better in some ways worse in others. But sometimes a significantly lacking "official" approach holds back an overwhelmingly superior non-official approach. Hopefully the Swift Server Work Group will keep that from happening or at least not for too long.

ralmidani 6y ago

Swift as a language/ecosystem does seem to check all the boxes in contrast to other modern, mainstream languages; it looks, to me at least, like a much more ergonomic alternative for building applications compared to Rust and Go. It's considerably faster and more type-safe than Python and Ruby. And it has a drama- and shenanigans-free licensing model that I personally am much more comfortable with as opposed to the shitshow that is Java (and, to a lesser extent, .Net). I've been reading lots of Swift docs/articles, and made quite a few book purchases from raywenderlich.com and hackingwithswift.com. My "gut feeling" tells me making the investments to become proficient in Swift, and eventually mastering it, will pay off big time. As a web-focused developer, I must admit I found Objective-C and UIKit intimidating, but with SwiftUI, Apple seems to be lowering barriers to entry; if you know something like Ember, Vue, React, or Angular, you won't struggle too much trying to grok SwiftUI. With Vapor becoming a mature framework, and Apple giving its official blessing for the development of server-side Swift libraries and tools, it does seem like we may soon reach critical mass on the server, and there is a lot of appeal in being able to consolidate and develop with one language across the stack. If we can get a Swift-to-Kotlin compiler and a Swift-to-JS compiler (there are already Swift-to-HTML DSLs, and I have been experimenting with a Swift-to-CSS DSL - with my limited proficiency in the language - and it does not seem totally impractical), it's not unreasonable to imagine Swift becoming a "rule them all" language (I remember reading somewhere that Chris Lattner said his goal with Swift was "Total World Domination" and didn't think it was that far off, but can't find the source now).

abjKT26nO8 6y ago
On the other hand, Swift changes so frequently that book authors teaching the language can't keep up with Apple to write up-to-date books. By the time a book comes out covering version N, we're a couple months away from version N+1. In this situation I can't trust I will be able to buy a book, learn the language and become comfortable with it before there is a new version with major changes. It's a very moving ground. As for performance, it would be cool if every single thing wasn't behind an atomic reference counter, making it slower than even garbage-collected Go: https://media.ccc.de/v/35c3-9670-safe_and_secure_drivers_in_high-level_languages https://media.ccc.de/v/35c3-9670-safe_and_secure_drivers_in_... (the relevant part starts at 33:06).

ksec 6y ago

The first thing that caught my attention; Tom Doron is a member of the Swift Core Team and the Swift Server Work Group. He manages a team working on server-side Swift libraries at Apple. Server Side Swift ? At Apple? I thought IBM gave up on working Server Side Swift and that was it.

shehryarrr 6y ago
IBM stopped working on their own framework Kitura. Vapor has become the dominant framework since then and Apple is still investing more in making server-side Swift better. I have heard rumors that Netflix is running some services using server-side Swift, obviously unconfirmed.
trevor-e 6y ago
I think Apple is pushing for the same thing that helped NodeJS get really popular: using the same language across your entire stack. In a perfect world Apple can have their devs use Swift to build an iOS/macOS app or help out with server-side code also written in Swift. For a company their size it could really pay off. I think Google had the same vision with Go but ultimately failed (imo). As an iOS developer I'm really excited to use Swift more and more outside of app development. edit: to clarify a bit more, I think Apple's vision is a lot more than just being able to build a small web app in Swift. They really want to build _everything_ with it.
- pjmlp 6y ago
  Google had no vision with Go, it was just a group of well known developers in the UNIX world that got fed up waiting for their C++ compile times, with a supporting manager that decided to fund their work. Google is pretty much Java and C++ alongside their infrastructure, and OSes. K8s prototype was started in Java and migrated to Go after some Go aficionados joined the team. Besides k8s, you have Google download service (because someone from Go team bothered to port the service to Go), gVisor, parts of Android GAPI, the new internal Android build system, gVisor, and Fuchsia TCP/IP stack that apparently should be rewritten in C++/Rust. And that is about it, as much as it comes outside.