6 ms·

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

by 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...
  - pjmlp 2y ago
    Web was never part of SwiftUI story, where does that come from?
    - refulgentis 2y ago
      You're absolutely right, never made any sense. I'm not comfy calling out specific names, but the sort of luminary who would have been featured on Daring Fireball over the years proposed this and took umbrage to this being pointed out at the time. I can think of 2 off the top of my head who specifically did this, one who went on about it until they saw SwiftUI x macOS 1.0 and that became their new drum to beat on. (i.e. the quality was low)
- erikrothoff 2y ago
  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 2y ago
    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 2y ago
      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 2y ago
        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 2y ago
        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 2y ago
        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.
neonsunset 2y ago
.NET does pretty well as far as WASM support goes, unlike Go which is abysmal :) https://bootsharp.com/guide/llvm https://bootsharp.com/guide/llvm / https://github.com/elringus/bootsharp https://github.com/elringus/bootsharp
- pjmlp 2y ago
  Tell that to Typescript and Azure teams, what can we say when DevDiv decides to bet elsewhere?
  - neonsunset 2y ago
    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 2y ago
> 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/ https://swiftwasm.org/
- refulgentis 2y ago
  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 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 2y ago
    > "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 2y ago
      > Can’t let the plebs bypass Xcode to develop on their Macs! AFAIK, they support that. https://www.swift.org/swiftly/documentation/swiftly/getting-started/ https://www.swift.org/swiftly/documentation/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.”
umvi 2y ago
Go's wasm is pretty bad. Rust's is good though.
cookiengineer 2y ago
> 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 https://github.com/cookiengineer/gooey

by isodev 2y ago

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...
- pjmlp 2y ago
  Web was never part of SwiftUI story, where does that come from?
  - refulgentis 2y ago
    You're absolutely right, never made any sense. I'm not comfy calling out specific names, but the sort of luminary who would have been featured on Daring Fireball over the years proposed this and took umbrage to this being pointed out at the time. I can think of 2 off the top of my head who specifically did this, one who went on about it until they saw SwiftUI x macOS 1.0 and that became their new drum to beat on. (i.e. the quality was low)
erikrothoff 2y ago
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 2y ago
  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 2y ago
    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 2y ago
      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 2y ago
        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 2y ago
      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.

neonsunset 2y ago

.NET does pretty well as far as WASM support goes, unlike Go which is abysmal :) https://bootsharp.com/guide/llvm https://bootsharp.com/guide/llvm / https://github.com/elringus/bootsharp https://github.com/elringus/bootsharp

pjmlp 2y ago
Tell that to Typescript and Azure teams, what can we say when DevDiv decides to bet elsewhere?
- neonsunset 2y ago
  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 2y ago

> 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/ https://swiftwasm.org/

refulgentis 2y ago
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 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 2y ago
  > "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 2y ago
    > Can’t let the plebs bypass Xcode to develop on their Macs! AFAIK, they support that. https://www.swift.org/swiftly/documentation/swiftly/getting-started/ https://www.swift.org/swiftly/documentation/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.”

umvi 2y ago

Go's wasm is pretty bad. Rust's is good though.

cookiengineer 2y ago

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