4 ms·

> First off, Swift has both memory & data race safety (as of v6) But v6 is not released yet, right?

by sesm 2y ago

wahnfrieden 2y ago
next month
worik 2y ago
> > First off, Swift has both memory & data race safety (as of v6) > But v6 is not released yet, right As of Swift 5 there is zero data race protection and the process model (DispatchQueues if memory serves) is woefully. No advantage over fork and much more convoluted I am well clear of the Apple development world now (thank goodness) but the tools were of very poor quality, albeit very nice looking, as of this time last year For the sake of my friends still in the world I hope Swift 6 is better, but I fear the dumpster fire that is Xcode is too far gone to rescue. The comparison with Rust demonstrates the utility of "design by committee ". Rust is far from perfect, but feels like the future where Swift feels like warmed up Objective C
- ninkendo 2y ago
  > As of Swift 5 there is zero data race protection and the process model (DispatchQueues if memory serves) is woefully. No advantage over fork and much more convoluted Swift Concurrency is the replacement for Dispatch and has been around since Swift 5.5 in (IIRC) 2021. It’s a completely different system, uses lightweight tasks (a la tokio in rust, or goroutines in go, etc), has a concept of “Sendable” for thread-safety a la rust’s Send, async/await, and a native `actor` type, among other things. Swift 5.5 didn’t get all the way towards rust-style data race safety due to a few things they had to make warnings instead of errors (to avoid breaking existing code), and introducing keywords like `@preconcurrency` when importing frameworks that predate Swift Concurrency, to facilitate incremental adoption. They’ve also been adding more checks in each minor release to tighten things up. IIUC Swift 6 is mainly going to turn all the warnings into proper errors and tweak some defaults so that you get proper data race protection on a default compile. Point is, it’s totally inaccurate to say that Dispatch Queues is all that exists in Swift 5. You’ve had much better stuff for a while now (although SC still has a ton of issues worth discussing.)
  - worik 2y ago
    > Swift 5.5 didn’t get all the way towards rust-style data race When I experimented with it it was trivial for one thread to interfere with another. So Swift got nowhere towards data race safety. Still stuck in the 1990s I know not what you mean "Swift Concurrency". When I was doing it all we had was DispatchQueue which was an obfuscation of `fork`. Quite shameful really. I think the main point is that Swift is a failure. "although SC still has a ton of issues worth discussing" once I would have cared, but this year (decade, century) I am just very glad putting meat in my fridge no longer depends on those rouges from Apple who treated me so badly when I was sweating so hard making software for their platforms (not to mention paying them so much money). In 2024, for a company like Apple, for their flagship developer offering, why would anyone still have "a ton of issues" with it? Apple is now an example of why popularity is a terrible metric to estimate quality of technical offerings. What a shame. How far the mighty have fallen
    - ezfe 2y ago
      Okay, so you're saying you don't know what Swift Concurrency is and they say Swift is a failure. Swift has async/await built into the language with many compile time guarantees of thread safety.
      - worik 2y ago
        > Okay, so you're saying you don't know what Swift Concurrency I just looked it up. It is Swift's version of async/await. That is a different thing from threads. I know what that is, used it a lot, because using threads was such a nightmare in Swift. > language with many compile time guarantees of thread safety From two separate threads you can access the same memory. No trouble (apart from crashes memory corruption....) at all. Async/await is always a bad idea, and without a garbage collector it is a nightmare (look at the mess Rust has gotten into). Whatever, async/await is no replacement for parallel programming with threads. It is a different beast.
        cube2222 2y ago
- wahnfrieden 2y ago
  Xcode 16 rewrote much of the autocomplete behaviors and the new engine is blazing fast in terms of UI blockage compared with 15, and stable. Everything to do with tagging etc not just completion itself.
  - worik 2y ago
    Can you get the profiler to do anything useful? Even comprehensible? We tried and tried but there was nothing we could use amongst the blinking lights and wonderful graphics.
    - wahnfrieden 2y ago
      Yes
  - kaladin_1 2y ago
    I don't know if this is irony or you've been in Apple ecosystem way too long. I had to do a very simple macOS app for my personal consumption recently and XCode dx is nothing to write home about. The only reason I finished the project there was that I couldn't set up vs code quickly for Swift/Cocoa project. I had to endure the slow compilation time, slow reaction time of the IDE UI. You make a change you keep seeing squiggly lines for a while, it's as though the UI is booting up each time. It was a horrible experience coming from IntelliJ and VS Code daily experience. Computer is 32Gb Apple M1 Pro. Imagine what will happen on some 8Gb i5 macbook.
    - wahnfrieden 2y ago
      Xcode 16?

> First off, Swift has both memory & data race safety (as of v6) But v6 is not released yet, right?

by sesm 2y ago

> First off, Swift has both memory & data race safety (as of v6) But v6 is not released yet, right?

wahnfrieden 2y ago

next month

worik 2y ago

> > First off, Swift has both memory & data race safety (as of v6) > But v6 is not released yet, right As of Swift 5 there is zero data race protection and the process model (DispatchQueues if memory serves) is woefully. No advantage over fork and much more convoluted I am well clear of the Apple development world now (thank goodness) but the tools were of very poor quality, albeit very nice looking, as of this time last year For the sake of my friends still in the world I hope Swift 6 is better, but I fear the dumpster fire that is Xcode is too far gone to rescue. The comparison with Rust demonstrates the utility of "design by committee ". Rust is far from perfect, but feels like the future where Swift feels like warmed up Objective C

ninkendo 2y ago
> As of Swift 5 there is zero data race protection and the process model (DispatchQueues if memory serves) is woefully. No advantage over fork and much more convoluted Swift Concurrency is the replacement for Dispatch and has been around since Swift 5.5 in (IIRC) 2021. It’s a completely different system, uses lightweight tasks (a la tokio in rust, or goroutines in go, etc), has a concept of “Sendable” for thread-safety a la rust’s Send, async/await, and a native `actor` type, among other things. Swift 5.5 didn’t get all the way towards rust-style data race safety due to a few things they had to make warnings instead of errors (to avoid breaking existing code), and introducing keywords like `@preconcurrency` when importing frameworks that predate Swift Concurrency, to facilitate incremental adoption. They’ve also been adding more checks in each minor release to tighten things up. IIUC Swift 6 is mainly going to turn all the warnings into proper errors and tweak some defaults so that you get proper data race protection on a default compile. Point is, it’s totally inaccurate to say that Dispatch Queues is all that exists in Swift 5. You’ve had much better stuff for a while now (although SC still has a ton of issues worth discussing.)
- worik 2y ago
  > Swift 5.5 didn’t get all the way towards rust-style data race When I experimented with it it was trivial for one thread to interfere with another. So Swift got nowhere towards data race safety. Still stuck in the 1990s I know not what you mean "Swift Concurrency". When I was doing it all we had was DispatchQueue which was an obfuscation of `fork`. Quite shameful really. I think the main point is that Swift is a failure. "although SC still has a ton of issues worth discussing" once I would have cared, but this year (decade, century) I am just very glad putting meat in my fridge no longer depends on those rouges from Apple who treated me so badly when I was sweating so hard making software for their platforms (not to mention paying them so much money). In 2024, for a company like Apple, for their flagship developer offering, why would anyone still have "a ton of issues" with it? Apple is now an example of why popularity is a terrible metric to estimate quality of technical offerings. What a shame. How far the mighty have fallen
  - ezfe 2y ago
    Okay, so you're saying you don't know what Swift Concurrency is and they say Swift is a failure. Swift has async/await built into the language with many compile time guarantees of thread safety.
    - worik 2y ago
      > Okay, so you're saying you don't know what Swift Concurrency I just looked it up. It is Swift's version of async/await. That is a different thing from threads. I know what that is, used it a lot, because using threads was such a nightmare in Swift. > language with many compile time guarantees of thread safety From two separate threads you can access the same memory. No trouble (apart from crashes memory corruption....) at all. Async/await is always a bad idea, and without a garbage collector it is a nightmare (look at the mess Rust has gotten into). Whatever, async/await is no replacement for parallel programming with threads. It is a different beast.
      - cube2222 2y ago
wahnfrieden 2y ago
Xcode 16 rewrote much of the autocomplete behaviors and the new engine is blazing fast in terms of UI blockage compared with 15, and stable. Everything to do with tagging etc not just completion itself.
- worik 2y ago
  Can you get the profiler to do anything useful? Even comprehensible? We tried and tried but there was nothing we could use amongst the blinking lights and wonderful graphics.
  - wahnfrieden 2y ago
    Yes
- kaladin_1 2y ago
  I don't know if this is irony or you've been in Apple ecosystem way too long. I had to do a very simple macOS app for my personal consumption recently and XCode dx is nothing to write home about. The only reason I finished the project there was that I couldn't set up vs code quickly for Swift/Cocoa project. I had to endure the slow compilation time, slow reaction time of the IDE UI. You make a change you keep seeing squiggly lines for a while, it's as though the UI is booting up each time. It was a horrible experience coming from IntelliJ and VS Code daily experience. Computer is 32Gb Apple M1 Pro. Imagine what will happen on some 8Gb i5 macbook.
  - wahnfrieden 2y ago
    Xcode 16?