Thanks @tkremenek for arranging this discussion. I'll show some opinions from my side.
Many software engineers may be quite unfamiliar with the embedded field and feel confused. Low-performance and limited resources seem to be their first instinct, and there is not a really clear definition to clarify what embedded development really does. In fact, it can include the work related to a few cents worth of MCUs, or powerful computers with a general architecture. However, the different scenarios need different solutions on the Swift side. To facilitate our later discussion, I would like to show my understanding of embedded development as a hardware engineer:
-
Andriod/Linux: it is really the same as the standard Linux app development. The only demand is better support for the higher level cross-compile tooling.
-
High recourses MCUs: nowadays, the performance and resources of MCUs can even rival the mainstream computers in 2000, except that they cannot run the general OSes (non-MMU). I believe these MCUs can support the standard Swift development. In addition to the better cross-compile support, I still need to target a mainstream RTOS. In this way, the Swift language can reach its full potential, especially with its various advanced characteristics. This is what I am most interested in, and I will talk about it later in next comment.
-
Low recourses MCUs: this should be the first impression of most developers. Arduino, MicroPython, embedded rust, etc. all focus on this area and have gained a large market share. If Swift wants to have its place, the binary size absolutely matters (of course smaller binary size is welcomed anywhere). A significant optimization/modification of std/runtime/LTO may thus be required: minimize the std, disable some advanced characteristics (Lazy properties, Copy-on-Write feature, etc), place variables in stack instead of heap explicitly, etc.
-
Most restricted field: IMHO, the programming language itself doesn’t matter any longer in this case. It depends largely on the domain experience of those large suppliers. They provide specific tools for engineers to convert control models into safe code which conforms to the domain specifications. Honestly speaking, it’s hard for any general programming language (even C) to have an important role in this field. It all depends on the relevant committees who make the rules and standards, like BMW/Bosch.
The High recourses MCU systems have been developed rapidly in recent years and don’t have a widely adopted development model. But the other three categories already have their commonly used development model and procedure. Although these four categories require different demands, the most common one should be a turnkey solution for cross-compile tooling which has been discussed sometimes in this forum. Some guys also created tools for it and as I know, SSWG is also working on this currently. Something like rustup would really be helpful for the compilation for different hardware/OSes (ARM Linux/MCU/WASM), and what's more, remove the barrier for those who aren’t iOS/macOS developers. I hope the Swift team could discuss more in the forum about the related work, so developers with different platform backgrounds could share their opinions.
The turnkey cross-compile support is so important, but it relates more to higher-level tools (such as SwiftPM) and platform-related libraries/SDKs, not the compiler itself, so I wonder is it necessary to create a dedicated workgroup for better tooling support?