6 ms·

A lot of people who are invested in the Apple ecosystem have been trying to present Swift as a general competitor to Rust, but no matter how many bullet points

by jchw 4y ago

A lot of people who are invested in the Apple ecosystem have been trying to present Swift as a general competitor to Rust, but no matter how many bullet points you list, as far as I can tell, it hasn't made any progress at all on that front, and I haven't been convinced that it will change to become closer to that any time soon, either. As far as I can tell, there's really nothing wrong with Swift, and it probably has a lot to offer, but at some point someone's going to need to point out the obvious: basically nobody outside of the Apple ecosystem is considering using Swift for anything. That doesn't mean it's bad, but it's not a competitor to Rust today, and it's not trending in that direction.

mr_00ff00 4y ago
I know this might be opening a can of worms, but technically doesn’t Swift do reference counting? Which is faster than “mark and sweep” GC but will never compare to manual management (like C/C++ and rust ownership) I assume that’s the big reason.
- convolvatron 4y ago
  indeed. RC isn't universally faster than GC - it depends on workload
- rat9988 4y ago
  reference counting is not necessarily faster.
  - lll-o-lll 4y ago
    It’s not faster in the normal case, it’s generally quite a bit slower. It is more predictable however (you can actually use it with real-time constraints!), and performs better under memory pressure. Whether this is a net benefit depends on what hardware you’re running on and what the app is supposed to be doing.
- Jweb_Guru 4y ago
  Reference counting is not faster than tracing GC for general purpose workloads, at least not without a lot of extensive tuning that includes stuff like using tracing and moving GC for the young generation (prior to the first collection), deferring reference count increment/decrements using write barriers, limiting reference count bits (and reclaiming stuck objects with some variant of full heap tracing), and so on. Many of these benefits cannot be effectively realized if you insist on prompt execution of finalizers, either. Languages like Rust and C++ gain their performance benefits not from using reference counting or immediate reclamation, but from avoiding creating garbage in the first place by stack allocating most stuff, creating large objects by-value and within vectors to reduce pointer chasing, using direct interior references into data structures in ways that it would be difficult to trace efficiently, and using data structures like arenas to emulate the benefits of generational GC in controlled contexts where a maximum lifetime can be statically determined. My personal feeling is that it's very hard to directly compare manual memory management and GC from a performance perspective because so many of the techniques that make tracing fast involve moving pointers, which is very costly to combine with many of the techniques that make manual memory management fast which rely on values not moving in memory. I think any such solution that is efficient for both kinds of memory will probably require the programmer to have very tight control over when the garbage collector can execute, whether pointers can move at particular times, etc., and the complexity of maintaining that kind of control (and getting it right!) seems so high that I'm not sure it would ever be usable for general purpose programming.
  - BulgarianIdiot 4y ago
    The Swift compiler does some of the optimizations/techniques you mention Rust does. It won't reference count, when the setup is possible to analyze statically and elide ref count. Swift also has widely used complex value types, which are stored on the stack. It will also even put some reference types on the stack after doing escape analysis etc. I don't know which benchmark to trust anymore, but for some reason iOS software tends to seemingly overperform comparable ART (GC) code.
    - saagarjha 4y ago
- nicoburns 4y ago
  I think you’re missing the context that people are choosing Rust over Swift even in domains like backend web development which should theoretically be a good fit for Swift. And this is largely because the Swift ecosystem outside of Apple is pretty minimal.
  - xedrac 4y ago
    And frankly, I have zero confidence that Apple will sufficiently invest in the language outside of their ecosystem. That's just not how Apple operates.
- karmakaze 4y ago
  After using Rust for my own personal tryouts, I liked it more than expected, and though I see the value in the borrow-checker don't work in areas where it's warranted. In most of my uses, I would be fine always using Rc/Arc which would make Rust equivalent to using Swift. As a language though, I much prefer Rust to Swift.
- jchw 4y ago
  That's certainly a reason, but Go doesn't have the adoption issues that Swift has despite Google's reputation. Go's GC may be fast, and on some workloads maybe even competitive against ARC - But, I really don't think that has anything to do with why Swift isn't seeing widespread adoption outside of the Apple ecosystem. Here's my personal opinion for why. Bear with me for a second. I just searched "Swift programming language" on my search engine and the first result looks promising: > https://developer.apple.com/swift/ https://developer.apple.com/swift/ OK. It's a language by Apple, so it's not surprising that it's on Apple's website, even though I think if you want people to get the idea that it's a serious independent project you probably should give it its own top-level site personally. (edit: Yes, I know it does. This is my honest first impression. Please keep reading.) > Swift is a powerful and intuitive programming language for iOS, iPadOS, macOS, tvOS, and watchOS. Alright, we're only talking about Apple platforms. Technically it doesn't say that it can't work outside of these OSes, but it's clear that Apple is not marketing Swift as a general purpose operating system. From Apple's marketing PoV, it's an operating system that is made for Apple platforms and anything else is incidental. > Download Xcode and learn how to build apps using Swift with documentation and sample code. No download links for users of other operating systems. But if you go to that link, all the way at the bottom, you get: > Swift is developed in the open. To learn more about the open source Swift project and community, visit Swift.org. Finally, you might notice that Swift is actually available outside of macOS. It's available for Windows and Linux, but not BSD as far as I can ascertain. The platform support of Swift is excellent when it comes to Apple devices, but it lags far behind other options when it comes to other platforms and architectures. My perception is that Apple hasn't really made a serious enough investment into making Swift a general purpose programming language outside of its own ecosystem. That's honestly fair, as doing so is no doubt extremely expensive and time-consuming, and it's an on-going investment. What they're doing now appears to kick it to the community, who has done a lot, including as far as I can tell, make Swift work on RISC-V. But Apple is literally the world's biggest technology company, so it's not exactly desirable to put a bunch of community effort into giving it the on-going support that it needs to feel "first-class" outside of Apple platforms. Even just the optics here are quite bad, and I think the fact that it's still like this is going to haunt the long-term prospects of Swift outside of Apple platforms. All of this is aside from its technical merits. Normally, I'd like to stick to purely just technical merits, but unfortunately this stuff does matter. It's part of the reason why Go is still a solid choice today even though Rust has a lot of technical advantages on paper.
- jasmer 4y ago
  That's definitely the elephant in the room. And the fact that it does not have clean and easy C integration. If you could do direct memory stuff and control the ARC stuff, and easily integrate with C ... ... and the docs were clean, and you could easily use something other than XCode ... Then Swift would be huge. It's a neat language but it's just not designed to go beyond Mac. The entire C++ world would move away in an instant to something clean and flexible. Rust is just too specific for most things, and Swift is just about outside. So sad.
  - myko 4y ago
    Using VSCode instead of Xcode should work fairly well: https://www.swift.org/blog/vscode-extension/ https://www.swift.org/blog/vscode-extension/ https://marketplace.visualstudio.com/items?itemName=sswg.swift-lang https://marketplace.visualstudio.com/items?itemName=sswg.swi...
  - sweetjuly 4y ago
    I've found Swift->C to interop very well with Swift. Yes, you get absolutely buried in UnsafeXXX wrapped types but it does do exactly what you expected. Going the other way is somewhat "herebe dragons" since @_cdecl is technically non-standardized (though there is a movement to standardize it [1]) but it definitely works fine. [1] https://forums.swift.org/t/formalizing-cdecl/40677/7 https://forums.swift.org/t/formalizing-cdecl/40677/7
  - galangalalgol 4y ago
    What do you mean about rust being too specific for most things? It seems like a fairly obvious choic for c++ replacement in a new project, the issue is large c++ codebases already exist, and that migration is painful in my experience. Autocxx type support is still largely missing or in work, diplomat seems reasonable, but I haven't had an opportunity to use it for something real yet.
    - xedrac 4y ago
      I think for Rust to truly replace C++, it needs a better dynamic linking story. I wish they would make their ABI stable within a given edition. That would make it much easier for people to rely on dynamic linking, similar to how C++ does it. Without it, Rust binaries are quite huge.
- pkulak 4y ago
  If reference counting was faster, Java would do it. It’s better for UIs and lower latency, but a modern, generational GC can beat C in throughput (because allocations get a lot faster).
  - mr_00ff00 4y ago
    Genuine question, but if that were true then why does High Frequency Trading and Performance critical applications use C if GCs can beat it?
    - zaphar 4y ago
      The two biggest languages I'm aware of in that space are Java and C++. I don't think I've heard of any shop using C. Java seems to be keeping up with C++ there as far as I know. Do you have evidence to the contrary?
      - mr_00ff00 4y ago
        Yeah I guess I used C and C++ interchangeably, but I believe C++ is the language of HFT. Do you have evidence to the contrary?
        pjmlp 4y ago
        "Why we chose Java for our High-Frequency Trading application" https://medium.com/@jadsarmo/why-we-chose-java-for-our-high-frequency-trading-application-600f7c04da94 https://medium.com/@jadsarmo/why-we-chose-java-for-our-high-...
        mr_00ff00 4y ago
        I don’t think your article makes the claim Java keeps up with C++. That article seems to be about getting latency low and consistent so Java can compete with C++.
        4y ago
brundolf 4y ago
It's a bummer because I feel like I'd really like Swift if I felt it were a real, durable cross-platform language to spend time learning and using. Some of the trade-offs it makes seem really nice But I don't feel like Swift on non-Apple platforms will ever be more than a hobby for the Apple org
- myko 4y ago
  What's stopping you from using it on Linux, or your platform of choice? It seems to be supported well enough, and Vapor is a decent toolkit for building a webapp with it.
  - techdragon 4y ago
    Speaking as someone with similar feelings… “Well enough” and “decent” are not how I would describe something I’m thinking of investing significant mental time and effort learning and familiarisation building on. I’ve done the basic tutorials and generally like the language ergonomics, it’s not bad, and I kinda like it for the little bit of Apple platform dev I’ve done with it. But it’s basically a different language on any non Apple platform.
  - brundolf 4y ago
    My understanding is that it's got second-class Linux support, for now. What happens when Apple loses interest? What about Windows? I don't get a sense of commitment from them outside of their own platforms, and that doesn't make me want to commit to learning or starting major projects in the language (outside of their platforms). If I can't have faith my project's foundation will continue to be solid, then I don't want to build it there; if I know I'll never have an employer who wants to let me use Swift (again, outside of Apple apps) then I don't really want to invest the time to deeply learn it (unless I'm going all-in on Apple apps) I could do a toy project or an iOS app with it, and maybe I will some day, but it's hard for me to feel like it's worth going past that while this is the feeling I'm getting from Apple (And I'm not really even blaming/judging them here; it makes total sense they would want to have a modern in-house language that's perfectly integrated with their systems and now their chipsets, and lets them ship more effectively. They don't owe anyone more than that. It's just a shame, for me personally, to think about what else could have been)
wilg 4y ago
This is all very hand-wavey. Are you just describing a chicken-and-egg scenario? Also, Swift probably can compete with Rust, especially when they finish adding Rust-style lifetimes. But the real advantage of Swift is it has a much more "high-level" feel than Rust – it's much more familiar to use than Rust by virtue of having classes and things. Swift also doesn't instantly force you into weeds of dealing with memory management complexity. I think I'm going to enjoy the "drop into manual memory management for hot paths" approach Swift is taking.
- acomjean 4y ago
  I think swift competes more with go than rust.
  - bsaul 4y ago
    From an aestethic pov, swift is taking the exact opposite direction than go: it keeps piling on more language features, with much less concerns on keeping the language simple. As a developer currently working in both, it feels like jumping to another civilisation every time i switch.
- verdagon 4y ago
  I'm particularly interested in this line of thinking, and I'd probably lean the same way. Would love to hear more, why do you think it's a better approach to default to more high-level, with the ability to drop down into manual memory management for hot paths?
  - wilg 4y ago
    Simply because hot paths are less common for a "typical" workload. So you'd want it to be more ergonomic by default. Where possible, jam all optimizations into the compiler so nobody has to think about it. If you can't do that, then allow developers to give the compiler more information even if it's more complex. Relatedly, it allows the language to help you "first make it work, then make it good".
- jchw 4y ago
deleted 4y ago
[deleted]
Kukumber 4y ago
People are busy using Swift rather than trying to religiously advocate for Rust on various websites One example: Arc is a webkit powered browser written in swift and is crossplatform: https://twitter.com/hursh/status/1612472691747090432 https://twitter.com/hursh/status/1612472691747090432
- saagarjha 4y ago
  Don’t think it is yet, and it uses Chromium
- jchw 4y ago
  No doubt people are busy using Swift, but Apple technology advocates are about as "religious advocates" as they come. And frankly, I'm not trying to say that as some kind of negative. It can be annoying, but clearly Apple users are genuine enthusiasts, even if I can't really see eye-to-eye with them. I do think that this genuine enthusiasm creates some distorted images of the reality of the world, though. The thing is, Apple users are likely so used to having more enthusiasm than competing communities of higher marketshare products and services that it's not surprising at all that the perception is that Rust is all hype. I'm more a Go coder than Rust by SLoC, and Rust has to be one of the most enthusiastically supported languages I've ever seen. Still, it'd be silly to discredit Rust on the basis of its enthusiastic userbase: it's successful by any measure. It's invading the Linux kernel, the campuses of Amazon, Google, Microsoft, it's going to be in both Firefox and Chromium, and that's really just the beginning. Even if Swift had more collective SLoC than Rust, Rust is clearly on its way to solidifying its place as one of the most impactful programming languages of the past 20 years. That impact is even going to be felt in Swift: when talking about Swift, it is very common to advertise it in terms of Rust. I mean hell, that's basically what this blog post title does: "Look, Swift did something even Rust couldn't!" -- If Rust wasn't so influential, I do not think anyone would bother to compare the two in this way.
  - Kukumber 4y ago
    for 1 article like this, you get 1000000 ones from "rust evangelists from the Rust Evangelism Strike Force" both can coexist, yet for the rust crowd only one must prevail that's what's annoying about rust and its religious community my previous comment's score is (-1), that speaks for itself don't you think ;)
pjmlp 4y ago
I would say it is the reverse on what concerns Apple platforms, Rust isn't a competitor to Swift. It will never have tooling parity with Swift. Trying to use Rust instead of Swift on Apple platforms is only for those that enjoy the pain of creating ecosystems from scratch.
- jchw 4y ago
  Definitely! There's only one enormous issue with this outlook: the rest of the world is bigger. Much bigger. Exactly how much bigger depends on who you ask, but it's a lot bigger. Just on the consumer side... https://gs.statcounter.com/os-market-share https://gs.statcounter.com/os-market-share Maybe it doesn't matter because developers prefer macOS, so the rest can be treated as a secondary case? Not even close. https://survey.stackoverflow.co/2022/#section-most-popular-technologies-operating-system https://survey.stackoverflow.co/2022/#section-most-popular-t... What about servers? Network services and SaaS are a huge industry, of course. Admittedly, I can't even find a good source for what marketshare macOS has: most "server marketshare" counts seem to exclude it or just merge it in with "UNIX-likes". The number appears to be extremely small. There's definitely some exceptions; I think Imgix has been deploying Macs to the datacenter. However, in order to do so, they essentially had to build custom rack mount equipment for desktop machines... I think it's very safe to say that macOS deployments for services are extremely in the minority, and the majority of macOS data center deployments aren't even for general network services specifically but mainly just for CI. OTOH, macOS Server and any "server" SKUs of Macs have been discontinued as far as I know. "Rust isn't a competitor to Swift" is not the zinger in Apple's favor that you think it to be. In fact, Apple would be best to support making Rust work better on Apple platforms if it can't support making Swift work better on other platforms in a much more significant way than it has in the past few years. And this all makes sense. Apple developers had been extolling the virtues of Objective C for a long time, including how it is superior to C++. I'm not even arguing for or against that PoV, but Objective C had at least pretty good compiler support on platforms outside of macOS and it did nothing for its adoption. The main place you'd see Objective C on other platforms were in software originally written for macOS, like `unar` on Linux. That's mainly it... Unless you want Swift to fail in the long term, I think this PoV is a very badly losing position.
int_19h 4y ago
I'd say that Swift is more of a general competitor to the likes of C# and Java. The lack of JIT-compiling VM is the obvious difference, but if you set that aside and look at the language itself, I'd say that it's on a similar level of abstraction - a fair bit higher than either Rust or C++.

by jchw 4y ago

mr_00ff00 4y ago

I know this might be opening a can of worms, but technically doesn’t Swift do reference counting? Which is faster than “mark and sweep” GC but will never compare to manual management (like C/C++ and rust ownership) I assume that’s the big reason.

convolvatron 4y ago
indeed. RC isn't universally faster than GC - it depends on workload
rat9988 4y ago
reference counting is not necessarily faster.
- lll-o-lll 4y ago
  It’s not faster in the normal case, it’s generally quite a bit slower. It is more predictable however (you can actually use it with real-time constraints!), and performs better under memory pressure. Whether this is a net benefit depends on what hardware you’re running on and what the app is supposed to be doing.
Jweb_Guru 4y ago
Reference counting is not faster than tracing GC for general purpose workloads, at least not without a lot of extensive tuning that includes stuff like using tracing and moving GC for the young generation (prior to the first collection), deferring reference count increment/decrements using write barriers, limiting reference count bits (and reclaiming stuck objects with some variant of full heap tracing), and so on. Many of these benefits cannot be effectively realized if you insist on prompt execution of finalizers, either. Languages like Rust and C++ gain their performance benefits not from using reference counting or immediate reclamation, but from avoiding creating garbage in the first place by stack allocating most stuff, creating large objects by-value and within vectors to reduce pointer chasing, using direct interior references into data structures in ways that it would be difficult to trace efficiently, and using data structures like arenas to emulate the benefits of generational GC in controlled contexts where a maximum lifetime can be statically determined. My personal feeling is that it's very hard to directly compare manual memory management and GC from a performance perspective because so many of the techniques that make tracing fast involve moving pointers, which is very costly to combine with many of the techniques that make manual memory management fast which rely on values not moving in memory. I think any such solution that is efficient for both kinds of memory will probably require the programmer to have very tight control over when the garbage collector can execute, whether pointers can move at particular times, etc., and the complexity of maintaining that kind of control (and getting it right!) seems so high that I'm not sure it would ever be usable for general purpose programming.
- BulgarianIdiot 4y ago
  The Swift compiler does some of the optimizations/techniques you mention Rust does. It won't reference count, when the setup is possible to analyze statically and elide ref count. Swift also has widely used complex value types, which are stored on the stack. It will also even put some reference types on the stack after doing escape analysis etc. I don't know which benchmark to trust anymore, but for some reason iOS software tends to seemingly overperform comparable ART (GC) code.
  - saagarjha 4y ago
nicoburns 4y ago
I think you’re missing the context that people are choosing Rust over Swift even in domains like backend web development which should theoretically be a good fit for Swift. And this is largely because the Swift ecosystem outside of Apple is pretty minimal.
- xedrac 4y ago
  And frankly, I have zero confidence that Apple will sufficiently invest in the language outside of their ecosystem. That's just not how Apple operates.
karmakaze 4y ago
After using Rust for my own personal tryouts, I liked it more than expected, and though I see the value in the borrow-checker don't work in areas where it's warranted. In most of my uses, I would be fine always using Rc/Arc which would make Rust equivalent to using Swift. As a language though, I much prefer Rust to Swift.
jchw 4y ago
That's certainly a reason, but Go doesn't have the adoption issues that Swift has despite Google's reputation. Go's GC may be fast, and on some workloads maybe even competitive against ARC - But, I really don't think that has anything to do with why Swift isn't seeing widespread adoption outside of the Apple ecosystem. Here's my personal opinion for why. Bear with me for a second. I just searched "Swift programming language" on my search engine and the first result looks promising: > https://developer.apple.com/swift/ https://developer.apple.com/swift/ OK. It's a language by Apple, so it's not surprising that it's on Apple's website, even though I think if you want people to get the idea that it's a serious independent project you probably should give it its own top-level site personally. (edit: Yes, I know it does. This is my honest first impression. Please keep reading.) > Swift is a powerful and intuitive programming language for iOS, iPadOS, macOS, tvOS, and watchOS. Alright, we're only talking about Apple platforms. Technically it doesn't say that it can't work outside of these OSes, but it's clear that Apple is not marketing Swift as a general purpose operating system. From Apple's marketing PoV, it's an operating system that is made for Apple platforms and anything else is incidental. > Download Xcode and learn how to build apps using Swift with documentation and sample code. No download links for users of other operating systems. But if you go to that link, all the way at the bottom, you get: > Swift is developed in the open. To learn more about the open source Swift project and community, visit Swift.org. Finally, you might notice that Swift is actually available outside of macOS. It's available for Windows and Linux, but not BSD as far as I can ascertain. The platform support of Swift is excellent when it comes to Apple devices, but it lags far behind other options when it comes to other platforms and architectures. My perception is that Apple hasn't really made a serious enough investment into making Swift a general purpose programming language outside of its own ecosystem. That's honestly fair, as doing so is no doubt extremely expensive and time-consuming, and it's an on-going investment. What they're doing now appears to kick it to the community, who has done a lot, including as far as I can tell, make Swift work on RISC-V. But Apple is literally the world's biggest technology company, so it's not exactly desirable to put a bunch of community effort into giving it the on-going support that it needs to feel "first-class" outside of Apple platforms. Even just the optics here are quite bad, and I think the fact that it's still like this is going to haunt the long-term prospects of Swift outside of Apple platforms. All of this is aside from its technical merits. Normally, I'd like to stick to purely just technical merits, but unfortunately this stuff does matter. It's part of the reason why Go is still a solid choice today even though Rust has a lot of technical advantages on paper.
jasmer 4y ago
That's definitely the elephant in the room. And the fact that it does not have clean and easy C integration. If you could do direct memory stuff and control the ARC stuff, and easily integrate with C ... ... and the docs were clean, and you could easily use something other than XCode ... Then Swift would be huge. It's a neat language but it's just not designed to go beyond Mac. The entire C++ world would move away in an instant to something clean and flexible. Rust is just too specific for most things, and Swift is just about outside. So sad.
- myko 4y ago
  Using VSCode instead of Xcode should work fairly well: https://www.swift.org/blog/vscode-extension/ https://www.swift.org/blog/vscode-extension/ https://marketplace.visualstudio.com/items?itemName=sswg.swift-lang https://marketplace.visualstudio.com/items?itemName=sswg.swi...
- sweetjuly 4y ago
  I've found Swift->C to interop very well with Swift. Yes, you get absolutely buried in UnsafeXXX wrapped types but it does do exactly what you expected. Going the other way is somewhat "herebe dragons" since @_cdecl is technically non-standardized (though there is a movement to standardize it [1]) but it definitely works fine. [1] https://forums.swift.org/t/formalizing-cdecl/40677/7 https://forums.swift.org/t/formalizing-cdecl/40677/7
- galangalalgol 4y ago
  What do you mean about rust being too specific for most things? It seems like a fairly obvious choic for c++ replacement in a new project, the issue is large c++ codebases already exist, and that migration is painful in my experience. Autocxx type support is still largely missing or in work, diplomat seems reasonable, but I haven't had an opportunity to use it for something real yet.
  - xedrac 4y ago
    I think for Rust to truly replace C++, it needs a better dynamic linking story. I wish they would make their ABI stable within a given edition. That would make it much easier for people to rely on dynamic linking, similar to how C++ does it. Without it, Rust binaries are quite huge.
pkulak 4y ago
If reference counting was faster, Java would do it. It’s better for UIs and lower latency, but a modern, generational GC can beat C in throughput (because allocations get a lot faster).
- mr_00ff00 4y ago
  Genuine question, but if that were true then why does High Frequency Trading and Performance critical applications use C if GCs can beat it?
  - zaphar 4y ago
    The two biggest languages I'm aware of in that space are Java and C++. I don't think I've heard of any shop using C. Java seems to be keeping up with C++ there as far as I know. Do you have evidence to the contrary?
    - mr_00ff00 4y ago
      Yeah I guess I used C and C++ interchangeably, but I believe C++ is the language of HFT. Do you have evidence to the contrary?
      - pjmlp 4y ago
        "Why we chose Java for our High-Frequency Trading application" https://medium.com/@jadsarmo/why-we-chose-java-for-our-high-frequency-trading-application-600f7c04da94 https://medium.com/@jadsarmo/why-we-chose-java-for-our-high-...
        mr_00ff00 4y ago
        I don’t think your article makes the claim Java keeps up with C++. That article seems to be about getting latency low and consistent so Java can compete with C++.
        4y ago

brundolf 4y ago

It's a bummer because I feel like I'd really like Swift if I felt it were a real, durable cross-platform language to spend time learning and using. Some of the trade-offs it makes seem really nice But I don't feel like Swift on non-Apple platforms will ever be more than a hobby for the Apple org

myko 4y ago
What's stopping you from using it on Linux, or your platform of choice? It seems to be supported well enough, and Vapor is a decent toolkit for building a webapp with it.
- techdragon 4y ago
  Speaking as someone with similar feelings… “Well enough” and “decent” are not how I would describe something I’m thinking of investing significant mental time and effort learning and familiarisation building on. I’ve done the basic tutorials and generally like the language ergonomics, it’s not bad, and I kinda like it for the little bit of Apple platform dev I’ve done with it. But it’s basically a different language on any non Apple platform.
- brundolf 4y ago
  My understanding is that it's got second-class Linux support, for now. What happens when Apple loses interest? What about Windows? I don't get a sense of commitment from them outside of their own platforms, and that doesn't make me want to commit to learning or starting major projects in the language (outside of their platforms). If I can't have faith my project's foundation will continue to be solid, then I don't want to build it there; if I know I'll never have an employer who wants to let me use Swift (again, outside of Apple apps) then I don't really want to invest the time to deeply learn it (unless I'm going all-in on Apple apps) I could do a toy project or an iOS app with it, and maybe I will some day, but it's hard for me to feel like it's worth going past that while this is the feeling I'm getting from Apple (And I'm not really even blaming/judging them here; it makes total sense they would want to have a modern in-house language that's perfectly integrated with their systems and now their chipsets, and lets them ship more effectively. They don't owe anyone more than that. It's just a shame, for me personally, to think about what else could have been)

wilg 4y ago

This is all very hand-wavey. Are you just describing a chicken-and-egg scenario? Also, Swift probably can compete with Rust, especially when they finish adding Rust-style lifetimes. But the real advantage of Swift is it has a much more "high-level" feel than Rust – it's much more familiar to use than Rust by virtue of having classes and things. Swift also doesn't instantly force you into weeds of dealing with memory management complexity. I think I'm going to enjoy the "drop into manual memory management for hot paths" approach Swift is taking.

acomjean 4y ago
I think swift competes more with go than rust.
- bsaul 4y ago
  From an aestethic pov, swift is taking the exact opposite direction than go: it keeps piling on more language features, with much less concerns on keeping the language simple. As a developer currently working in both, it feels like jumping to another civilisation every time i switch.
verdagon 4y ago
I'm particularly interested in this line of thinking, and I'd probably lean the same way. Would love to hear more, why do you think it's a better approach to default to more high-level, with the ability to drop down into manual memory management for hot paths?
- wilg 4y ago
  Simply because hot paths are less common for a "typical" workload. So you'd want it to be more ergonomic by default. Where possible, jam all optimizations into the compiler so nobody has to think about it. If you can't do that, then allow developers to give the compiler more information even if it's more complex. Relatedly, it allows the language to help you "first make it work, then make it good".
jchw 4y ago

deleted 4y ago

[deleted]

Kukumber 4y ago

People are busy using Swift rather than trying to religiously advocate for Rust on various websites One example: Arc is a webkit powered browser written in swift and is crossplatform: https://twitter.com/hursh/status/1612472691747090432 https://twitter.com/hursh/status/1612472691747090432

saagarjha 4y ago
Don’t think it is yet, and it uses Chromium
jchw 4y ago
No doubt people are busy using Swift, but Apple technology advocates are about as "religious advocates" as they come. And frankly, I'm not trying to say that as some kind of negative. It can be annoying, but clearly Apple users are genuine enthusiasts, even if I can't really see eye-to-eye with them. I do think that this genuine enthusiasm creates some distorted images of the reality of the world, though. The thing is, Apple users are likely so used to having more enthusiasm than competing communities of higher marketshare products and services that it's not surprising at all that the perception is that Rust is all hype. I'm more a Go coder than Rust by SLoC, and Rust has to be one of the most enthusiastically supported languages I've ever seen. Still, it'd be silly to discredit Rust on the basis of its enthusiastic userbase: it's successful by any measure. It's invading the Linux kernel, the campuses of Amazon, Google, Microsoft, it's going to be in both Firefox and Chromium, and that's really just the beginning. Even if Swift had more collective SLoC than Rust, Rust is clearly on its way to solidifying its place as one of the most impactful programming languages of the past 20 years. That impact is even going to be felt in Swift: when talking about Swift, it is very common to advertise it in terms of Rust. I mean hell, that's basically what this blog post title does: "Look, Swift did something even Rust couldn't!" -- If Rust wasn't so influential, I do not think anyone would bother to compare the two in this way.
- Kukumber 4y ago
  for 1 article like this, you get 1000000 ones from "rust evangelists from the Rust Evangelism Strike Force" both can coexist, yet for the rust crowd only one must prevail that's what's annoying about rust and its religious community my previous comment's score is (-1), that speaks for itself don't you think ;)

pjmlp 4y ago

I would say it is the reverse on what concerns Apple platforms, Rust isn't a competitor to Swift. It will never have tooling parity with Swift. Trying to use Rust instead of Swift on Apple platforms is only for those that enjoy the pain of creating ecosystems from scratch.

jchw 4y ago
Definitely! There's only one enormous issue with this outlook: the rest of the world is bigger. Much bigger. Exactly how much bigger depends on who you ask, but it's a lot bigger. Just on the consumer side... https://gs.statcounter.com/os-market-share https://gs.statcounter.com/os-market-share Maybe it doesn't matter because developers prefer macOS, so the rest can be treated as a secondary case? Not even close. https://survey.stackoverflow.co/2022/#section-most-popular-technologies-operating-system https://survey.stackoverflow.co/2022/#section-most-popular-t... What about servers? Network services and SaaS are a huge industry, of course. Admittedly, I can't even find a good source for what marketshare macOS has: most "server marketshare" counts seem to exclude it or just merge it in with "UNIX-likes". The number appears to be extremely small. There's definitely some exceptions; I think Imgix has been deploying Macs to the datacenter. However, in order to do so, they essentially had to build custom rack mount equipment for desktop machines... I think it's very safe to say that macOS deployments for services are extremely in the minority, and the majority of macOS data center deployments aren't even for general network services specifically but mainly just for CI. OTOH, macOS Server and any "server" SKUs of Macs have been discontinued as far as I know. "Rust isn't a competitor to Swift" is not the zinger in Apple's favor that you think it to be. In fact, Apple would be best to support making Rust work better on Apple platforms if it can't support making Swift work better on other platforms in a much more significant way than it has in the past few years. And this all makes sense. Apple developers had been extolling the virtues of Objective C for a long time, including how it is superior to C++. I'm not even arguing for or against that PoV, but Objective C had at least pretty good compiler support on platforms outside of macOS and it did nothing for its adoption. The main place you'd see Objective C on other platforms were in software originally written for macOS, like `unar` on Linux. That's mainly it... Unless you want Swift to fail in the long term, I think this PoV is a very badly losing position.

int_19h 4y ago

I'd say that Swift is more of a general competitor to the likes of C# and Java. The lack of JIT-compiling VM is the obvious difference, but if you set that aside and look at the language itself, I'd say that it's on a similar level of abstraction - a fair bit higher than either Rust or C++.