[HN Gopher] A Vision for WebAssembly Support in Swift
___________________________________________________________________
A Vision for WebAssembly Support in Swift
Author : LucidLynx
Score : 200 points
Date : 2025-04-05 13:58 UTC (1 days ago)
(HTM) web link (forums.swift.org)
(TXT) w3m dump (forums.swift.org)
| turnsout wrote:
| 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 wrote:
| 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/).
|
| How would UIs work on other platforms, though?
| thewebguyd wrote:
| > 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 wrote:
| TokamakUI
|
| And https://skip.tools
| solardev wrote:
| Hmm, Tokamak seems abandoned (hasn't been touched in
| years) and skip.tools requires xCode and is Android-only
| =/
|
| Thank you though.
| wahnfrieden wrote:
| 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 wrote:
| 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 wrote:
| 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
|
| And Qt was exploring some bindings using the new C++
| interoperability.
| loic-sharma wrote:
| There's also Shaft, which is Flutter ported to Swift:
|
| 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 wrote:
| 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 wrote:
| 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 wrote:
| 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 wrote:
| > 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
| grandempire wrote:
| Yeah. My understanding is the design of type inference is
| flawed and requires exponential complexity to resolve and
| it's not fixable without breaking change.
|
| Why this is not a top priority before literally anything
| else?
| yAak wrote:
| I agree with you, but sounds like a rough problem:
|
| https://danielchasehooper.com/posts/why-swift-is-slow/
| saagarjha wrote:
| The author is welcome to add type annotations if they
| want...?
| grandempire wrote:
| ?? No other language times out error checking. This is
| insanity.
| saagarjha wrote:
| Not regularly but many languages have type systems that
| are algorithmically worse, like TypeScript
| 9dev wrote:
| As a user, I couldn't care less about the algorithmic
| beauty of the type system if it works, lets me type
| complex things reliably, and is fast enough to stay out
| of my way. Does it do that by being a mess of duct table
| and plywood? Totally fine for me.
| saagarjha wrote:
| Sure, but often the duct tape and plywood makes it
| difficult to make things that are reliable and stay out
| of your way.
| troupo wrote:
| And yet TypeScript doesn't fail with a cryptic
| nonsensical error just because you have the impossible
| component with an unfathomable number of two nested
| lists, like in SwiftUI.
| saagarjha wrote:
| Algorithmically worse doesn't mean worse in practice
| grandempire wrote:
| Can you show a common line of type script that will take
| exponential complexity for typescript to resolve?
| saagarjha wrote:
| I think you misunderstood my comment.
| troupo wrote:
| Everyone misunderstood your reply.
|
| Perhaps it was a pure academic reply? Because reality
| always trumps theory.
| grandempire wrote:
| My understanding is you are saying TypeScript has a
| similar complexity problem in its type system as Swift.
|
| I am wondering if you have a common example that would
| timeout or have problems.
|
| If not then I struggle to see what similarity you are
| seeing.
|
| (Genuine question, I am interested in what other
| languages do)
| cyberax wrote:
| Yeah. I have a bunch of code with bog-standard linear
| algebra classes (vec2, vec3, mat2, ...). No generics, no
| nothing. Just simple classes with operator overloading.
|
| After the recent minor XCode upgrade, Swift can't deduce
| the type for an expression `((v2 * scalar1) * v3)`, I
| have to split `let tmp1=v2*scalar1` for it to work.
|
| Like, wtf, Apple?
| grandempire wrote:
| It's even possible to compile on one machine and timeout
| on another.
| troupo wrote:
| > deep in some nested views
|
| It doesn't even have to be deep. I ran into this issue on
| very few quite simple components. The compiler just gives
| up because somehow swift's type system makes it impossible
| to figure out
| bjustin wrote:
| This problem is very real. There is at least an ok way to
| avoid it getting too bad: make lots of View and
| ViewModifier structs, with each one having smallish amounts
| of code. Split them up to the extent that it feels silly.
|
| As an added bonus, this is also the way to get good
| performance at run time. It helps minimize how many views
| need to get re-evaluated when something changes.
| cosmic_cheese wrote:
| This is more or less how I feel too. Writing Swift feels
| good, and once you make a habit of avoiding code smells that
| trip up SourceKit, syntax coloration and all that works well
| enough too. SwiftUI on the other hand gets to be a mess for
| anything larger than small components and collection view
| cells.
|
| And so I write pure code UIKit most of the time. It's not
| trendy but it's very effective.
| ben_w wrote:
| I agree about SwiftUI. It's something I want to like, but
| everything about it... no.
|
| For me, SwiftUI does exactly two things better than UIKit:
| tables and collection views. For everything else, it's so
| much easier to get stuff done with UIKit*, regardless of if
| I'm working with Interface Builder or making UI in code (as
| per various projects I've dropped into).
|
| _In theory_ , reactive UI is good. In practice, at least in
| the case of SwiftUI, the "magic" data passing does sometimes
| fail -- perhaps someone put in the wrong @ on the property --
| and then you've got to debug some weird magic, and if there's
| a sensible place to put a breakpoint for that kind of problem
| I have yet to learn it.
|
| _In theory_ , the UI is reusable across all Apple platforms.
| In practice, the nature of the user experience is so
| different that actually trying this makes it suck for
| everyone -- you don't want finger-sized buttons on a mouse-
| driven UI or tiny mouse-suitable click areas for a mobile UI,
| and I have no idea what the user expectations are for tvOS or
| WatchOS despite having written apps for both because hardly
| anyone shares their experiences and lessons learned.
|
| _In theory_ , having the code be the source of truth for the
| WYSIWYG editor is great. In practice, the WYSIWYG editor
| keeps giving up because of e.g. a compiler error, and decides
| to stop forever until you manually resume the preview.
|
| * I'm mostly on iOS rather than macOS, but I'd assume UIKit
| and AppKit have the same strengths and weaknesses.
| cosmic_cheese wrote:
| Even outside of iOS I'm not fully convinced that
| declarative/reactive is "the way". Jetpack Compose while
| not as bad as SwiftUI in some ways shares many of its
| problems, including the magic, inscrutable stack traces,
| and challenges in reasoning. Past a certain level of
| complexity imperative UI feels more manageable.
| saagarjha wrote:
| > In theory, the UI is reusable across all Apple platforms.
|
| This is the practice (when people are lazy). The theory
| that Apple presented was that you are supposed to tweak
| your UI for each platform and share some of the common
| code.
| jchw wrote:
| 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 wrote:
| 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 wrote:
| The rug-pull of Swift from TensorFlow came from Google rather
| than Apple.
| jchw wrote:
| Hey, I didn't say you should trust _other_ Google projects.
| The Google Graveyard meme should be enough evidence of
| that.
| saagarjha wrote:
| It came from Google because they couldn't trust Apple,
| actually. Also Chris Lattner having the focus of a
| goldfish.
| geodel wrote:
| He has got his _mojo_ back now.
| pjmlp wrote:
| While the efforts are laudable, it remains to be seen
| where it will stand against regular Python and Julia,
| that actually have support from card vendors directly.
| Rohansi wrote:
| Not sure if you're aware or not but .NET these days can
| (officially) target pretty much anything - not just Windows.
| Usage on Linux definitely picked up vs. Windows because Linux
| servers are cheaper. Android/iOS is there. WebAssembly is
| also there.
| pjmlp wrote:
| Kind of, still misses a few platforms that have had JVM
| support outside mainstream computing, but yeah mostly great
| experience for target platforms.
|
| The IDE story is a bit complicated though, either you go
| for Rider, or have to delve into the internal politics of
| VSCode vs VS, and features that VSCode will never get
| because there are those VS licenses to sell.
| jbverschoor wrote:
| 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 wrote:
| 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 wrote:
| 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 wrote:
| 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 wrote:
| > _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 wrote:
| Is Dart still a thing? Genuinely interested.
| cogman10 wrote:
| 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 wrote:
| 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 wrote:
| Not only a thing but is growing at a crazy rate. Easily my
| favourite language out there for the last few years.
| izacus wrote:
| 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 wrote:
| Just what I've been waiting for! Now about that JVM support for
| Swift...?
| isodev wrote:
| You're mixing up the visions :) JVM support was the buzzword
| for last year's "Swift on the Server for realz".
| detourdog wrote:
| I thought that was when WebObjects switched to Java.
| isodev wrote:
| Ah, also known as Project Wonder. Good times
| zerr wrote:
| Why not Swift .NET? :)
| pjmlp wrote:
| Because we already have F# with much better tooling. :)
| watusername wrote:
| Don't forget about BEAM/Erlang interop too, now we are getting
| truly distributed... :P
| isodev wrote:
| 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 wrote:
| > 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 wrote:
| 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 wrote:
| Don't forget our old friend "The compiler is unable to
| type-check this expression in reasonable time"
| refulgentis wrote:
| 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(tm), the thing is,
| there's always been a Huge Project that's launching, but not
| landing...
| pjmlp wrote:
| Web was never part of SwiftUI story, where does that come
| from?
| erikrothoff wrote:
| Is this still a thing in Swift? I loved Swift 1, spent a
| couple of days upgrading to Swift 2, a week or more for Swift
| 3. At that point I just switched to React Native. I
| understand that iterating is generally a good thing, but the
| constant cykle breaking changes in the language was just too
| much.
| Daedren wrote:
| Yes. It feels like the language is being handled by
| academics who don't actually use it, Swift 6 really drives
| it down.
|
| The lack of Sendable support for Combine and half-assed
| support on Async Algorithms only makes it more painful to
| transition at this point in time.
| saagarjha wrote:
| Disagree about the academics point but Async Algorithms
| is basically an abandoned project at this point. There is
| someone working on it but the intention is that it
| evolves basically at the pace that the language does, but
| without the investment that the language gets. I would
| recommend against relying on anything going on there.
| elpakal wrote:
| Are you talking about Combine or Async Algorithms? This
| has been brought up before about Combine, but AA's repo
| still has some recent commits.
| saagarjha wrote:
| No, I'm talking about the latter. Combine is truly dead
| but the other repo is mired in an inability to make real
| changes, because that requires significant review effort,
| which is not really there. So it's just bugfixes and
| small tweaks.
| Daedren wrote:
| Between a dead Combine that no longer functions in Swift
| 6 or a severely handicapped AsyncSequence lacking basic
| features, where are developers supposed to turn to?
|
| All these projects like Async Algorithms,
| AsyncExtensions, Asynchrone, etc. are being born out of
| necessity.
|
| Deprecating Combine would be less of a problem if
| Sendable wasn't a hard requirement but it is.
| DidYaWipe wrote:
| Let's not forget the absurd insistence on "will change"
| semantics in onChange() instead of the far-more-useful
| notification "did change."
|
| And of course the brain-dead design of
| withObservationTracking, which only fires on the FIRST
| change of a value. I mean... by what definition is that
| "tracking?" It's goddamned useless, unless of course you
| implement the clumsy workaround of re-establishing
| observation tracking every (first) time it fires.
|
| Then there's the bizarre hypocrisy of evangelizing the
| "single source of truth" while telling everyone to prefer
| structs over classes in Swift. But structs are COPIED
| everywhere, which of course breaks the "single source of
| truth" on the first function call.
|
| I wasted so much time trying to conform to these "best
| practices" until I finally realized that the people
| promoting them don't know WTF they're doing. Then I went
| back to classes, injected the "single source" everywhere
| it was needed, and got to work adding functionality.
|
| And let's not even get into the half-assery that is
| SwiftUI... still, all these years later.
| iamkonstantin wrote:
| It's now almost a full year since Swift 6 (concurrency)
| was introduced, and I've spent a lot of time rewriting,
| debugging and generally tweaking things to make the
| compiler happy... The promise of "strict concurrency" is
| yet to yield any meaningful benefit, despite the huge
| cost of having it.
|
| I think the pursuit of some kind of semantic purity in
| the Swift language overshadows more practical needs and
| concerns. Making Swift too different from its neighbours
| like Kotlin and Rust also makes it harder to context
| switch. It now takes a lot more time and effort to get
| into the flow of developing native things for iOS...
| neonsunset wrote:
| .NET does pretty well as far as WASM support goes, unlike Go
| which is abysmal :)
|
| https://bootsharp.com/guide/llvm /
| https://github.com/elringus/bootsharp
| pjmlp wrote:
| Tell that to Typescript and Azure teams, what can we say when
| DevDiv decides to bet elsewhere?
| neonsunset wrote:
| I don't think they considered the terrible state of WASM in
| Go to be a challenge.
|
| But then again, we've already concluded it was a short-
| sighted decision.
| syspec wrote:
| > 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".
|
| I mean, well, it actually already exists? It's been around for
| a long time and works pretty great, with multithreading, access
| to JS objects, etc. The author of the linked thread topic is
| the original author of it.
|
| https://swiftwasm.org/
| refulgentis wrote:
| Amazing!
|
| Why are they framing it as a proposal if it's done? (if this
| comes across as Socratic, it is unintentional, I genuinely
| don't understand why the author would be posting a proposal
| when it is done)
|
| EDIT: My naive reading of
| https://github.com/swiftwasm/swift/issues is there's a lot,
| lot, to go. TL;DR: open from 2021, stdio FILE not available
| in WASILibc. Long version, filed in 2020 and open: "Pointers
| needed on WASILibc", "Make the toolchain work without Xcode
| installed", "Enable libdispatch or provide stubs for it",
| 2022 "canImport(Dispatch) is wrongly truthy on WASI target",
| "wasm lacks signal support" (broke/regression in Sept. 2024,
| still open)
| jagged-chisel wrote:
| > "Make the toolchain work without Xcode installed"
|
| On macOS. Works fine on Linux.
|
| This is such an easy ask. The only thing holding it back,
| imo, is Apple. Can't let the plebs bypass Xcode to develop
| on their Macs!
|
| My workaround is running a container with Linux Swift
| installed. Of course, I'm not targeting an Apple OS so I
| have the flexibility.
| Someone wrote:
| > Can't let the plebs bypass Xcode to develop on their
| Macs!
|
| AFAIK, they support that. https://www.swift.org/swiftly/d
| ocumentation/swiftly/getting-...:
|
| _"Overview
|
| To get started with swiftly you can download it from
| swift.org, and extract the package.
|
| On macOS you can either run the pkg installer from the
| command-line like this or just run the package by double-
| clicking on it (not recommended):
| installer -pkg swift-x.y.z.pkg -target
| CurrentUserHomeDirectory
|
| Now run swiftly init to finish the installation:
| ~/usr/local/bin/swiftly init
|
| Swiftly will install itself and download the latest
| available Swift toolchain."_
| isodev wrote:
| I think that's WASI Preview 1 that's currently supported by
| swiftwasm (and I don't think the spec implementation is even
| complete), not the current WASI 0.2. Preview 1 was the
| current status quo about 2 years ago.
|
| Writing WASM in Swift so it can only be run by a Swift
| runtime also misses out on a huge aspect of that "bring your
| language" approach to wasm. It should support enough of the
| spec so a current wasm binary compiled from say Go can be
| executed in a WASI runtime powered by Swift and vis-versa.
| It's a long way to get there.
| umvi wrote:
| Go's wasm is pretty bad. Rust's is good though.
| cookiengineer wrote:
| > Rust, Go and others have been building WASM 0.2 support for
| many years, they currently have a "just works" support...
|
| Can confirm. I was pretty stubborn and wanted to use Go to
| build a UI in a webview/webview using local app, but oh my,
| js.Value in Go is so much pain to deal with. A lot of things in
| the JS world don't integrate nicely with Go as a language (e.g.
| the difference of Go channels and JS Promises, or magical enum
| values _and_ URL patterns on the same properties like in the
| Fetch API)
|
| Long story short, I am now around 3 months into building a
| WebASM bindings and components framework, and it's still a lot
| of work until I am on the functionality level of TSX files. [1]
| All those Web/DOM/Browser APIs are kinda hard to integrate into
| the Go world, especially if you're as stubborn as me and want
| to have a real typed bindings API that uses Go's native data
| types.
|
| [1] https://github.com/cookiengineer/gooey
| zerr wrote:
| Can we have a proper Windows support? i.e. with all the
| batteries/libraries included.
| mdhb wrote:
| 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 wrote:
| 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 wrote:
| 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 wrote:
| Is there a compelling reason to use Swift over Rust for anything
| other than Apple development in 2025?
| saagarjha wrote:
| 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 wrote:
| 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 wrote:
| 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 wrote:
| 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 wrote:
| > 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.
| bobbylarrybobby wrote:
| Some differences and advantages of swift are documented here:
| https://faultlore.com/blah/swift-abi/
| singularity2001 wrote:
| 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 wrote:
| 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.
___________________________________________________________________
(page generated 2025-04-06 23:01 UTC)