4 ms·

Embedded Swift [video]

77 points by surprisetalk 2y ago

Ecco 2y ago
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. I wonder how Swift plans to address this.
- tomcam 2y ago
  > 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.
  - tomcam 2y ago
    Interested in understanding why the downvotes?
- SV_BubbleTime 2y ago
  You are thinking about a level higher than embedded.
  - bilkow 2y ago
    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.
    - SV_BubbleTime 2y ago
      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.
      - bilkow 2y ago
        Yeah, I generally agree with you, but I don't see how the parent comment implies any of that
        flyingcircus3 2y ago
        "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.
- therein 2y ago
  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.
  - sureglymop 2y ago
    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.
- w10-1 2y ago
  > I wonder how Swift plans to address this. Swift subsets the language and libraries (which the compiler inlines). No complicated strings or runtime metadata for generic existentials. And new features for ownership. Seamless C interop. There's a lot to it!
nazgu1 2y ago
I wonder if or how easy will be to use existing embedded c/c++ libraries e.g arduino libs.
- dejv 2y ago
  Not sure about Arduino specific code, but including C/C++ is fairly easy. See Swift Embedded Examples [1] (check Sources/Support) [1]: https://github.com/apple/swift-embedded-examples/tree/main/pico-blink https://github.com/apple/swift-embedded-examples/tree/main/p...
- de_aztec 2y ago
  they even show this in the video, apparently it’s supposed to be straightforward
- tomovo 2y ago
  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.
frou_dh 2y ago
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.
afavour 2y ago
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.
- frou_dh 2y ago
  > “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.
  - steve1977 2y ago
    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).
    - deleted 2y ago
      [deleted]
- SV_BubbleTime 2y ago
  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.
- pjmlp 2y ago
  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.
xyst 2y ago
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 note: even apple engineers hate Xcode, +1 for neovim (https://youtu.be/LqxbsADqDI4?feature=shared&t=229 https://youtu.be/LqxbsADqDI4?feature=shared&t=229)
- deleted 2y ago
  [deleted]
- pjmlp 2y ago
  Nope, to make the point about being cross platform, all sessions that weren't Apple framework specific were done in VSCode, Emacs or Neovim. Just like when Microsoft started doing .NET demos on Mac laptops with VSCode, to send the message across.
__rito__ 2y ago
What's the state of Rust for embedded devices nowadays? Can someone point me towards some notable works, learning resources, etc.?
- zengid 2y ago
  Seems to be doing pretty well. Some notable works include Oxide Computer's operating system Hubris https://hubris.oxide.computer/ https://hubris.oxide.computer/
  - steveklabnik 2y ago
    Thanks for linking us! There's also stuff like https://tockos.org/ https://tockos.org/ and https://oxidos.io/ https://oxidos.io/ https://embassy.dev/ https://embassy.dev/ is pretty popular too.
cjensen 2y ago
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. [1] https://en.wikipedia.org/wiki/Embedded_C%2B%2B https://en.wikipedia.org/wiki/Embedded_C%2B%2B
- saagarjha 2y ago
  It’s not just places where you can’t take the performance hit of allocation: some code cannot allocate for correctness reasons.
jonplackett 2y ago
Now that is a lovely bow tie.
zengid 2y ago
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 https://github.com/swiftlang
KolmogorovComp 2y ago
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.
- steveklabnik 2y ago
  Apple is using Rust internally for some things, but we don't know a lot about it. The most public info we have is job openings they've had.
- mannuch 2y ago
  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. To see what I’m talking about check out https://youtu.be/I9XGyizHxmU?si=Zl-7dA0NqhnctRPQ https://youtu.be/I9XGyizHxmU?si=Zl-7dA0NqhnctRPQ 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.).
deleted 2y ago
[deleted]

77 points by surprisetalk 2y ago

Ecco 2y ago

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. I wonder how Swift plans to address this.

tomcam 2y ago
> 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.
- tomcam 2y ago
  Interested in understanding why the downvotes?
SV_BubbleTime 2y ago
You are thinking about a level higher than embedded.
- bilkow 2y ago
  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.
  - SV_BubbleTime 2y ago
    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.
    - bilkow 2y ago
      Yeah, I generally agree with you, but I don't see how the parent comment implies any of that
      - flyingcircus3 2y ago
        "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.
therein 2y ago
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.
- sureglymop 2y ago
  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.
w10-1 2y ago
> I wonder how Swift plans to address this. Swift subsets the language and libraries (which the compiler inlines). No complicated strings or runtime metadata for generic existentials. And new features for ownership. Seamless C interop. There's a lot to it!

nazgu1 2y ago

I wonder if or how easy will be to use existing embedded c/c++ libraries e.g arduino libs.

dejv 2y ago
Not sure about Arduino specific code, but including C/C++ is fairly easy. See Swift Embedded Examples [1] (check Sources/Support) [1]: https://github.com/apple/swift-embedded-examples/tree/main/pico-blink https://github.com/apple/swift-embedded-examples/tree/main/p...
de_aztec 2y ago
they even show this in the video, apparently it’s supposed to be straightforward
tomovo 2y ago
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.

frou_dh 2y ago

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.

afavour 2y ago

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.

frou_dh 2y ago
> “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.
- steve1977 2y ago
  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).
  - deleted 2y ago
    [deleted]
SV_BubbleTime 2y ago
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.
pjmlp 2y ago
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.

xyst 2y ago

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 note: even apple engineers hate Xcode, +1 for neovim (https://youtu.be/LqxbsADqDI4?feature=shared&t=229 https://youtu.be/LqxbsADqDI4?feature=shared&t=229)

deleted 2y ago
[deleted]
pjmlp 2y ago
Nope, to make the point about being cross platform, all sessions that weren't Apple framework specific were done in VSCode, Emacs or Neovim. Just like when Microsoft started doing .NET demos on Mac laptops with VSCode, to send the message across.

__rito__ 2y ago

What's the state of Rust for embedded devices nowadays? Can someone point me towards some notable works, learning resources, etc.?

zengid 2y ago
Seems to be doing pretty well. Some notable works include Oxide Computer's operating system Hubris https://hubris.oxide.computer/ https://hubris.oxide.computer/
- steveklabnik 2y ago
  Thanks for linking us! There's also stuff like https://tockos.org/ https://tockos.org/ and https://oxidos.io/ https://oxidos.io/ https://embassy.dev/ https://embassy.dev/ is pretty popular too.

cjensen 2y ago

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. [1] https://en.wikipedia.org/wiki/Embedded_C%2B%2B https://en.wikipedia.org/wiki/Embedded_C%2B%2B

saagarjha 2y ago
It’s not just places where you can’t take the performance hit of allocation: some code cannot allocate for correctness reasons.

jonplackett 2y ago

Now that is a lovely bow tie.

zengid 2y ago

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 https://github.com/swiftlang

KolmogorovComp 2y ago

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.

steveklabnik 2y ago
Apple is using Rust internally for some things, but we don't know a lot about it. The most public info we have is job openings they've had.
mannuch 2y ago
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. To see what I’m talking about check out https://youtu.be/I9XGyizHxmU?si=Zl-7dA0NqhnctRPQ https://youtu.be/I9XGyizHxmU?si=Zl-7dA0NqhnctRPQ 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.).

deleted 2y ago

[deleted]