11 ms·

A Vision for WebAssembly Support in Swift

202 points by LucidLynx 2y ago

turnsout 2y ago
Ignore the haters—Swift is an enjoyable and productive language that gives you a lot of advanced features if you want them, but lets you ignore them and almost treat it like a scripting language. Adding first-class wasm support could help it become a more reasonable choice for development outside the Apple platform.
- solardev 2y ago
  Wow, thanks for saying this. I had no idea it was even usable outside the Apple ecosystem. Seems like other IDEs support it too (https://www.swift.org/tools/ https://www.swift.org/tools/). How would UIs work on other platforms, though?
  - thewebguyd 2y ago
    > How would UIs work on other platforms, though? I think for right now, you'd have to use the C interop and link against something like GTK or other GUI library. I don't think SwiftUI specifically would ever work well cross-platform, it has so many Apple-isms. There's also Swift/Win32, but it's MVC. You could also use the interop and use QT as well. I don't think any of those are necessarily good solutions, but they are there.
    - wahnfrieden 2y ago
      TokamakUI And https://skip.tools https://skip.tools
      - solardev 2y ago
        Hmm, Tokamak seems abandoned (hasn't been touched in years) and skip.tools requires xCode and is Android-only =/ Thank you though.
        wahnfrieden 2y ago
        Yes there’s nothing all in one yet. But these are promising directions. Tokamak isn’t abandoned, members are involved in core Swift changes that it depends on and have made progress recently with embedded Swift.
    - achierius 2y ago
      What sort of things are you referring to when you say "Apple-isms"? Not that I doubt your claim -- I just don't do much UI development so I don't have a good reference for what things might be 'platform specific' in that way.
  - dagmx 2y ago
    As with other languages, you’d need bindings to another UI framework. In that sense, I wish SwiftUI had a different name because it seems intrinsic to Swift when it’s really no different than UIKit. There’s stuff like SwiftCrossUI that does multiple backend bindings https://github.com/stackotter/swift-cross-ui https://github.com/stackotter/swift-cross-ui And Qt was exploring some bindings using the new C++ interoperability.
    - loic-sharma 2y ago
      There’s also Shaft, which is Flutter ported to Swift: https://github.com/ShaftUI/Shaft https://github.com/ShaftUI/Shaft Like Flutter, this paints everything itself. It doesn’t need to bind to a UI framework directly. Instead, it needs the platform to provide primitives like a surface to draw into and input events.
- jonhohle 2y ago
  Rust, Go, and Swift were all coming up around the same time. Rust looked ugly, Go underwhelmed me, and Swift aeemed like the best “language” at the time, with many opinions that aligned with my own. Having now spent time in all three, swift feels the most ergonomic and has features that make me feel productive. I still feel like there isn’t much “there” in Go, and rust makes me feel like I’m solving for the compiler rather than working on whatever problem I was needing to work on. Edit to add: SwiftUI, however, is a mess that I loathe. I may be in the minority of enjoying the IoC choices in Interface Builder and AppKit.
  - jkubicek 2y ago
    SwiftUI is just amazing for the first 30 minutes you use it... then you make a minor syntax error deep in some nested views and you're selectively commenting out coded blocks to hone in on the error like a caveman. It makes print-statement debugging look cutting edge.
    - turnsout 2y ago
      As an early adopter of SwiftUI, this hasn't been my experience—but I understand that a lot of people struggle with it. I think it's pretty opinionated, and if you stick to the "preferred" way of doing things, life is easier. The biggest (and known) issue with SwiftUI is the complex error messages you get, and the fact that the type checker will give up and ask you to break up your view into "distinct sub-expressions." Really the issue is almost never the complexity of a view, but some simple syntax error (passing the wrong type to a function, etc).
      - troupo 2y ago
        > The biggest (and known) issue with Isn't this literally what the person above is talking about? > Really the issue is almost never the complexity of a view, but some simple syntax error (passing the wrong type to a function, etc). The issue is that this is a big, known, common problem that cannot be solved, apparently
        2y ago
- jchw 2y ago
  My only fear with Swift is Apple. The language itself seems largely fine, very interesting even, which makes me feel deeply conflicted. While Apple has been big on pushing multi-platform Swift right now and distancing itself a bit from the Swift branding in some ways (e.g. it having its own GitHub organization) they've historically had quite an ebb and flow to this behavior. If their priorities changed, what happens to the non-Apple projects that adopted Swift? It would be better if there were multiple parties that had stake and some control in the future of Swift. I have similar worries with Microsoft and .NET, although it's a bit different owing to the fact that Microsoft is quite a different company with different problems. It's actually kind of bizarre that it never really felt like Google was a problem for Go, but I guess that's because unlike Apple Swift and Microsoft .NET, Go mostly targets and is almost entirely developed on platforms that Google has little control over. (Though that doesn't mean that their presence is entirely unnoticed, but even stuff like the module proxy has been more well-received than expected. It's an odd area where Google has managed to maintain some goodwill, though it could evaporate over night.)
  - turnsout 2y ago
    I think you hit the nail on the head. By extending Go to many platforms, it doesn't feel like you're using a corporate-sponsored language (though you are). The Swift team is aware that they need to help the language thrive in other contexts, which is why they're working on projects like Embedded Swift [0]. I hope they fully embrace wasm as well! [0]: https://www.swift.org/getting-started/embedded-swift/
  - odyssey7 2y ago
    The rug-pull of Swift from TensorFlow came from Google rather than Apple.
    - jchw 2y ago
      Hey, I didn't say you should trust other Google projects. The Google Graveyard meme should be enough evidence of that.
    - saagarjha 2y ago
- jbverschoor 2y ago
  Either as shebang/interpreted script, or just compile to a binary for great startup speed. I actually only recently found out you could use swift for scripting. Turns out, you can also access all the other Apple APIs :-) #!/usr/bin/env swift I made this small "shebang thing runner script" that either runs your script interpreted, or compiles and executes it. Depending on if you're on a TTY or not. I'm also changing it to simply check for the number of executions since last modified, and then compile. In some cases the extra time is well appreciated. You still get the convenience of interpreting, but also the performance of native. It's basically a drop-in replacement: #/path/to/autocompile_or_interpret_swift Very noticeable difference. real 0m0.212s user 0m0.159s sys 0m0.045s vs real 0m0.014s user 0m0.004s sys 0m0.008s
  - turnsout 2y ago
    Ha, nice! I've used the Swift shebang before, but honestly once you have something that works as a "script," it's so easy to convert it to a real command line utility via Swift Argument Parser [0] that I usually spend the 5 minutes to wrap it up. [0]: https://github.com/apple/swift-argument-parser
    - jbverschoor 2y ago
      That's pretty sweet the argparser It's kind of nice to be able to access all native libraries. I usually use ruby, but having something compiled and strict is super nice. Shellscripting it one big minefield. Compiling is a simple step ofc. But it's nice to only have the scriptfile and it's nice to not have your directory cluttered with binaries. I'll see if I can post it tomorrow. It's very small anyway
    - saagarjha 2y ago
      Yes, but then you have to compile it to use it, since scripts can’t use dependencies. Personally I just use getopt which sounds insane but it’s part of the standard library (imported from C).
- satvikpendem 2y ago
  > Ignore the haters—Swift is an enjoyable and productive language Sure, if you are on Apple devices. If you are not, better to use other languages like Rust, Go, or even Dart.
  - palata 2y ago
    Is Dart still a thing? Genuinely interested.
    - cogman10 2y ago
      Yup. It got it's second life because Flutter adopted it as it's language. It was pretty dead for a few years (despite what the googlers will tell you...)
    - FuturisticGoo 2y ago
      It absolutely is and its a pleasant language to work with. Although it is in a kinda-symbiotic relationship with Flutter, I've found myself using it for small scripts and cli tools instead of Python because of its strong+static typing with null safety. Relevant to the topic, Dart (and Flutter) supports targeting wasm.
    - mdhb 2y ago
      Not only a thing but is growing at a crazy rate. Easily my favourite language out there for the last few years.
  - izacus 2y ago
    The direct competitor to Swift is most likely Kotlin and I bet it'll win out as a cross platform solution of choice in a couple of years as KMP stabilizes.
nofunsir 2y ago
Just what I've been waiting for! Now about that JVM support for Swift...?
- isodev 2y ago
  You’re mixing up the visions :) JVM support was the buzzword for last year’s “Swift on the Server for realz”.
  - detourdog 2y ago
    I thought that was when WebObjects switched to Java.
    - isodev 2y ago
      Ah, also known as Project Wonder. Good times
- zerr 2y ago
  Why not Swift .NET? :)
  - pjmlp 2y ago
    Because we already have F# with much better tooling. :)
- watusername 2y ago
  Don't forget about BEAM/Erlang interop too, now we are getting truly distributed... :P
isodev 2y ago
Interesting proposal though it does sound a bit too general. “Improve cross compilation”… current Swift tools are barely keeping it together for the “happy path” of building for Apple devices (it’s not that happy). It would be cool to expand into wasm/wasi as long as it doesn’t come at the expense of other desperately needed improvements. Rust, Go and others have been building WASM 0.2 support for many years, they currently have a “just works” support for WASI. It would be a long time until Swift is even remotely ready for something like this and I don’t feel there is a burning need to have “yet another wasm platform”.
- elpakal 2y ago
  > current Swift tools are barely keeping it together for the “happy path” of building for Apple devices (it’s not that happy) I agree, but I'm telling myself this is only a temporary pain caused by the changes for supporting Swift 6 language mode. Are you talking about something else?
  - isodev 2y ago
    Temporary but measured in years and forced on every Swift dev out there … hard to dismiss. My comment was not about that though, I was more thinking about the super slow build times, unreliable SPM with strange limitations, Xcode still shows errors while reporting a successful build, Previews not previewing, etc.
    - deergomoo 2y ago
      Don’t forget our old friend “The compiler is unable to type-check this expression in reasonable time”
  - refulgentis 2y ago
    For context, I was saying that same thing in 2017*, because it seemed obvious, especialy given the elite consensus was it was obvious SwiftUI was being introduced to allow full cross platform development, including web. In retrospect, I was starstruck by the people I learned programming from, and Apple Neue funds software engineering, especially developer tooling, to the point it is not actively harmful, as opposed to not painful, and very opposed to not-harmful-and-not-painful-on-not-our-platforms. * Of course, not for Swift 6 Language Mode™, the thing is, there's always been a Huge Project that's launching, but not landing...
deleted 2y ago
[deleted]
zerr 2y ago
Can we have a proper Windows support? i.e. with all the batteries/libraries included.
- mdhb 2y ago
  Apple barely invest in their own platform, they sure as hell aren’t going to invest the resources required to do this. Flutter on the other hand… genuinely does a great job of cross platform and I’d argue Dart is a nicer language too.
  - zerr 2y ago
    Yes, but Dart is only a single-threaded application language, while Swift can be a proper systems language, something between C++ and Rust, in terms of usability and safety. Golang killer, when it comes to high-level systems programming.
troupo 2y ago
I wish they had a vision for the language and not "we throw everything and the kitchen sink at it so that our compiler often cannot handle even the simplest SwiftUI components and takes ages to do anything"
WD-42 2y ago
Is there a compelling reason to use Swift over Rust for anything other than Apple development in 2025?
- saagarjha 2y ago
  It’s a somewhat more pleasant Rust, with nicer syntax, where you get an additional option wherever you would have weird ownership semantics to just pay some extra cost to have the language solve it for you. Whether that is worth dealing with a worse toolchain is something for you to decide.
  - zozbot234 2y ago
    You can do the same in Rust of course, it just takes some boilerplate. Whether the Swift approach is genuinely "nicer" is probably a matter of personal opinion.
    - saagarjha 2y ago
      Niceness is an opinion but I don't think "you need more boilerplate so it is nicer" is one that many people share. When discussing aesthetics as one does here it's not very difficult to rank obvious choices like these.
  - pcwalton 2y ago
    This is sort of true in theory, but in practice there's a major difference in that nearly all the libraries in Swift use a reference-counted (i.e. GC'd) shared-everything model, while in Rust nearly all the libraries use ownership and borrowing. The "normal path" of least friction in Swift is a reference-counted world, while the "normal path" in Rust is the ownership-and-borrowing world. This is not a knock on Swift--it's really the inevitable outcome of seamless compatibility with the COM-like model of Objective-C and Core Foundation being a guiding principle of the language.
    - zozbot234 2y ago
      > The "normal path" of least friction in Swift is a reference-counted world, while the "normal path" in Rust is the ownership-and-borrowing world. Of course, but the borrow checker in Rust does a lot to smooth out that potential friction; and Swift will also include comparable facilities starting from Swift 6, which will finally achieve comprehensive safety including in concurrent code. > it's really the inevitable outcome of seamless compatibility with the COM-like model of Objective-C There's a comparable focus in Rust of getting not-quite-seamless compatibility with the COM-like model of... well duh, COM. See Microsoft's efforts at getting low-level components rewritten in Rust into their OS's.
singularity2001 2y ago
Hopefully they make interface types available to the runtime. So you can read/write wasm struct properties from the host without all the usual glue code cancer
cyberax 2y ago
Can we have at least SOME form of JIT compilation for iOS? The technological limitations of not being able to use it are just ridiculous at this point. And for no real reason, except that apparently Apple's whole ecosystem can crash and burn if somebody looks at it wrongly.

202 points by LucidLynx 2y ago

Ignore the haters—Swift is an enjoyable and productive language that gives you a lot of advanced features if you want them, but lets you ignore them and almost treat it like a scripting language. Adding first-class wasm support could help it become a more reasonable choice for development outside the Apple platform.

solardev 2y ago
Wow, thanks for saying this. I had no idea it was even usable outside the Apple ecosystem. Seems like other IDEs support it too (https://www.swift.org/tools/ https://www.swift.org/tools/). How would UIs work on other platforms, though?
- thewebguyd 2y ago
  > How would UIs work on other platforms, though? I think for right now, you'd have to use the C interop and link against something like GTK or other GUI library. I don't think SwiftUI specifically would ever work well cross-platform, it has so many Apple-isms. There's also Swift/Win32, but it's MVC. You could also use the interop and use QT as well. I don't think any of those are necessarily good solutions, but they are there.
  - wahnfrieden 2y ago
    TokamakUI And https://skip.tools https://skip.tools
    - solardev 2y ago
      Hmm, Tokamak seems abandoned (hasn't been touched in years) and skip.tools requires xCode and is Android-only =/ Thank you though.
      - wahnfrieden 2y ago
        Yes there’s nothing all in one yet. But these are promising directions. Tokamak isn’t abandoned, members are involved in core Swift changes that it depends on and have made progress recently with embedded Swift.
  - achierius 2y ago
    What sort of things are you referring to when you say "Apple-isms"? Not that I doubt your claim -- I just don't do much UI development so I don't have a good reference for what things might be 'platform specific' in that way.
- dagmx 2y ago
  As with other languages, you’d need bindings to another UI framework. In that sense, I wish SwiftUI had a different name because it seems intrinsic to Swift when it’s really no different than UIKit. There’s stuff like SwiftCrossUI that does multiple backend bindings https://github.com/stackotter/swift-cross-ui https://github.com/stackotter/swift-cross-ui And Qt was exploring some bindings using the new C++ interoperability.
  - loic-sharma 2y ago
    There’s also Shaft, which is Flutter ported to Swift: https://github.com/ShaftUI/Shaft https://github.com/ShaftUI/Shaft Like Flutter, this paints everything itself. It doesn’t need to bind to a UI framework directly. Instead, it needs the platform to provide primitives like a surface to draw into and input events.
jonhohle 2y ago
Rust, Go, and Swift were all coming up around the same time. Rust looked ugly, Go underwhelmed me, and Swift aeemed like the best “language” at the time, with many opinions that aligned with my own. Having now spent time in all three, swift feels the most ergonomic and has features that make me feel productive. I still feel like there isn’t much “there” in Go, and rust makes me feel like I’m solving for the compiler rather than working on whatever problem I was needing to work on. Edit to add: SwiftUI, however, is a mess that I loathe. I may be in the minority of enjoying the IoC choices in Interface Builder and AppKit.
- jkubicek 2y ago
  SwiftUI is just amazing for the first 30 minutes you use it... then you make a minor syntax error deep in some nested views and you're selectively commenting out coded blocks to hone in on the error like a caveman. It makes print-statement debugging look cutting edge.
  - turnsout 2y ago
    As an early adopter of SwiftUI, this hasn't been my experience—but I understand that a lot of people struggle with it. I think it's pretty opinionated, and if you stick to the "preferred" way of doing things, life is easier. The biggest (and known) issue with SwiftUI is the complex error messages you get, and the fact that the type checker will give up and ask you to break up your view into "distinct sub-expressions." Really the issue is almost never the complexity of a view, but some simple syntax error (passing the wrong type to a function, etc).
    - troupo 2y ago
      > The biggest (and known) issue with Isn't this literally what the person above is talking about? > Really the issue is almost never the complexity of a view, but some simple syntax error (passing the wrong type to a function, etc). The issue is that this is a big, known, common problem that cannot be solved, apparently
      - 2y ago
jchw 2y ago
My only fear with Swift is Apple. The language itself seems largely fine, very interesting even, which makes me feel deeply conflicted. While Apple has been big on pushing multi-platform Swift right now and distancing itself a bit from the Swift branding in some ways (e.g. it having its own GitHub organization) they've historically had quite an ebb and flow to this behavior. If their priorities changed, what happens to the non-Apple projects that adopted Swift? It would be better if there were multiple parties that had stake and some control in the future of Swift. I have similar worries with Microsoft and .NET, although it's a bit different owing to the fact that Microsoft is quite a different company with different problems. It's actually kind of bizarre that it never really felt like Google was a problem for Go, but I guess that's because unlike Apple Swift and Microsoft .NET, Go mostly targets and is almost entirely developed on platforms that Google has little control over. (Though that doesn't mean that their presence is entirely unnoticed, but even stuff like the module proxy has been more well-received than expected. It's an odd area where Google has managed to maintain some goodwill, though it could evaporate over night.)
- turnsout 2y ago
  I think you hit the nail on the head. By extending Go to many platforms, it doesn't feel like you're using a corporate-sponsored language (though you are). The Swift team is aware that they need to help the language thrive in other contexts, which is why they're working on projects like Embedded Swift [0]. I hope they fully embrace wasm as well! [0]: https://www.swift.org/getting-started/embedded-swift/
- odyssey7 2y ago
  The rug-pull of Swift from TensorFlow came from Google rather than Apple.
  - jchw 2y ago
    Hey, I didn't say you should trust other Google projects. The Google Graveyard meme should be enough evidence of that.
  - saagarjha 2y ago
jbverschoor 2y ago
Either as shebang/interpreted script, or just compile to a binary for great startup speed. I actually only recently found out you could use swift for scripting. Turns out, you can also access all the other Apple APIs :-) #!/usr/bin/env swift I made this small "shebang thing runner script" that either runs your script interpreted, or compiles and executes it. Depending on if you're on a TTY or not. I'm also changing it to simply check for the number of executions since last modified, and then compile. In some cases the extra time is well appreciated. You still get the convenience of interpreting, but also the performance of native. It's basically a drop-in replacement: #/path/to/autocompile_or_interpret_swift Very noticeable difference. real 0m0.212s user 0m0.159s sys 0m0.045s vs real 0m0.014s user 0m0.004s sys 0m0.008s
- turnsout 2y ago
  Ha, nice! I've used the Swift shebang before, but honestly once you have something that works as a "script," it's so easy to convert it to a real command line utility via Swift Argument Parser [0] that I usually spend the 5 minutes to wrap it up. [0]: https://github.com/apple/swift-argument-parser
  - jbverschoor 2y ago
    That's pretty sweet the argparser It's kind of nice to be able to access all native libraries. I usually use ruby, but having something compiled and strict is super nice. Shellscripting it one big minefield. Compiling is a simple step ofc. But it's nice to only have the scriptfile and it's nice to not have your directory cluttered with binaries. I'll see if I can post it tomorrow. It's very small anyway
  - saagarjha 2y ago
    Yes, but then you have to compile it to use it, since scripts can’t use dependencies. Personally I just use getopt which sounds insane but it’s part of the standard library (imported from C).
satvikpendem 2y ago
> Ignore the haters—Swift is an enjoyable and productive language Sure, if you are on Apple devices. If you are not, better to use other languages like Rust, Go, or even Dart.
- palata 2y ago
  Is Dart still a thing? Genuinely interested.
  - cogman10 2y ago
    Yup. It got it's second life because Flutter adopted it as it's language. It was pretty dead for a few years (despite what the googlers will tell you...)
  - FuturisticGoo 2y ago
    It absolutely is and its a pleasant language to work with. Although it is in a kinda-symbiotic relationship with Flutter, I've found myself using it for small scripts and cli tools instead of Python because of its strong+static typing with null safety. Relevant to the topic, Dart (and Flutter) supports targeting wasm.
  - mdhb 2y ago
    Not only a thing but is growing at a crazy rate. Easily my favourite language out there for the last few years.
- izacus 2y ago
  The direct competitor to Swift is most likely Kotlin and I bet it'll win out as a cross platform solution of choice in a couple of years as KMP stabilizes.

nofunsir 2y ago

Just what I've been waiting for! Now about that JVM support for Swift...?

isodev 2y ago
You’re mixing up the visions :) JVM support was the buzzword for last year’s “Swift on the Server for realz”.
- detourdog 2y ago
  I thought that was when WebObjects switched to Java.
  - isodev 2y ago
    Ah, also known as Project Wonder. Good times
zerr 2y ago
Why not Swift .NET? :)
- pjmlp 2y ago
  Because we already have F# with much better tooling. :)
watusername 2y ago
Don't forget about BEAM/Erlang interop too, now we are getting truly distributed... :P

isodev 2y ago

Interesting proposal though it does sound a bit too general. “Improve cross compilation”… current Swift tools are barely keeping it together for the “happy path” of building for Apple devices (it’s not that happy). It would be cool to expand into wasm/wasi as long as it doesn’t come at the expense of other desperately needed improvements. Rust, Go and others have been building WASM 0.2 support for many years, they currently have a “just works” support for WASI. It would be a long time until Swift is even remotely ready for something like this and I don’t feel there is a burning need to have “yet another wasm platform”.

elpakal 2y ago
> current Swift tools are barely keeping it together for the “happy path” of building for Apple devices (it’s not that happy) I agree, but I'm telling myself this is only a temporary pain caused by the changes for supporting Swift 6 language mode. Are you talking about something else?
- isodev 2y ago
  Temporary but measured in years and forced on every Swift dev out there … hard to dismiss. My comment was not about that though, I was more thinking about the super slow build times, unreliable SPM with strange limitations, Xcode still shows errors while reporting a successful build, Previews not previewing, etc.
  - deergomoo 2y ago
    Don’t forget our old friend “The compiler is unable to type-check this expression in reasonable time”
- refulgentis 2y ago
  For context, I was saying that same thing in 2017*, because it seemed obvious, especialy given the elite consensus was it was obvious SwiftUI was being introduced to allow full cross platform development, including web. In retrospect, I was starstruck by the people I learned programming from, and Apple Neue funds software engineering, especially developer tooling, to the point it is not actively harmful, as opposed to not painful, and very opposed to not-harmful-and-not-painful-on-not-our-platforms. * Of course, not for Swift 6 Language Mode™, the thing is, there's always been a Huge Project that's launching, but not landing...

deleted 2y ago

[deleted]

zerr 2y ago

Can we have a proper Windows support? i.e. with all the batteries/libraries included.

mdhb 2y ago
Apple barely invest in their own platform, they sure as hell aren’t going to invest the resources required to do this. Flutter on the other hand… genuinely does a great job of cross platform and I’d argue Dart is a nicer language too.
- zerr 2y ago
  Yes, but Dart is only a single-threaded application language, while Swift can be a proper systems language, something between C++ and Rust, in terms of usability and safety. Golang killer, when it comes to high-level systems programming.

troupo 2y ago

I wish they had a vision for the language and not "we throw everything and the kitchen sink at it so that our compiler often cannot handle even the simplest SwiftUI components and takes ages to do anything"

WD-42 2y ago

Is there a compelling reason to use Swift over Rust for anything other than Apple development in 2025?

saagarjha 2y ago
It’s a somewhat more pleasant Rust, with nicer syntax, where you get an additional option wherever you would have weird ownership semantics to just pay some extra cost to have the language solve it for you. Whether that is worth dealing with a worse toolchain is something for you to decide.
- zozbot234 2y ago
  You can do the same in Rust of course, it just takes some boilerplate. Whether the Swift approach is genuinely "nicer" is probably a matter of personal opinion.
  - saagarjha 2y ago
    Niceness is an opinion but I don't think "you need more boilerplate so it is nicer" is one that many people share. When discussing aesthetics as one does here it's not very difficult to rank obvious choices like these.
- pcwalton 2y ago
  This is sort of true in theory, but in practice there's a major difference in that nearly all the libraries in Swift use a reference-counted (i.e. GC'd) shared-everything model, while in Rust nearly all the libraries use ownership and borrowing. The "normal path" of least friction in Swift is a reference-counted world, while the "normal path" in Rust is the ownership-and-borrowing world. This is not a knock on Swift--it's really the inevitable outcome of seamless compatibility with the COM-like model of Objective-C and Core Foundation being a guiding principle of the language.
  - zozbot234 2y ago
    > The "normal path" of least friction in Swift is a reference-counted world, while the "normal path" in Rust is the ownership-and-borrowing world. Of course, but the borrow checker in Rust does a lot to smooth out that potential friction; and Swift will also include comparable facilities starting from Swift 6, which will finally achieve comprehensive safety including in concurrent code. > it's really the inevitable outcome of seamless compatibility with the COM-like model of Objective-C There's a comparable focus in Rust of getting not-quite-seamless compatibility with the COM-like model of... well duh, COM. See Microsoft's efforts at getting low-level components rewritten in Rust into their OS's.

singularity2001 2y ago

Hopefully they make interface types available to the runtime. So you can read/write wasm struct properties from the host without all the usual glue code cancer

cyberax 2y ago

Can we have at least SOME form of JIT compilation for iOS? The technological limitations of not being able to use it are just ridiculous at this point. And for no real reason, except that apparently Apple's whole ecosystem can crash and burn if somebody looks at it wrongly.