I do feel like there’s a “X will be the year of Linux on the desktop!” quality to this stuff. 2024 will be the year of Swift on the server/embedded systems/anywhere that isn’t iOS/macOS!
I really enjoy programming in Swift. But I’m not convinced it’ll ever escape the confines of iOS development because there isn’t that persuasive a case for it. It’s nice. But “nice” isn’t enough motivation to create an entire ecosystem. You’re not going to be able to reuse most iOS-oriented swift code in an embedded system so you’ll be starting from scratch.
It suffices to be the language of choice on Apple platforms.
This kind of embedded stuff is also used internally at Apple, and is preparing the work to replace firmware stuff like iBoot that is written on a Apple specific Safe C dialect.
The practical use case here imo, is that your low level stuff, your vendor material, your legacy code is all C.
Your high level application gets to be in swift and create objects, I assume have concurrency, a robust error and exception system.
I like it. I’m not sure it’s going to beat Rust or Zig, but I wouldn’t be upset if it did.
I would seriously look at it for the next project. I love that you can keep VS Code, CMake, and dockerize the environment. What I’m not sure about is the debugging.
It got introduced at time when completion was less fierce and competing languages sucked at that time. Sometimes it's just as well about timing. Swift, Kotlin, Typescript, Rust didn't exist at that time. If today Go got introduced for the first time I doubt it would gain any momentum.
Swift is probsbly to late to the party considering big competition amount languages and their ecosystems being "nice" today is not enough.
Being backed by Google was huge. Swift is backed by Apple but not outside of their specific use cases. If Apple had announced they were going to start making all their backend services in Swift too I imagine things could have looked very different.
* linux, windows and wasm compilation targets. They hired the maintainer of wasm project as well.
* LSP language server for Swift, to power VSCode and others editors, even though, they use Xcode that doesn't need it
* well tested server side libraries similar to netty/jetty (they even have a former Akka developer)
Other commenters have gone over many of the reasons why Go got popular, and I don't claim to know for certain, but in my view one important one is probably Rob Pike. He obviously has a well-known pedigree, he's very articulate, and a lot of people latched on to his "Go philosophy". Combine that with the reputation for unrivaled engineering excellence that Google had in 2009 and it's not surprising that Go got as big as it did.
Google hype, popular cloud native open source projects showing its potential, well known creators, good to acceptable tooling, strong standard library, low memory footprint, concurrency, simplicity, productivity, the whole philosophy behind it.
Some of these are questionable, but I heard all these by some people.
What does this say about Swift's chances to gain mainstream popularity outside of the Apple ecosystem? Probably nothing, as the languages and the circumstances are so different.
Go drove the cloud-native migration from java/enterprise, riding the wave from behemoth machines to small containers, as a result of Google deciding to build alternatives to Java/Oracle and raw C.
The ease of the language and the self-contained binaries just changed how fast that could happen, not whether it would happen.
> “nice” isn’t enough motivation to create an entire ecosystem.
Just look at backend web development. There's prodigious duplication of effort by each language camp to create their own web framework, database libraries, etc. Why does each camp bother? They just think their chosen language is really nice.
Interestingly, there is not too much momentum behind Swift-based web frameworks, despite the language being perceived as nice by many (as far as I can tell).
https://skip.tools offers a compelling option for going SwiftUI-first and having Android too. And a vision (and reference implementation) for how to start doing this on more platforms too.
Isn’t their motivation just the need to create verifiable foundations for the platform for AI private cloud compute? Everything else should just be gravy.
Sort of a tangent, but I'm really stoked that Apple has uploaded all of their WWDC videos onto youtube. I am much more likely to watch them on there. I feel like it might be a part of them opening more things up around their platform development, like migrating the swift repos out of Apples org on github into SwiftLang https://github.com/swiftlang
The main problem with embedded software is that it usually lacks many facilities commonly found in desktops or servers. For instance, dynamic memory allocation or access to a filesystem.
This potentially results in a big fragmentation of the ecosystem. For instance, even though “embedded C” as a language is really just C, the vast majority of C libraries cannot be used on embedded systems because they’ll use the occasional malloc, mmap or fopen call.
Rust is particularly good at this, with its [no_std] directive that is well documented and used in a wide variety of libraries.
Rust does it well with [no_std] but then seems to be dropping the ball with [restricted_std].
I recently set up an embedded-hal project for cortex-m and after some struggle, I was happy to get dynamic memory allocation and std working but the platform had a tier 2.5 support so I had to put [restricted_std] if I wanted to use it.
But that means none of your dependencies can use std unless they also declare [restricted_std]. So now I have the stdlib but none of my dependencies can use it.
Interesting. I never went as far as trying to make dynamic memory allocation work. But I really did have a good experience with rust. So many helper crates to make things just work (hal, pac, cortex-m, embedded-graphics, etc). And not to forget things like heapless which work quite well. Now I never did embedded development in any other language but in rust it was definitely nice for a beginner with everything already there and easily installable.
> The main problem with embedded software is that it usually lacks many facilities commonly found in desktops or servers. For instance, dynamic memory allocation or access to a filesystem.
Very often dynamic memory allocation and file system access are explicitly forbidden from an embedded project. They can both cause security problems and unpredictable behavior.
Care to elaborate? As I see it, the only restriction on embedded systems the parent has added is that it usually lacks filesystem access or dynamic memory allocation.
Time, posix, threads, core, a lot of times MPU, an OS beyond a scheduler, file system, basically almost all abstractions you get on the levels above embedded.
"it usually lacks many facilities commonly found in desktops or servers."
This is where they implied that operating system level functionalities are not found on computers without operating systems.
The fragmentation that exists in embedded is due to the nature of embedded systems, not programming languages. PCs, laptops, and smartphones are general purpose computers. Just about everything else is an embedded device, hardware custom designed for a specific purpose, given just enough resources to accomplish its intended task. Writing software for a general purpose computer on top of a full OS can largely be done without caring about the underlying hardware. Writing embedded firmware without an OS is only possible through understanding the specific hardware you are targeting.
I'm not sure what's Apple plan here, as others have stated Swift will stay for the foreseeable future 'IOS language', and even if it is used internally, why not use Rust instead who provides a similar kind of safety and convenience, and is already much more used in embedded devices? Assuming the reason is to avoid using C/Cpp.
Given engineers' skills at Apple using Rust would not be an issue.
Rust is much less ergonomic than Swift, especially for application-level development.
I like to think about it like this: Rust forces you to think about memory where Swift doesn’t.
But what’s really cool is that Swift is adopting some of the great things about Rust’s ownership system, allowing you to “opt-in” to a Rust-style performance profile if you think the mental overhead is worth it for your use-case or domain.
What’s exciting to me is that Swift is becoming a great language that works at all levels of the stack while staying a language that feels really great to write.
IMO what’s largely held it back in adoption is its cross-platform experience, but you see that the Swift team is really trying to change the perception here (they’ve specifically tried to highlight using non-Xcode/non-Mac dev environments, deploying to Linux, developing embedded etc.).
I appreciate the effort, but this is a misguided idea.
This is not the first Embedded <LANG> attempted. For example, Embedded C++ [1] has been around for a couple of decades and is only used in a few weird places like Apple Device Drivers.
The problem is that if you are so very constrained that you can't afford to have dynamic memory that is reference counted, then you probably have so little memory and functionality that you may as well just use C as an advanced assembly language for the processor.
I wonder if the AirPods firmware could be written in Swift. I gather that Apple's "OS" they currently use for them and other devices is a project called RTKit.
I don't see any benefit of using this over Rust, C or C++. I guess if you have been coding in swift your entire career, it's just one less language to learn if you decide to get into IoT
I just tried it recently, worked well enough, including support for std vector, string etc. You can loop over std vector items using a standard Swift loop, for example. It´s clear Apple needs and uses this internally too.
I really enjoy programming in Swift. But I’m not convinced it’ll ever escape the confines of iOS development because there isn’t that persuasive a case for it. It’s nice. But “nice” isn’t enough motivation to create an entire ecosystem. You’re not going to be able to reuse most iOS-oriented swift code in an embedded system so you’ll be starting from scratch.