12 ms·

I really like how Swift is shaping up. They keep making choices that imho give you good balance of ergonomics and performance.

by qaq 6y ago

blacktriangle 6y ago
I can't help but feel the opposite, as if Swift is a dog chasing cars. Function builders are a really awkward unnecessary feature that was implemented so that SwiftUI could have a decent looking DSL. Some types showed that the whole protocol oriented programming model breaks down in some serious ways. And now they are looking at doing actors as a whole new built-in functionality rather than just a concurrency library. It looks like the Swift language is just too rigid and unable to evolve in useful ways without the blessing of the language developers themselves.
- afavour 6y ago
  I really enjoy working with Swift but after looking at this Actor proposal I think I agree with you. It seems like you'd always want to use actors? Unless you specifically don't want things to be concurrency safe. It feels like something the language should have had from the start or should have as an external library.
  - ogre_codes 6y ago
    > It seems like you'd always want to use actors? My impression is that when working with Swift your first tool of choice should be a value type, so a strict or an enum. Actors would only be desirable when you need class-like behaviors and need concurrency. Maybe I’m missing something, but I suspect many of us will never use actors directly at all. I certainly don’t see any parts of my code which demand this kind of structure.
  - viktorcode 6y ago
    You'll want actors if you have shared mutable state. But the most common usage of concurrent programming will be covered with simple async / await calls.
- raspasov 6y ago
  Agree. Either choose to use lisp syntax and lisp macros or add all the language "features" ad-hoc one by one over the years.
  - yoz-y 6y ago
    That is stretching the quote fairly thin. Programming in Swift is nothing like programming in Lisp on many levels.
    - raspasov 6y ago
      >> Programming in Swift is nothing like programming in Lisp on many levels. Precisely. "Any sufficiently complicated C or Fortran program contains an ad hoc, informally-specified, bug-ridden, slow implementation of half of Common Lisp." https://en.wikipedia.org/wiki/Greenspun%27s_tenth_rule https://en.wikipedia.org/wiki/Greenspun%27s_tenth_rule
    - blacktriangle 6y ago
      Eh its kind of an interesting question. Where is the line between what should be a language feature and what should be a macro. At the extreme arguing a feature should not be part of the language and be a library does translate to advocating lisp for everything. But concurrency is a really interesting case. Concurrency solutions are highly specific. I think we'd all agree there is no "answer" for concurrency, which puts it square in the library category. And there are consequences to getting your language's concurrency solution wrong. For example, I'd point to Clojure's built-in STM as a huge swing-and-a-miss. Otoh Erlang is the poster child for why doing concurrency right really does require language-level support. What's the way out? Imo either build your language around concurrency from day 1, ie Erlang, Go, Pony, or accept that concurrency will always be a best effort good-enough solution in your language.
- ckok 6y ago
  I can't help but get the feeling that plan with Swift is to be the only language you can effectively use for Apple platforms, but also is probably going to be the language that will only be used on Apple platforms because of Apple's whims like the function builders.
  - qaq 6y ago
    Realistically if choosing between C++, Rust, Go and Swift for things that are not highly performance sensitive I would happily go with Swift.
    - cmollis 6y ago
      agree.
- ragnese 6y ago
  > Function builders are a really awkward unnecessary feature that was implemented so that SwiftUI could have a decent looking DSL. Ugh. I agree. I haven't actually used SwiftUI in anger yet, so I try to reserve my judgement, but the whole thing seems like a lot of magic and complexity to me (not to mention reports of some performance issues/gotchas). Didn't they also add some weird dynamic JavaScripty property getters or something?
  - blacktriangle 6y ago
    Yep, property wrappers: https://nshipster.com/propertywrapper/ https://nshipster.com/propertywrapper/
- slavapestov 6y ago
  > Some types showed that the whole protocol oriented programming model breaks down in some serious ways. How so? Rust has an equivalent feature (impl Trait) for example. It solves a legitimate problem.
- astrange 6y ago
  The point of doing concurrency as a language feature is that it can stop you from writing incorrect programs in a way that a library can't. Besides, Swift already has concurrency libraries because Objective-C did - dispatch, NSOperation, NSRunLoop and so on. The problem is it has too many of them.
- skohan 6y ago
  > Function builders are a really awkward unnecessary feature that was implemented so that SwiftUI could have a decent looking DSL I totally agree. It's actually a big part of the reason I pulled back from Swift development for personal projects, since it appears that the core team has no problem shoe-horning in half-baked features if it's required to make the necessary impact at the keynote of WWDC. However I think that example (along with property wrappers) shouldn't be used to impugn the language design decisions as a whole. Protocol-oriented programming is extremely powerful in Swift, and since I have switched to mostly using Rust over the past year for personal projects, there are a lot of things about Swift I really miss.
  - dwaite 6y ago
    > ...since it appears that the core team has no problem shoe-horning in half-baked features if it's required to make the necessary impact at the keynote of WWDC. To be fair, that 'shoe-horning' took nearly a year and a half. Apple was willing to ship the feature but took their time and got lots of community feedback before a version of it became officially part of the language. I believe SwiftUI has already migrated over to the standardized version of it. SwiftUI is in some ways amazing - because you (rightfully) get this feeling that they had several ridiculously-overqualified compiler experts working in tandem with UX experts and low-level framework engineers on it. But the flip side is that you don't have a lot of parallels to draw experience from when using it - you must gain experience by working with SwiftUI itself.
    - skohan 6y ago
      > Apple was willing to ship the feature but took their time and got lots of community feedback before a version of it became officially part of the language. So let me tell you, as someone who was a very active member of the community when these features were announced, this is not what that felt like. I, like the rest of the community, found out about function builders by noticing code presented on a slide at WWDC which would not compile under the then-current version of Swift. There was then a large debate within the community, where members of the core team presented post-hoc rationalizations about how "Swift was always intended as a language which would support DSL's and declarative programming". But the message was clear - this feature was going into the language, with zero prior community review or input, because it was required for the business goals of Apple. The thing that made this particularly jarring for many in the community is that it was so far out of character for the general language evolution process. If anything Swift had been known for being slow at adopting new features. Every addition or change had to meet a very high standard of 1. feeling cohesive with the language, 2. not limiting the future design space, and 3. not presenting risks with respect to the ABI. Highly necessary features like variadic generics with obvious utility languished for years, cross-platform support and tooling remained in this grey zone of working in some select cases but not others, and here were radical changes to the language being made which were not known to the community at all. For me and a lot of others it clarified things about the direction and governance philosophy of the language. > But the flip side is that you don't have a lot of parallels to draw experience from when using it - you must gain experience by working with SwiftUI itself. What would be the big differences you would see with other hot-reloading FRP-style frameworks like React and Flutter?
ragnese 6y ago
I feel like it's really lame that its Swift version 157 or whatever and they still don't have a stable async/concurrency story besides callbacks. What's more is that they actually chose an error handling mechanism that doesn't even work with callbacks/closures! So sometimes you have a throwing function and sometimes you return a Result. As much as I actually do enjoy working with Swift (real type classes!!), there are some parts that are a big WTF.
- slavapestov 6y ago
  > they still don't have a stable async/concurrency story besides callbacks. What's more is that they actually chose an error handling mechanism that doesn't even work with callbacks/closures! So sometimes you have a throwing function and sometimes you return a Result. This is exactly what the new async/await feature solves though. Actors are built on top of that.
  - ragnese 6y ago
    Yeah, I know. I'm just lamenting how long it took to get to async/await. It's weird for the official language of a mobile app ecosystem to not have a pretty strong async story pretty early on, IMO.
    - zepto 6y ago
      They already had GCD and Operation provided by the platform, which worked perfectly with Swift, and dealt with concurrency very nicely. They weren’t under any pressure at all to have any other ‘async’ story early on and so intentionally chose to focus on other fundamentals and take their time to build something that would be well designed and additive.
      - ragnese 6y ago
        I argue that GCD, etc, don't actually work perfectly with Swift, though. Swift functions use a flavor of "checked errors" in the function signature via the `throws` keyword. When you're passing around callbacks or implementing Operation, there's no where to allow a `throws` function. Very similar problem to Java with checked exceptions and closures. The early versions of Swift didn't even have a standard Result type, IIRC. So even today, you will see some Swift functions that have `throws` in the signature and some that return `Result<T>`. It was always awkward.

I really like how Swift is shaping up. They keep making choices that imho give you good balance of ergonomics and performance.

by qaq 6y ago

I really like how Swift is shaping up. They keep making choices that imho give you good balance of ergonomics and performance.

blacktriangle 6y ago

I can't help but feel the opposite, as if Swift is a dog chasing cars. Function builders are a really awkward unnecessary feature that was implemented so that SwiftUI could have a decent looking DSL. Some types showed that the whole protocol oriented programming model breaks down in some serious ways. And now they are looking at doing actors as a whole new built-in functionality rather than just a concurrency library. It looks like the Swift language is just too rigid and unable to evolve in useful ways without the blessing of the language developers themselves.

afavour 6y ago
I really enjoy working with Swift but after looking at this Actor proposal I think I agree with you. It seems like you'd always want to use actors? Unless you specifically don't want things to be concurrency safe. It feels like something the language should have had from the start or should have as an external library.
- ogre_codes 6y ago
  > It seems like you'd always want to use actors? My impression is that when working with Swift your first tool of choice should be a value type, so a strict or an enum. Actors would only be desirable when you need class-like behaviors and need concurrency. Maybe I’m missing something, but I suspect many of us will never use actors directly at all. I certainly don’t see any parts of my code which demand this kind of structure.
- viktorcode 6y ago
  You'll want actors if you have shared mutable state. But the most common usage of concurrent programming will be covered with simple async / await calls.
raspasov 6y ago
Agree. Either choose to use lisp syntax and lisp macros or add all the language "features" ad-hoc one by one over the years.
- yoz-y 6y ago
  That is stretching the quote fairly thin. Programming in Swift is nothing like programming in Lisp on many levels.
  - raspasov 6y ago
    >> Programming in Swift is nothing like programming in Lisp on many levels. Precisely. "Any sufficiently complicated C or Fortran program contains an ad hoc, informally-specified, bug-ridden, slow implementation of half of Common Lisp." https://en.wikipedia.org/wiki/Greenspun%27s_tenth_rule https://en.wikipedia.org/wiki/Greenspun%27s_tenth_rule
  - blacktriangle 6y ago
    Eh its kind of an interesting question. Where is the line between what should be a language feature and what should be a macro. At the extreme arguing a feature should not be part of the language and be a library does translate to advocating lisp for everything. But concurrency is a really interesting case. Concurrency solutions are highly specific. I think we'd all agree there is no "answer" for concurrency, which puts it square in the library category. And there are consequences to getting your language's concurrency solution wrong. For example, I'd point to Clojure's built-in STM as a huge swing-and-a-miss. Otoh Erlang is the poster child for why doing concurrency right really does require language-level support. What's the way out? Imo either build your language around concurrency from day 1, ie Erlang, Go, Pony, or accept that concurrency will always be a best effort good-enough solution in your language.
ckok 6y ago
I can't help but get the feeling that plan with Swift is to be the only language you can effectively use for Apple platforms, but also is probably going to be the language that will only be used on Apple platforms because of Apple's whims like the function builders.
- qaq 6y ago
  Realistically if choosing between C++, Rust, Go and Swift for things that are not highly performance sensitive I would happily go with Swift.
  - cmollis 6y ago
    agree.
ragnese 6y ago
> Function builders are a really awkward unnecessary feature that was implemented so that SwiftUI could have a decent looking DSL. Ugh. I agree. I haven't actually used SwiftUI in anger yet, so I try to reserve my judgement, but the whole thing seems like a lot of magic and complexity to me (not to mention reports of some performance issues/gotchas). Didn't they also add some weird dynamic JavaScripty property getters or something?
- blacktriangle 6y ago
  Yep, property wrappers: https://nshipster.com/propertywrapper/ https://nshipster.com/propertywrapper/
slavapestov 6y ago
> Some types showed that the whole protocol oriented programming model breaks down in some serious ways. How so? Rust has an equivalent feature (impl Trait) for example. It solves a legitimate problem.
astrange 6y ago
The point of doing concurrency as a language feature is that it can stop you from writing incorrect programs in a way that a library can't. Besides, Swift already has concurrency libraries because Objective-C did - dispatch, NSOperation, NSRunLoop and so on. The problem is it has too many of them.
skohan 6y ago
> Function builders are a really awkward unnecessary feature that was implemented so that SwiftUI could have a decent looking DSL I totally agree. It's actually a big part of the reason I pulled back from Swift development for personal projects, since it appears that the core team has no problem shoe-horning in half-baked features if it's required to make the necessary impact at the keynote of WWDC. However I think that example (along with property wrappers) shouldn't be used to impugn the language design decisions as a whole. Protocol-oriented programming is extremely powerful in Swift, and since I have switched to mostly using Rust over the past year for personal projects, there are a lot of things about Swift I really miss.
- dwaite 6y ago
  > ...since it appears that the core team has no problem shoe-horning in half-baked features if it's required to make the necessary impact at the keynote of WWDC. To be fair, that 'shoe-horning' took nearly a year and a half. Apple was willing to ship the feature but took their time and got lots of community feedback before a version of it became officially part of the language. I believe SwiftUI has already migrated over to the standardized version of it. SwiftUI is in some ways amazing - because you (rightfully) get this feeling that they had several ridiculously-overqualified compiler experts working in tandem with UX experts and low-level framework engineers on it. But the flip side is that you don't have a lot of parallels to draw experience from when using it - you must gain experience by working with SwiftUI itself.
  - skohan 6y ago
    > Apple was willing to ship the feature but took their time and got lots of community feedback before a version of it became officially part of the language. So let me tell you, as someone who was a very active member of the community when these features were announced, this is not what that felt like. I, like the rest of the community, found out about function builders by noticing code presented on a slide at WWDC which would not compile under the then-current version of Swift. There was then a large debate within the community, where members of the core team presented post-hoc rationalizations about how "Swift was always intended as a language which would support DSL's and declarative programming". But the message was clear - this feature was going into the language, with zero prior community review or input, because it was required for the business goals of Apple. The thing that made this particularly jarring for many in the community is that it was so far out of character for the general language evolution process. If anything Swift had been known for being slow at adopting new features. Every addition or change had to meet a very high standard of 1. feeling cohesive with the language, 2. not limiting the future design space, and 3. not presenting risks with respect to the ABI. Highly necessary features like variadic generics with obvious utility languished for years, cross-platform support and tooling remained in this grey zone of working in some select cases but not others, and here were radical changes to the language being made which were not known to the community at all. For me and a lot of others it clarified things about the direction and governance philosophy of the language. > But the flip side is that you don't have a lot of parallels to draw experience from when using it - you must gain experience by working with SwiftUI itself. What would be the big differences you would see with other hot-reloading FRP-style frameworks like React and Flutter?

ragnese 6y ago

I feel like it's really lame that its Swift version 157 or whatever and they still don't have a stable async/concurrency story besides callbacks. What's more is that they actually chose an error handling mechanism that doesn't even work with callbacks/closures! So sometimes you have a throwing function and sometimes you return a Result. As much as I actually do enjoy working with Swift (real type classes!!), there are some parts that are a big WTF.

slavapestov 6y ago
> they still don't have a stable async/concurrency story besides callbacks. What's more is that they actually chose an error handling mechanism that doesn't even work with callbacks/closures! So sometimes you have a throwing function and sometimes you return a Result. This is exactly what the new async/await feature solves though. Actors are built on top of that.
- ragnese 6y ago
  Yeah, I know. I'm just lamenting how long it took to get to async/await. It's weird for the official language of a mobile app ecosystem to not have a pretty strong async story pretty early on, IMO.
  - zepto 6y ago
    They already had GCD and Operation provided by the platform, which worked perfectly with Swift, and dealt with concurrency very nicely. They weren’t under any pressure at all to have any other ‘async’ story early on and so intentionally chose to focus on other fundamentals and take their time to build something that would be well designed and additive.
    - ragnese 6y ago
      I argue that GCD, etc, don't actually work perfectly with Swift, though. Swift functions use a flavor of "checked errors" in the function signature via the `throws` keyword. When you're passing around callbacks or implementing Operation, there's no where to allow a `throws` function. Very similar problem to Java with checked exceptions and closures. The early versions of Swift didn't even have a standard Result type, IIRC. So even today, you will see some Swift functions that have `throws` in the signature and some that return `Result<T>`. It was always awkward.