Introducing Swift Service Lifecycle | Hacker News Reader

Introducing Swift Service Lifecycle

swift.org

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).

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_... (the relevant part starts at 33:06).

Regarding language changes, I think this has improved quite a bit. I forget if stability was introduced in 4.x or 5.x, but code written today should be fine even when run through a new major version of the compiler. You can simply ignore new language features you aren't ready for until your codebase is due for a refactor.

Regarding ARC, you don't have to use reference types in Swift, and the community seems to agree that structs are more suitable than classes for most use cases (a SwiftUI app is made of structs that conform to certain protocols, and those structs can be initialized, copied, and "modified" with little overhead).

The cool thing about Swift is that structs can still have methods, computed properties, and custom initializers. So if you're coming from Python or Ruby or Java, or think OOP can help you organize your code, you don't have to throw away everything you've learned in order to be productive and write elegant code (and Swift brings a few new OOP tricks of its own).

> I forget if stability was introduced in 4.x or 5.x, but code written today should be fine...

They've always provided source compatibility modes in new releases of the compiler so you can delay making syntax changes to an existing codebase if you need to.

You're thinking of ABI stability, which is in place as of Swift 5, and doesn't have anything to do with what parent is talking about.

For some time; at some point newer compilers will drop support for older versions.

> Swift changes so frequently that book authors teaching the language can't keep up

This hasn't been true for a couple years.

>I remember reading somewhere that Chris Lattner said his goal with Swift was "Total World Domination"

I think it was ATP Podcast

https://atp.fm/205

But if you are listening to ATP most of the guest and host aren't really liking swift at all. And prefer to stick to Objective-C for as long as they could.

In someway I could understand that, Swift all of a sudden has 10x increase in complexity compared to Objective-C.

>And prefer to stick to Objective-C for as long as they could.

I know these types, and they're extremely frustrating. Swift is superior to Objective-C in just about every way a modern programmer could want.

> Swift is superior to Objective-C in just about every way a modern programmer could want.

Reflection and dynamism are fairly big areas where Swift falls short. A couple more: interoperatibility with C++, any form of macro support, ability to shed the runtime where convenient…

Not in interop. Objective-C++ is how I write macOS apps. So does facebook AFAIK.

Some of the members of that podcast write a fair amount of Swift. Actually, I think the majority of the hosts do, and the holdout is seriously considering doing so as well.

Swift started out as a pretty nice language, but in my opinion there are some major problems:

The combination of ubiquitous closures and reference counting is dangerous. Avoiding circular references is not nearly as easy as you might think and reference counting is slow (low memory usage is an upside though).

And lately, the language has become rather convoluted. They have added features that make Swift code hard to read. Function builders in particular are a terrible idea. I know many people like internal DSLs. I don't.

I think it's a big mistake to overload the syntax of a language to such a degree that reading a piece of code in isolation tells you very little about what it does, because somewhere far away there may be a mode switch that completely changes the semantics of that piece of code.

Consistency is more important than "looking clean" at all cost.

I agree function builders have a lot of potential for abuse. But I prefer to take a "with great power comes great responsibility" approach over saying a feature should _never_ be allowed in a language.

If I'm promoting a DSL that makes heavy use of something like function builders, I should provide robust documentation so other developers know what to expect. And those developers should, on the other hand, at least skim the docs in order to get a basic understanding of how the DSL works. If someone goes through the trouble of providing docs to accompany a DSL, and a downstream developer doesn't bother to read them, is that really the original developer's fault?

Consistency is a good thing, because it allows you to infer how something works based on what you already know. If you can't infer it then you have to go read the docs. That's more work you have to do.

There's clearly a trade-off between expressing a specific task as succinctly as possible and for our knowledge to be transferable between different tasks.

It is the job of a programming language to guarantee a minimum level of transferability while allowing maximum expressivity. To do that, it has to put restrictions on how the semantics of syntax can be redefined.

It's clearly an art to get that balance right. In my view, Swift hasn't got it right and is moving in the wrong direction.

I sympathize with your concern. I actually chose Python/Django over Ruby/Rails because I found it almost impossible to understand how Rails really works. The biggest offenders in my book are Rails doing auto-import and (at least when I was learning it) lots of reopening of classes. Even if a person wanted to read the docs to understand where a piece of functionality came from, it was very easy to get lost.

Swift does risk getting carried away and becoming just a safer and faster version of Ruby, but I still think it's too early to write it off just because they introduced some syntactic sugar.

I've said before that writing an import statement never killed anyone. If Swift were to make something like auto-imports mainstream, I would definitely take it as an indication they were going in the wrong direction. But so far that doesn't seem to be the case.

Nit: closures are problematic when they escape. The ubiquitous ones that the functional constructs take (for example) are totally fine.

I've been exploring Kotlin as a "rule them all" language. With Kotlin native/multiplatform you can already cover all platforms today since it can compile to JVM, JS, and native code for iOS/macOS.

You still need to write the iOS/macOS UI in Swift but you can very easily have your data layer and business logic shared across platforms. I actually like that approach better than other cross-platform solutions since you keep the native platform UI.

Very interesting, I will check it out!

Is there a Kotlin-first server-side framework that you can recommend? (I use Java/Spring at work and it's OK, but would prefer to try something else for my side projects)

Edit: if someone doesn't want JVM drama on their servers, how far can they get with Kotlin via LLVM?

I've been using https://ktor.io (by Jetbrains, same company behind Kotlin) but there are others like Micronaut and Quarkus. A few more options at: https://kotlinlang.org/lp/server-side/

As far as I'm aware there's no native server side framework available at the moment, but ktor could potentially support it in the future given the ktor client libraries work on native. You could also use GraalVM native image to build a JVM-free binary of your server, Quarkus has built-in support for it.

I developed one or two server side apps using both Vapor & Kitura in late 2016 | 2017. the ecosystem though helpful isn't as vibrant as in other languages. if you care about shipping product i.e time to delivery vs language performance that matters a lot. machines are cheap, human labour and effort is not. with SwiftUI they're just bringing sanity around. otherwise screw apple for their closed ecosystem.

I'm fairly new to Vapor, and not sure what the ecosystem was like 3-4 years ago, but it's possible it has matured a lot if the last time you checked it out was that long ago. I know Vapor's Fluent ORM has improved quite a bit recently, especially as it can take advantage of property wrappers introduced in Swift 5.1. It's not hard to imagine Fluent approaching feature parity with Rails' ActiveRecord and Django's ORM, but with much better performance and type-safety.

FWIW, Kitura is probably dead in the water as IBM has stopped supporting it.

> and, to a lesser extent, .Net

What's the problem with .NET, as it belongs to .NET Foundation now?

https://en.wikipedia.org/wiki/.NET_Framework#Licensing

The ecosystem looks like a hodgepodge of proprietary, MIT (accompanied by a potentially non-enforceable "patent promise"), and Apache. It's better than what Oracle is doing with Java, but Apple did the right thing and released Swift under Apache.

Like getting out every single new Java version since Java 6, adding AOT support (which Sun was completly against it was JIT or the highway), integrating GCs able to handle TB sized heaps in ms, adding value types and improving the generics story without doing Python 3 with 25 years old JARs, fibers, replacing JNI, bringing the metacircular JVM MaximeVM into production, long term roadmap to make Hotstop a mostly Java implementation, adding vector instructions in collaboration with Linaro and Intel,...

Yeah, considering that only IBM did an acquisition offer that was quickly withdrawn, Oracle is being really nasty for Java, even Microsoft now contributes to OpenJDK.

None of my criticism is regarding how Oracle has been managing Java at a technical level. I thought that would be clear from the context, but I am strictly concerned with the increasingly dark patterns in the licensing model; I had Oracle's Java 8 on one of my computers, and it worked fine, but then a few months ago I got a notification that I needed to update to a newer version. After it was done updating, I was presented with an ultimatum: accept the new licensing terms (no commercial use without paying) or uninstall the software. I chose to uninstall, and vowed to never touch Java again when I personally have the discretion. Yes, I know I can install OpenJDK, but given Oracle's past and present behavior, how can anyone be assured they won't attempt to extinguish OpenJDK, even in the near future? Oracle seems to be boiling the frog slowly, and it probably won't be long before it becomes impractical to use non-proprietary Java anywhere.

Edit: There was no warning that installing the latest "update" to Java would trigger an ultimatum screen, and no way to revert the installation. And as far as I know, there is now no way to download Java from Oracle without accepting the new license terms. It's pretty obvious what Oracle's endgame strategy is.

Anyone with some knowledge of the Java eco-system knows perfectly well that Java is as free as ever, more so that it was under Sun, where it was only free beer without source.

https://www.oracle.com/technetwork/java/javase/overview/orac...

https://medium.com/@javachampions/java-is-still-free-2-0-0-6...

Finally if you want top of the game JIT, GC, managed runtimes someone has to get the money.

If you are afraid what Oracle might do with Java, better not touch any language handled by Apple, Google, Microsoft, IBM, Intel, SAP, ...

It is not you that they care about, rather their shareholders.

When Apple releases Swift under Apache 2.0, which includes an explicit, unequivocal patent license, it inspires a lot more confidence than all the shenanigans Oracle has been pulling with GPL2. Whom Apple cares about is less important than how they behave. With Swift, they're buying goodwill in the FOSS community. Oracle, on the other hand, keeps burning bridges.

The beauty of Apache 2.0 is that corporations don't have to contribute anything back to the community, really inspiring.

Apple also enjoys making use of their lawyers by the way.

Everything in that list is MIT or Apache except the ancient version from 2012. The idea that releasing under MIT is bad would be news to users of Perl, Python, Ruby, etc.

After all, software patents aren't a big deal for most languages. Perhaps excepting Swift, where patents are somewhat of a problem - it's debatable whether a competing implementation would be legal due to Apple's patents:

https://news.ycombinator.com/item?id=18997302

IANAL, but MIT plus a "patent promise" seems dangerous, because AFAIK it hasn't been established whether such a promise would lead to offensive patent litigation being thrown out.

A lot of people refused to use React because it wasn't clear if Facebook intended to weaponize its patents. After lots of protest, Facebook relented and switched from BSD plus a patent grant to vanilla MIT. It hasn't been established in court if MIT by itself gives you implicit protection against patent litigation, but adding a patent grant that is one-side is, in the opinion of at least a few people on HN, more dangerous than not mentioning patents at all.

I wasn't following React during that kerfuffle. Reading about it, it seems to be that Facebook made an Apache style licence with a very titled patent clause, where one's rights are terminated following any patent suit against Facebook, even if the patent suit did not relate to React. That is, the problem seems to be the phrasing of the patent clause which was included in the licence, and a different patent promise would not be a problem.

The phrasing of the .NET patent promise[0] doesn't seem to have that problem. It might be a bit difficult for people who want to copy and modify the code, since the promise is limited there (only reimplemtations, but I can understand that since they don't want to waive the patents altogether). However, the promise seems fine for users of the framework (IANAL etc. etc.).

[0] https://github.com/dotnet/coreclr/blob/master/PATENTS.TXT

IANAL

What if MS retracted its promise? Would the retraction be retroactive? A license is usually perpetual and non-revocable, with causes for revocation being written into the license itself (side note: RMS is not infallible, and my zeal for making everything Copyleft has mellowed, but I still find the wording of the GPL to be pure genius).

Has a "patent promise" been tested in court? The GPL has been tested and upheld in some jurisdictions, perhaps most notably in the BusyBox cases: https://en.wikipedia.org/wiki/BusyBox#GPL_lawsuits

According to the "In re Spansion" case[0], a patent promise is equivalent to a licence. Given that and the MIT licence, I don't see much of any way for MS to abuse patents against .NET users (IANAL). Amusingly, Apple itself was the beneficiary of the ruling.

Speaking of Apple, given its history it's not impossible to imagine a closed source "Swift 6" with no backward compatibility, leaving only a very tiny ecosystem for the open source Swift.

[0] https://patentlyo.com/patent/2013/01/3rd-circuit-covenant-no...

I thought kotlin's aporoach about in language dsl shines here.

You still need to read code from somewhere else to know whether it is a variable/field/extension or something. But at least you know it is a 'value', so you can access prop on it or something. You probably don't know the context of a lamba. But you will always at least know it is a lambda, and you can/need return value from it. Important basic information didn't lose under the sugar syntax.

Compares to the groovy. That is literally a nightmare that I never find out what it is doing, am I calling a method or assign something to variable? I really don't know. And I end up gave up and copy build.gradle from someone else.

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.

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/

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.

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.

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.

I think it died the moment Chris Latterner left.

>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).

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.

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.

>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).

I wasn't trying to say that FOSS _allows_ for anyone to contribute but that it _relies_ on that.

I was trying to make the point that Swift will be good for the things that the parties who are interested in it need it for. And these interested parties are the deep pockets you are talking about.

We might just be saying the same thing :)

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.

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.

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.

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.

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.

Have you used the Python interop? I went looking to try it a few months ago and it was MIA as far as I could tell. It seems to be exclusively baked into Tensorflow's fork of the compiler. I would love a pointer if I missed something!

Yep, there's a standalone library and it has some system dependencies but it works great:

https://github.com/pvieito/PythonKit

Thanks; I found that and still couldn't figure it out, but I'll take another look at some point.

The captive bit isn't entirely true, as the language has had Objective-C for competition.

I suspect that instead of an enthusiasm gap the greater negative impact on FOSS libraries comes from the Apple-platform dev community being strongly oriented around making consumer-focused programs for money.

Objective-C is neither easy nor something most people liked. I did actually like it because I always thought it was really cool, but most people I talked with hate it with a passion. For the average Java developer, choosing between Swift and Objective-C is like choosing between cake and a tomato for dessert. Some people might pick Objective-C, but it's definitely not the majority.

And to this day the only shops that actually care about Ruby in the West are doing Rails and not much else, to the point Rails == Ruby.

Swift has already achieved that, Swift == Apple platforms.

I don't follow your argument. Ruby is a single-use-case language so therefore Swift must also be? I can point to many languages which have achieved adoption in more than one domain as counter-examples.

Like Objective-C?

Does Objective-C have a 1st party open-source runtime, and Linux and Windows targets in the main CI pipeline?

It has the former: https://opensource.apple.com/source/objc4/objc4-781/

It does now. It was closed source when ObjC was a relevant language

It has been available from Apple for at least a decade.

And the source that is available today dates back all the way to 2001.

That is just libobjc, which is basically useless except if you actually plan to reimplement everything Foundation does. ObjC IS de-facto Foundation, without NSString, NSArray, etc no library will ever work. GNUStep is more likely to be considered a decent multi-platform implementation of an Objective-C runtime, or WinObjC from Microsoft.

Not just to share code, but developers and other parts of the language ecosystem as well.

From my perspective Swift is in a trailing group with Go and Rust, chasing C# and Java for new server/service development. Swift is behind, IMO, in supporting server-side development, but ahead in language adoption. That's why the SSWG makes sense.

(Probably C/C++ is used for a lot of new server development too, but I feel that's mostly unassailable, at least directly -- I think that's mostly on-going development in systems with heavy ties to existing C/C++ projects where they've already very seriously considered alternatives and rejected them.)

> 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…)

> 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.

The context implies it’s macOS on Apple silicon.

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.

It’s implied the OP isn’t considered part of the “public” for this issue.

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.

Unless they work for apple. Those on the inside have been toying with it for a while now.

Nope, just a third-party developer who until June knew of "aarch64-darwin-xnu" as "iOS" ;)

Yup, that’s what I’m doing. Just offering my comments on how difficult some projects are to port: some require no new code and some will require quite a bit, and some will be blocked on their dependencies being in the latter camp :)

I've been running production grade Go apps[1] on aarch64 servers for ~ a year, written on macOS(x86_64), tested on aarch64 before deployment and never faced a single instance where something didn't work because of the architecture.

These are the benchmarks for different ARM platforms[2], where I had submitted one for Jetson Nano a year back and now it seems there's one for Apple Silicon.

I'm not telling, no one would ever find cross platform issues with Go; I'm just curious to know what issues you have faced and whether it's because of Apple's extension of ARM instructions.

[1]https://needgap.com

[2]https://github.com/golang/go/wiki/GoArm#jetson-nano

The comment wasn’t really an attack on the languages being unportable itself but more that their toolchains are complicated and not very flexible, requiring a decent amount of additional work for new architectures, whereas a lot of the “./configure && make” style projects already work.

Apple’s proprietary extensions don’t really affect porting efforts except in one specific case when writing high-performance JITs for language runtimes. (And there is a fairly simple patch to disable this entirely.)

>chuckle a bit because neither language works right now. Not even their dependencies work. It’ll be a while before they will be supported.

I'm not sure what's preventing you from giving a direct & specific answer. As it would be useful to know where Rust/Go's toolchains fail for using the code for cross - platform applications.

Rust is blocked on libffi, as are most things using Python (which includes cmake, and that precludes all of LLVM). I downloaded the Go bootstrap and it tried to link against crt0 directly and it's either looking up the wrong one or there is none for aarch64. It's also looking for a file called defs_darwin_arm.h which I don't have. Some warnings that will probably be problematic at the future related to the ABI defining char to be signed.

>I downloaded the Go bootstrap and it tried to link against crt0 directly and it's either looking up the wrong one or there is none for aarch64.

Go team was already working on getting the toolchain to work on darwin/macOS before Apple announcement[1] because GOOS=darwin meant iOS(gomobile) and there are instructions available now[2] to build it successfully before the official patches. Your test results there would be a valuable contribution.

>Some warnings that will probably be problematic at the future related to the ABI defining char to be signed

You mean unsigned char? that's a common hurdle while porting x86 code to ARM.

[1]https://github.com/golang/go/issues/38485

[2]https://gist.github.com/tonistiigi/290d2e7118fe6f581e336bf35...

Is there a good public link to what those "Apple’s proprietary extensions" might be? Thanks.

https://developer.apple.com/documentation/apple_silicon/port...

https://siguza.github.io/APRR#a-new-jit-on-the-block

> “./configure && make” style projects already work This is because Apple has a massive investment in LLVM, Xcode is completely based on it. When they unvealed Apple Silicon, the development toolkit and the new Xcode, Clang was already ready for macOS 11 on AArch64, a luxury the Go developers definitely didn't have.

For instance, GCC is not ready and no one really knows when it will support desktop Darwin on AArch64 (see https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96168#c6)

Yes, because MacOS on ARM is a super common architecture in July 2020 :-)

macOS works, ARM has support for years; for many projects all you need to do is pass in the flags requesting support for both and they work pretty much out of the box. Some get a little confused about how such a thing could possibly exist, but I can’t really fault them for that :)

The problem about assumptions is that we can't live with them, but we can't also live without them.

Many so-called "cross platform" projects have had big surprises when it actually came time them to be ported to other platforms.

It's extremely rare for a project which has never been compiled and launched on another platform to actually require 0 porting effort for that platform once actually required to run there.

Yes, for all but the simplest or most abstracted projects sticking steadfastly to standardized features this is fairly hard to do. But the closer you stay stick to that, the more platforms your projects has been through, the more foundational (and less dependency-heavy) your project is, the more likely it will port with few or any changes. My preferred shell and text editor, for example, required zero changes; as did many core tools such as ncurses or make or autoconf. And on top of those it was easy to get things like perl or ninja up with perhaps a small tweak to their configure script or something.

The lowest common denominator leads to working with Stone Age tools. I'm not surprised that not everyone goes that route.

And regarding your porting, Perl, sure, was easy to port. What about CPAN? Want to bet how many Perl libraries will keel over? Same thing for Ruby/gems, Python/pip, etc.

Don't get me wrong, your work is nice, but the people that build on top of your work outnumber you by 2-3-5 orders of magnitude and not all of their porting efforts will be trivial.

This was the extent of the changes necessary to get Meson working on the system-provided Python: https://github.com/mesonbuild/meson/commit/85686e21d78a587de.... Surely that is not a "Stone Age tool"? The people doing the work right now to get foundational stuff working are doing that precisely to aid the porting efforts of the many, many developers that will depend on those things working in a few months when they have to port their own codebases.

How many third party Python libraries does Meson use?

Edit: I've checked, none. Most of the Python stuff out there will use at least some.

And they’ll probably have a harder job as a result.

When I was working porting code across multiple UNIXes during the 90's, I discovered how "portable" POSIX actually is.

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?

C++, Oberon, Ada, Pascal, Basic Java, are also options, depending on what exotic hardware you mean.

https://www.mikroe.com/compilers

https://www.astrobe.com/default.htm

https://www.ptc.com/en/products/developer-tools/apexada

https://www.ghs.com/products/ada_optimizing_compilers.html

https://www.aicas.com/wp/

https://www.microej.com/product/vee/

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.

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.

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.

>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.

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.

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.

If there are resources that won’t be cleared on crash, then how can you say a system is OK to crash?

Assuming the system was designed in such a way that relaunching the crash process will recover those resources for the freshly started process.

Now if the error cause has led to an endless crash cycle, then not.

I came here to say more or less the same thing - my understanding was that system resources (like memory allocations, file descriptors) would be freed when the process exits.

That said, I still see the value of doing graceful shutdowns.

Not necessarily, for example IPC connection points depending on what kind they are.

Ah yes, the various highly cursed SysV IPC constructs. And named pipes. Any others?

A communication channel which survives a process exit is fine as long as the next process start can pick it up again. You can do that with the SysV things and named pipes.

Of course, you can also not do that - i remember the first program i wrote to play with SysV message queues created a fresh private queue each time, and didn't delete it on exit, so i ended up with piles of anonymous queues i couldn't delete. I had to go and cry to a system administrator who knew how to get rid of them.

If your code is crashing more often than it is gracefully shutting down, you have a problem.

Yes, you need to engineer for the crash scenario, but you shouldn't be relying on that in the same way you shouldn't tell users the only way to stop your software is to `kill -9 [PID]`.

In a normal deployment it might be useful to use shutdown parts of code to signal to orchestrators that the operation has been completed successfully so they can take further steps, for example.

Everybody's circumstance is different, but I definitely recommend thinking more about shutdown workflows.

> If your code is crashing more often than it is gracefully shutting down, you have a problem.

You have this exactly backwards. If your software crashes rarely, you have a problem - when it does crash. Because then it's doing something you aren't routinely and thoroughly testing by doing it all the time.

This is an old, counter-intuitive, but powerful idea - if you're not familiar with it, start with this paper:

https://dslab.epfl.ch/pubs/crashonly.pdf

Surely a webserver at least wants to finish serving in-flight requests?

For some things fine, or at least you can sorta get away with it.

But in scenarios where you want/need to avoid service interruptions that's not good. The basic scenario is when you have an instance of your service you want to shut down for whatever reason (maintenance, update): (1) start a new instance of your service; (2) route requests to the new instance; (3) shutdown the old instance.

In (3) you'd prefer not to just kill any requests in-progress. It's also nice to flush write-buffers (can be used for high-write-frequency but not critical data -- perhaps stats collection or other informational data).

I'd definitely keep shutdown simple, but you don't need to go without.

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.

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.

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.

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.

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.

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.

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

Reply on news.ycombinator.com