6 ms·

Key takeaway for me was the note that it “definitely isn’t a community designed language”. This is telling, I’ve watched a lot of neat languages over the years

Key takeaway for me was the note that it “definitely isn’t a community designed language”. This is telling, I’ve watched a lot of neat languages over the years and absolutely none of the ones without community involvement have grown beyond the sphere of influence of their primary companies. I like swift enough I’m learning it to build my own personal tech nerd ideal podcast client because I own apple devices and want an app that works between macOS, iOS, iPadOS, tvOS,and watchOS. but I doubt I’ll ever use it for anything beyond this one personally motivated project. Even if i release it as an app on the store for download or purchase I don’t know if I will ever be motivated enough to build anything else using it. Because the scope is too narrow. Business work is converging on open stacks like react, and angular, and the dark horse of C# with its latest release supporting WASM web components backed by GRPC-web and a C# function driven stack from front to back, even without SQL Server costs this is a compelling ecosystem backed by PostgreSQL and other completely open source tools. But Swift remains Apple’s language for apple stuff and… while a profitable niche, it’s still a niche. Edit: typo fix.

username_my1 5y ago
which sucks because apple had the chance not to repeat their mistake with Objective-C .. but history repeats itself. No matter how much apple market share in whatever market grows, developers want to be able to switch platforms and not have to think about the language.
- snek_case 5y ago
  Vendor lock-in will always inevitably backfire, because developers and users don't want to be trapped. It might work to maximize profits in the short to medium term, but there's very strong financial incentives not to be stuck with a single platform. Vendor lock-in could mean the death of your product, or even your whole business.
  - infogulch 5y ago
    Most new products are positioned to grow into a form of locked-in market that you can extract value from, drawing a box around their customers for the sole purpose of squeezing it in the future. This business strategy is a mind virus and has even overtaken the aspirations of bright-eyed entrepreneurs. The aim has fallen from the simple "get rich by selling a $1 item to 10 million people" down to "create a product where customers are trapped in a dependency relationship with the product by design, give it away below cost to push out alternatives, then flip it and squeeze them for as much as possible" (where the last part is omitted from the initial business plan but still implied, and enabled by outsourcing the dirty work to new management via buyout). The primary goal should be to maximize value, and within that a balanced tension between maximizing delivered value vs maximizing captured value. It's reasonable to be compensated for the value you add, but it needs to be in service of maximizing value in general. If the correct hierarchy of goals is inverted and capturing value becomes the primary aim then it inevitably devolves into this antisocial, monopolistic, lock-in behavior.
  - Grustaf 5y ago
    I'd say at least 95% of Swift users don't mind at all that it's mostly an Apple language.
    - samhw 5y ago
      Well, and 95% of heroin users don't mind needles and constipation. It's trivially true that the people who end up using a product are mostly the people who are content with its tradeoffs. That doesn't say much at all about whether those tradeoffs are ultimately optimal.
      - Grustaf 5y ago
        I don't know about optimal, but I've been a Swift developer since day 1 and yet never heard anyone I know complain about Swift being to Apple centric. It's typically armchair philosophers online that have purity concerns, not practical developers.
        b3morales 5y ago
        I don't have a problem with it being Apple controlled. I have a problem with it being presented as an open project while simultaneously Apple completely controls its trajectory and maintains private forks of everything, which are where the developer tools are actually built from. If it was a closed process where neat stuff just dropped out of the sky each year, that would be fine. When features drop out of nowhere each year and then get laundered through ex post facto public "review", then I take issue. If it was a closed process then we would expect that only features coming from Apple would exist. In a truly open process there would be facilitation for contributions from people outside the organization. In the Swift project as it is currently run, those contributions have withered on the vine; the core team doesn't particularly welcome or support anything that didn't originate internally.
        Grustaf 5y ago
        This is a textbook example of what I meant by philosophers obsessed with purity. And it doesn't sound like you're actually following Swift Evolution. A) Most of what happens is done in public, only rarely do they hide stuff until the last minute, like result builders for SwiftUI. B) As far as I know, they have never claimed that it's going to be completely open and 100% community controlled. The core team is mostly Apple employees, that is not a secret.
- dmitriid 5y ago
  > apple had the chance not to repeat their mistake with Objective-C .. but history repeats itself. Objective-C has served them for over 40 years, building several different OSes over a multitude of CPUS and platforms. If anything, Swift would welcome a repeat of this history.
  - MAGZine 5y ago
    You can build OSes in many different languages, and compile software to many different CPUs and architectures. That alone does not make it good.
    - Apocryphon 5y ago
      APIs designed for and built in Objective-C have been the mainstay of Apple application development ever since the Cocoa framework, stretching all the way back to NeXTSTEP in the 1980s. Even with the advent of Swift, most of today's iOS and macOS APIs carry the legacy of Objective-C. Much of development with Swift has involved with attempting to use the new language for old APIs. Perhaps legacy alone does not make it good, but it certainly demonstrates that there has not been a need to rewrite all of it using newer languages, that Objective-C has been reliable and venerable.
- mehrdada 5y ago
  Objective-C was not originally designed by Apple (or NeXT)
- andrewcl 5y ago
  Objective-C is such a small and concise language. It doesn't get in the way of development in quite the same way Swift can delay building out a feature due to bikeshedding.
silvestrov 5y ago
I think Swift was a strategic mistake mainly due to the niche effect, even if it's a better language. It would have been much more productive to team up with the C# team as C# is a mature language, and a combined Apple + Microsoft would have been able to compete against java (esp. with Oracle as owner of java).
- eropple 5y ago
  An Apple C# future is a neat idea, but I'm not sure how you square that with the (IMO correct) observation that allocation control really matters for quality of experience on constrained platforms. Obviously iOS platforms are much less constrained today, but not having to run a GC is a pretty nice thing. Maybe C# could've been extended into that universe (I know Midori had their own variant but don't know much about it) but it seems daunting to then make that compatible.
  - silvestrov 5y ago
    Apple tried to do automatic GC but did so very badly and with a language not designed for it, so they had a bad experience and were scared away. The modern GC in java is amazingly fast and with a few tricks likely to be good enough.
    - richardwhiuk 5y ago
      I'm fairly convinced that GC is the reason that Android phones need much more RAM and much more CPU to generally be worse than Apple phones in terms of performance.
      - miskin 5y ago
        You may be both right, as android is actually not using Java garbage collectors that are quite good, but they have their own runtime.
    - eropple 5y ago
      I'm pretty familiar with the modern Java GCs, and they're very impressive, but at the same time having to do manifestly less work with ARC is probably good for responsiveness and battery life.
GeekyBear 5y ago
> Key takeaway for me was the note that it “definitely isn’t a community designed language”. If you scroll to the top of the page with Chris' comment, this point is being addressed: >In the coming weeks, we hope to introduce a new language workgroup that will focus on the core of the language evolution itself, splitting off this responsibility from the core steering of the project. The intent is to free the core team to invest more in overall project stewardship and create a larger language workgroup that can incorporate more community members in language decisions.
- jonhendry18 5y ago
  Another committee is sure to fix the problem with the existing committees.
jon889 5y ago
I’d much rather have a language specifically for creating apps than another generic language. It’s actually my opinion that Swift got worse since they started wanting it be used for more things like the server side.
- manmal 5y ago
  The weird stuff came out of Tensorflow and SwiftUI IMO. Distributed actors looks like it’s not hurting the design.
jjtheblunt 5y ago
> and absolutely none of the ones without community involvement have grown beyond the sphere of influence of their primary companies C touches much more than telephony

username_my1 5y ago

which sucks because apple had the chance not to repeat their mistake with Objective-C .. but history repeats itself. No matter how much apple market share in whatever market grows, developers want to be able to switch platforms and not have to think about the language.

snek_case 5y ago
Vendor lock-in will always inevitably backfire, because developers and users don't want to be trapped. It might work to maximize profits in the short to medium term, but there's very strong financial incentives not to be stuck with a single platform. Vendor lock-in could mean the death of your product, or even your whole business.
- infogulch 5y ago
  Most new products are positioned to grow into a form of locked-in market that you can extract value from, drawing a box around their customers for the sole purpose of squeezing it in the future. This business strategy is a mind virus and has even overtaken the aspirations of bright-eyed entrepreneurs. The aim has fallen from the simple "get rich by selling a $1 item to 10 million people" down to "create a product where customers are trapped in a dependency relationship with the product by design, give it away below cost to push out alternatives, then flip it and squeeze them for as much as possible" (where the last part is omitted from the initial business plan but still implied, and enabled by outsourcing the dirty work to new management via buyout). The primary goal should be to maximize value, and within that a balanced tension between maximizing delivered value vs maximizing captured value. It's reasonable to be compensated for the value you add, but it needs to be in service of maximizing value in general. If the correct hierarchy of goals is inverted and capturing value becomes the primary aim then it inevitably devolves into this antisocial, monopolistic, lock-in behavior.
- Grustaf 5y ago
  I'd say at least 95% of Swift users don't mind at all that it's mostly an Apple language.
  - samhw 5y ago
    Well, and 95% of heroin users don't mind needles and constipation. It's trivially true that the people who end up using a product are mostly the people who are content with its tradeoffs. That doesn't say much at all about whether those tradeoffs are ultimately optimal.
    - Grustaf 5y ago
      I don't know about optimal, but I've been a Swift developer since day 1 and yet never heard anyone I know complain about Swift being to Apple centric. It's typically armchair philosophers online that have purity concerns, not practical developers.
      - b3morales 5y ago
        I don't have a problem with it being Apple controlled. I have a problem with it being presented as an open project while simultaneously Apple completely controls its trajectory and maintains private forks of everything, which are where the developer tools are actually built from. If it was a closed process where neat stuff just dropped out of the sky each year, that would be fine. When features drop out of nowhere each year and then get laundered through ex post facto public "review", then I take issue. If it was a closed process then we would expect that only features coming from Apple would exist. In a truly open process there would be facilitation for contributions from people outside the organization. In the Swift project as it is currently run, those contributions have withered on the vine; the core team doesn't particularly welcome or support anything that didn't originate internally.
        Grustaf 5y ago
        This is a textbook example of what I meant by philosophers obsessed with purity. And it doesn't sound like you're actually following Swift Evolution. A) Most of what happens is done in public, only rarely do they hide stuff until the last minute, like result builders for SwiftUI. B) As far as I know, they have never claimed that it's going to be completely open and 100% community controlled. The core team is mostly Apple employees, that is not a secret.
dmitriid 5y ago
> apple had the chance not to repeat their mistake with Objective-C .. but history repeats itself. Objective-C has served them for over 40 years, building several different OSes over a multitude of CPUS and platforms. If anything, Swift would welcome a repeat of this history.
- MAGZine 5y ago
  You can build OSes in many different languages, and compile software to many different CPUs and architectures. That alone does not make it good.
  - Apocryphon 5y ago
    APIs designed for and built in Objective-C have been the mainstay of Apple application development ever since the Cocoa framework, stretching all the way back to NeXTSTEP in the 1980s. Even with the advent of Swift, most of today's iOS and macOS APIs carry the legacy of Objective-C. Much of development with Swift has involved with attempting to use the new language for old APIs. Perhaps legacy alone does not make it good, but it certainly demonstrates that there has not been a need to rewrite all of it using newer languages, that Objective-C has been reliable and venerable.
mehrdada 5y ago
Objective-C was not originally designed by Apple (or NeXT)
andrewcl 5y ago
Objective-C is such a small and concise language. It doesn't get in the way of development in quite the same way Swift can delay building out a feature due to bikeshedding.

silvestrov 5y ago

I think Swift was a strategic mistake mainly due to the niche effect, even if it's a better language. It would have been much more productive to team up with the C# team as C# is a mature language, and a combined Apple + Microsoft would have been able to compete against java (esp. with Oracle as owner of java).

eropple 5y ago
An Apple C# future is a neat idea, but I'm not sure how you square that with the (IMO correct) observation that allocation control really matters for quality of experience on constrained platforms. Obviously iOS platforms are much less constrained today, but not having to run a GC is a pretty nice thing. Maybe C# could've been extended into that universe (I know Midori had their own variant but don't know much about it) but it seems daunting to then make that compatible.
- silvestrov 5y ago
  Apple tried to do automatic GC but did so very badly and with a language not designed for it, so they had a bad experience and were scared away. The modern GC in java is amazingly fast and with a few tricks likely to be good enough.
  - richardwhiuk 5y ago
    I'm fairly convinced that GC is the reason that Android phones need much more RAM and much more CPU to generally be worse than Apple phones in terms of performance.
    - miskin 5y ago
      You may be both right, as android is actually not using Java garbage collectors that are quite good, but they have their own runtime.
  - eropple 5y ago
    I'm pretty familiar with the modern Java GCs, and they're very impressive, but at the same time having to do manifestly less work with ARC is probably good for responsiveness and battery life.

GeekyBear 5y ago

> Key takeaway for me was the note that it “definitely isn’t a community designed language”. If you scroll to the top of the page with Chris' comment, this point is being addressed: >In the coming weeks, we hope to introduce a new language workgroup that will focus on the core of the language evolution itself, splitting off this responsibility from the core steering of the project. The intent is to free the core team to invest more in overall project stewardship and create a larger language workgroup that can incorporate more community members in language decisions.

jonhendry18 5y ago
Another committee is sure to fix the problem with the existing committees.

jon889 5y ago

I’d much rather have a language specifically for creating apps than another generic language. It’s actually my opinion that Swift got worse since they started wanting it be used for more things like the server side.

manmal 5y ago
The weird stuff came out of Tensorflow and SwiftUI IMO. Distributed actors looks like it’s not hurting the design.

jjtheblunt 5y ago

> and absolutely none of the ones without community involvement have grown beyond the sphere of influence of their primary companies C touches much more than telephony