Apple explicitly said they see Swift as a systems language... curious what people thing about that. Does it compete with C/Rust, or is it just a pipe dream/marketing message?
It's designed to give it hype, it's not a systems language.
The first question you should ask for any systems language is how to I integrate assembler, when the answer is to use C / C++ then you know it's not a systems language.
Also, how you can tell a language is a systems language, it has an operating system written in it used by a large user base.
How do you layout a struct in Swift so that it's the exact size and layout you want? You can't, again, not a systems language. It's like going to Home Depot and buying "industrial grade" appliances which are usually just your standard shitty appliances with a stainless finish.
To write an OS you simply need to be able to compile code that can be launched by a bootloader. That's it. You don't need explicit control over the layout of your data structures in memory.
I'd hazard that the engineers at Apple are perfectly qualified to identify what is and isn't a "systems language" working for one of the few companies that has actually developed several from scratch (I am referring to A/UX, Mac OS Classic, Newton OS, and NeXTStep / OpenStep / OSX / iOS in case you're wondering).
I assumed you were talking about there being a well-defined relationship between a struct definition and its layout in memory. As far as I know, Swift can allocate chunks of memory and play with bytes explicitly without resorting to assembler, so I think that's pretty much covered.
That said -- if Swift were to be used for systems programming, you'd probably want better support for all of this stuff (starting with inline assembler), and for all we know Apple is already tinkering with this stuff in-house, it just hasn't released it yet (e.g. because it's in flux).
Since it's perfectly possible to do inline assembler via a straightforward kludge, adding that particular feature to Swift would be almost trivial.
As things stand, it would be pretty easy for a third-party (once Swift is open sourced) to add the necessary niceties to the standard libraries or Swift itself, so these kind of objections are pretty minor. The big question is low-level performance, and Swift has real advantages over Python and Go here.
To be fair, you don't have complete control over struct memory layout in standard C, either, and C is certainly a systems language. The compiler can choose to add padding where it likes. Pragma pack, attribute(packed) etc are compiler extensions.
Edit: You can also link against .o files with Swift, which is the only sane way to integrate assembly language anyway (i.e. in a separate compilation unit).
I don't know if you are talking about swift only, but with GCC or clang working in C, inline asm is a lot more pleasant than another object file. More efficient too. (Unless you like that your code makes a pointless jump to run a single instruction and jump back.) You can contrast this with the Microsoft compiler which won't do inline asm on ARM.
