8 ms·

For UI portion of their Mac OS version? What am I missing?

Wowfunhappy 2y ago
For everything. Swift is—at least in theory—a general purpose language, it's not exclusively for Apple technologies. > First off, Swift has both memory & data race safety (as of v6). It's also a modern language with solid ergonomics. > Something that matters to us a lot is OO. Web specs & browser internals tend to be highly object-oriented, and life is easier when you can model specs closely in your code. Swift has first-class OO support, in many ways even nicer than C++. > The Swift team is also investing heavily in C++ interop, which means there's a real path to incremental adoption, not just gigantic rewrites. https://x.com/awesomekling/status/1822236888188498031 https://x.com/awesomekling/status/1822236888188498031 https://news.ycombinator.com/item?id=41208836 https://news.ycombinator.com/item?id=41208836
- sheeshkebab 2y ago
  Swift is useless outside of macOS/iOS dev… the thing doesn’t even have namespacing. I don’t know for what reason someone would use it outside for Apple environment.
  - factotvm 2y ago
    You can disambiguate two types with the same name from different libraries, e.g. `Factotvm.URL` and `Foundation.URL`. Do you mean something more full-featured? You are not prefixing types with three letters, if that's what you think has to be done. I don't know if it's still the case, but there was an annoyance where you couldn't have a type with the same name as the package. But that is hardly a lack of namespaces.
  - refulgentis 2y ago
    You're right but this touches the hot stove. HN majority doesn't like hearing that ladybird et al might just be wandering around, even if the goal is catnip for the bleachers, and we should be skeptical this is the year of multiplatform Swift, because it wasn't last year if you actually tried it. Or the year before last. Or the year before that. Or the year before that year. Or the year before that one.
    - afavour 2y ago
      I’m slightly more ambivalent than you about it. Swift is a nice language and has better ergonomics than C++ and I imagine a Swift codebase might find more contributors than a C++ one (maybe I’m wrong about that!) I also think it’s separate from the dream of “multiplatform Swift”. For that you need a healthy package ecosystem that all works cross platform, Swift doesn’t have that. But a lot of Ladybird is written at a low enough level that it won’t matter so much.
      - refulgentis 2y ago
        Problem is Swift engineer supply is low, there's not a viable business case to learn Swift because it's not actually viable cross-platform for development unless you have $X00 million to throw at your macOS/iOS team to build it from scratch, platform by platform (to wit, sibling comment re: Arc Browser) So best case we're looking at: Swift isn't ready yet, the next major version will be, and we can't build UI with it, so we'll put in the effort in to bootstrap a cross-platform ecosystem and UI frameworks. Or maybe we'll just do our business logic in it? It's a confusing mess that is irrational. Even with great blessings of resources. ex. $X00M that Arc has obtained one incremental platform after a year. And "all" they had to do was Swift bindings for WinRT and connect it to the existing C++ engine. All of this is easy to justify if we treat it as an opportunity to shoot for how we wish software could work in theory, instead of practice. I hope I'm wrong but after being right the last few years, I'm willing to say it's naive wishcasting out loud, even though its boorish. I see it as unfortunately necessary, a younger me would be greatly misled by the conversations about it on HN. "We've decided to write the browser in Swift!" approaches parody levels of irresponsible resource management and is a case study in several solo engineer delusions that I also fall victim to. It's genuinely impossible for me to imagine anyone in my social circle of Apple devs, going back to 2007, who would think writing a browser engine in Swift is a good idea. I love Swift, used it since pre-1.0, immediately started shipping it after release, and that was the right decision. However, even given infinite resources and time, it is a poor fit for a browser engine, and an odd masochistic choice for cross-platform UI.
        lnrd 2y ago
  - oblio 2y ago
    Objective-C had some minimal adoption outside of Apple (probably due to NextStep nostalgia), so if Objective-C managed to get some traction, Swift will do it to, probably. However, Apple's history is very much stacked against Swift becoming a mainstream language outside of Apple's platform.
- 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.)
- deleted 2y ago
  [deleted]
- deleted 2y ago
  [deleted]
askonomm 2y ago
For non-UI portions as well, more from the horses mouth: https://x.com/awesomekling/status/1822236888188498031 https://x.com/awesomekling/status/1822236888188498031
deleted 2y ago
[deleted]

For everything. Swift is—at least in theory—a general purpose language, it's not exclusively for Apple technologies. > First off, Swift has both memory & data race safety (as of v6). It's also a modern language with solid ergonomics. > Something that matters to us a lot is OO. Web specs & browser internals tend to be highly object-oriented, and life is easier when you can model specs closely in your code. Swift has first-class OO support, in many ways even nicer than C++. > The Swift team is also investing heavily in C++ interop, which means there's a real path to incremental adoption, not just gigantic rewrites. https://x.com/awesomekling/status/1822236888188498031 https://x.com/awesomekling/status/1822236888188498031 https://news.ycombinator.com/item?id=41208836 https://news.ycombinator.com/item?id=41208836

sheeshkebab 2y ago
Swift is useless outside of macOS/iOS dev… the thing doesn’t even have namespacing. I don’t know for what reason someone would use it outside for Apple environment.
- factotvm 2y ago
  You can disambiguate two types with the same name from different libraries, e.g. `Factotvm.URL` and `Foundation.URL`. Do you mean something more full-featured? You are not prefixing types with three letters, if that's what you think has to be done. I don't know if it's still the case, but there was an annoyance where you couldn't have a type with the same name as the package. But that is hardly a lack of namespaces.
- refulgentis 2y ago
  You're right but this touches the hot stove. HN majority doesn't like hearing that ladybird et al might just be wandering around, even if the goal is catnip for the bleachers, and we should be skeptical this is the year of multiplatform Swift, because it wasn't last year if you actually tried it. Or the year before last. Or the year before that. Or the year before that year. Or the year before that one.
  - afavour 2y ago
    I’m slightly more ambivalent than you about it. Swift is a nice language and has better ergonomics than C++ and I imagine a Swift codebase might find more contributors than a C++ one (maybe I’m wrong about that!) I also think it’s separate from the dream of “multiplatform Swift”. For that you need a healthy package ecosystem that all works cross platform, Swift doesn’t have that. But a lot of Ladybird is written at a low enough level that it won’t matter so much.
    - refulgentis 2y ago
      Problem is Swift engineer supply is low, there's not a viable business case to learn Swift because it's not actually viable cross-platform for development unless you have $X00 million to throw at your macOS/iOS team to build it from scratch, platform by platform (to wit, sibling comment re: Arc Browser) So best case we're looking at: Swift isn't ready yet, the next major version will be, and we can't build UI with it, so we'll put in the effort in to bootstrap a cross-platform ecosystem and UI frameworks. Or maybe we'll just do our business logic in it? It's a confusing mess that is irrational. Even with great blessings of resources. ex. $X00M that Arc has obtained one incremental platform after a year. And "all" they had to do was Swift bindings for WinRT and connect it to the existing C++ engine. All of this is easy to justify if we treat it as an opportunity to shoot for how we wish software could work in theory, instead of practice. I hope I'm wrong but after being right the last few years, I'm willing to say it's naive wishcasting out loud, even though its boorish. I see it as unfortunately necessary, a younger me would be greatly misled by the conversations about it on HN. "We've decided to write the browser in Swift!" approaches parody levels of irresponsible resource management and is a case study in several solo engineer delusions that I also fall victim to. It's genuinely impossible for me to imagine anyone in my social circle of Apple devs, going back to 2007, who would think writing a browser engine in Swift is a good idea. I love Swift, used it since pre-1.0, immediately started shipping it after release, and that was the right decision. However, even given infinite resources and time, it is a poor fit for a browser engine, and an odd masochistic choice for cross-platform UI.
      - lnrd 2y ago
- oblio 2y ago
  Objective-C had some minimal adoption outside of Apple (probably due to NextStep nostalgia), so if Objective-C managed to get some traction, Swift will do it to, probably. However, Apple's history is very much stacked against Swift becoming a mainstream language outside of Apple's platform.
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.)
deleted 2y ago
[deleted]
deleted 2y ago
[deleted]

askonomm 2y ago

For non-UI portions as well, more from the horses mouth: https://x.com/awesomekling/status/1822236888188498031 https://x.com/awesomekling/status/1822236888188498031

deleted 2y ago

[deleted]