4 ms·

I have not looked at Swift since I last wrote some around maybe v3. I hear that it's generally not a competitor to Rust, and is only really useful within the Ap

I have not looked at Swift since I last wrote some around maybe v3. I hear that it's generally not a competitor to Rust, and is only really useful within the Apple ecosystem. Why is it not more useful as a C++ alternative, since I think that's kind of what the initial goal was? Is it just that non-Apple support is new-ish and not yet matured? Or a more fundamental issue?

jonny_eh 1y ago
Apparently Arc Browser is written in Swift: https://www.reddit.com/r/ArcBrowser/comments/18j39g3/why_arc_using_swift_programming_language_under/ https://www.reddit.com/r/ArcBrowser/comments/18j39g3/why_arc...
briandear 1y ago
Generally only useful within the Apple ecosystem is definitely inaccurate. An example: https://vapor.codes/ https://vapor.codes/ The problem is that people only think it’s generally useful in the Apple ecosystem.
- AnishLaddha 1y ago
  what advantages does swift offer over go/rust/js/java for server side programming? I always presumed the advantages of swift were native code compilation + top tier integration w/the apple ecosystem.
  - amichail 1y ago
    It's a high level language that doesn't get in your way.
  - madeofpalk 1y ago
    In my little usage of it (and go and rust), Swift feels like a nice middleground between go and rust. Or, a better (safer) go. I think Swift is vastly underestimated due to it's relation to Apple.
    - hocuspocus 1y ago
      I don't think people care about its relation to Apple, they care about the language ecosystem, roadmap and evolution that were shaped by Apple's needs for iOS and macOS before there was a real attempt at making Swift more general purpose and multi-platform. And now that it's somewhat there, there are better options in almost every dimension.
  - favorited 1y ago
    I have a few personal and professional Swift on server projects, in the wild and in the works. Code reuse is a big win – we can ~easily expose functionality of our client apps to other systems. Familiarity is another – there's an ocean of iOS (and, to a lesser extent, macOS) developers out there who are familiar with Swift. With a little bit of coaching, they can pretty quickly get up to speed with how services work. It reminds me a lot of what it was like to ship Node.js software 15 years ago – the ecosystem is still young, but there are enough resources out there to solve 95% of the problems you'll face.
  - 725686 1y ago
    The advantage is obvious if you already use Swift.
  - rcruzeiro 1y ago
    In my experience, writing Swift for the backend feels a lot like writing TypeScript, but nicer — though that’s just a personal preference. You get the performance of a compiled language like Rust (though that’s rarely a bottleneck for backend applications), but Swift is significantly easier than Rust and has much faster compile times.
- ackfoobar 1y ago
  I don't use Swift not because I think it's not useful outside Apple, but because I believe its developer experience is poor. Some stories that formed my opinions: https://news.ycombinator.com/item?id=9947193 https://news.ycombinator.com/item?id=9947193 https://news.ycombinator.com/item?id=42803489 https://news.ycombinator.com/item?id=42803489 Granted, my perception may be wrong, but trying it to know for sure costs time. Swift has not earned my time investment.
  - rcruzeiro 1y ago
    The second example is moot since, outside the Apple ecosystem, you don't even need to know Xcode exists.
- ardit33 1y ago
  They have stalled, and the concurency is making things harder to implement right. Basically, Vapor has to be re-written as it is, in order to work will with swift 6+. Which kinda kills already any little moment it had. Was looking to use it with a new project, as it is a nice framework, but going with GoLang on the server side due to all this in flux changes.
afavour 1y ago
There’s a level of self fulfilling prophecy here: people don’t use Swift off Apple platforms because there isn’t a critical mass of people using Swift off Apple platforms. But that said it can be frustrating. A lot of the documentation and tutorials you find out there assume you’re on an Apple platform where, e.g. Foundation APIs are available. And the direction of the language, the features being added etc, very clearly serve Apple’s goals. (Side note: IBM was an early adopter of Swift off-platform but then stepped back: https://forums.swift.org/t/december-12th-2019/31735 https://forums.swift.org/t/december-12th-2019/31735)
- rcruzeiro 1y ago
  Knowing which parts of Foundation will explode on your face on Linux is most of the challenge of doing non-Apple Swift code.
  - jshier 1y ago
    None, if you stick to using the bits from swift-foundation instead of swift-corelibs-foundation. Confusing, but the new code is much better, and in production on Apple's platforms as well.
porcoda 1y ago
I use it as a C++ alternative on Linux. We ported a substantial code base from C++ to Swift last year and it works great. Performance is better in some places, comparable to C++ in others. Productivity is definitely improved over the C++ codebase. We didn’t use rust for this project after evaluating how that migration would impact how it was designed internally, and we decided it wasn’t the right way to go. I think the “swift is only relevant in apple ecosystem” view is inaccurate these days. Swift certainly isn’t the answer to every project, just like rust or any other language isn’t the universal answer to every project. It’s worth considering though if it is appropriate.
- rcruzeiro 1y ago
  There is this belief that Swift is not really useful outside of the Apple ecosystem or is somehow clunky, and that could not be farthest from the truth. In fact, having written a few backends in Swift, I can say that the experience of writing a Swift backend on Linux was much more ergonomic than what I am used to with writing Swift for iOS.
deleted 1y ago
[deleted]
pkulak 1y ago
You can't really say a language with a garbage collector (Swift) is an alternative to one without (Rust, C++, etc), because a lot of the time, the reason someone is using a non-GC language is because they don't want a GC. EDIT: Yes, ref. counting is garbage collection, before the replies blow up. haha
- favorited 1y ago
  > a language with a garbage collector (Swift) You can certainly make the case that reference counting is a form of garbage collection, but it is absolutely false to say Swift has "a garbage collector." There is no runtime process that is responsible for collecting garbage – allocated objects are freed deterministically when their reference count hits zero. The same thing is true of `shared_ptr` instances in C++, and there's certainly no "garbage collector" there, either.
  - pkulak 1y ago
    That reference counting is done at runtime. It’s a runtime garbage collector. It’s different than a generational GC, but it’s GC. Those cycles to increment and decrement a counter attached to every object at ever touch aren’t free. All the downvotes in the world won’t make that free.
    - favorited 1y ago
      > It’s a runtime garbage collector What does "it" refer to? The function calls to _swift_release_()? Because if function calls are a "garbage collector," then free() is a garbage collector. And if free() is a garbage collector, then the term is too vague to have any useful meaning.
      - pkulak 1y ago
        Yes. Garbage collectors also call free. They call functions. They do all kinds of things. They even increment and decrement reference counters on your behalf. When there’s a system that manages your memory for you at runtime, that’s a garbage collector. Swift is great. And reference counting is exactly the right kind of GC for UIs because there are no pauses. But GC it still is. And it wrecks throughput and is not appropriate for situations where you don’t want GC. And in reference to `shared_ptr`, or Rc and Arc in Rust, that's manual memory management because you're doing it... manually. Swift is like C++ or Rust if you were never allowed to have a reference to anything that wasn't behind an Arc. Then it's no longer manual, it's automatic.
lukeh 1y ago
Also using it in an embedded Linux project [1]. 75% of code written for this project is Swift. The rest is Dart and C/C++. It’s a productive language. [1] https://forums.swift.org/t/an-embedded-audio-product-built-with-swift/77671 https://forums.swift.org/t/an-embedded-audio-product-built-w...
Hashex129542 1y ago
For hobby programming at first I picked Java for the alternative to C++ and then Swift since 10 years. I really thought Swift language is the one which going to replace the Python. How dump I am. It's supposed to be. Because of SwiftUI, the direction of Swift language changed. The so called open source label is not fit to the Swift language. May be we can call it as free programming language by Apple. I used vapor server also and now I think that Swift really has advantage for cross platform development. Just because of SwiftUI they've to adopt nonsense updates. IBM took greater decision on Kitura. Vapor is still with Swift version 5.9; Let's see how it's ends.
viktorcode 1y ago
Unlike Rust, it has some C++ binding, which is extremely useful.

jonny_eh 1y ago

Apparently Arc Browser is written in Swift: https://www.reddit.com/r/ArcBrowser/comments/18j39g3/why_arc_using_swift_programming_language_under/ https://www.reddit.com/r/ArcBrowser/comments/18j39g3/why_arc...

briandear 1y ago

Generally only useful within the Apple ecosystem is definitely inaccurate. An example: https://vapor.codes/ https://vapor.codes/ The problem is that people only think it’s generally useful in the Apple ecosystem.

AnishLaddha 1y ago
what advantages does swift offer over go/rust/js/java for server side programming? I always presumed the advantages of swift were native code compilation + top tier integration w/the apple ecosystem.
- amichail 1y ago
  It's a high level language that doesn't get in your way.
- madeofpalk 1y ago
  In my little usage of it (and go and rust), Swift feels like a nice middleground between go and rust. Or, a better (safer) go. I think Swift is vastly underestimated due to it's relation to Apple.
  - hocuspocus 1y ago
    I don't think people care about its relation to Apple, they care about the language ecosystem, roadmap and evolution that were shaped by Apple's needs for iOS and macOS before there was a real attempt at making Swift more general purpose and multi-platform. And now that it's somewhat there, there are better options in almost every dimension.
- favorited 1y ago
  I have a few personal and professional Swift on server projects, in the wild and in the works. Code reuse is a big win – we can ~easily expose functionality of our client apps to other systems. Familiarity is another – there's an ocean of iOS (and, to a lesser extent, macOS) developers out there who are familiar with Swift. With a little bit of coaching, they can pretty quickly get up to speed with how services work. It reminds me a lot of what it was like to ship Node.js software 15 years ago – the ecosystem is still young, but there are enough resources out there to solve 95% of the problems you'll face.
- 725686 1y ago
  The advantage is obvious if you already use Swift.
- rcruzeiro 1y ago
  In my experience, writing Swift for the backend feels a lot like writing TypeScript, but nicer — though that’s just a personal preference. You get the performance of a compiled language like Rust (though that’s rarely a bottleneck for backend applications), but Swift is significantly easier than Rust and has much faster compile times.
ackfoobar 1y ago
I don't use Swift not because I think it's not useful outside Apple, but because I believe its developer experience is poor. Some stories that formed my opinions: https://news.ycombinator.com/item?id=9947193 https://news.ycombinator.com/item?id=9947193 https://news.ycombinator.com/item?id=42803489 https://news.ycombinator.com/item?id=42803489 Granted, my perception may be wrong, but trying it to know for sure costs time. Swift has not earned my time investment.
- rcruzeiro 1y ago
  The second example is moot since, outside the Apple ecosystem, you don't even need to know Xcode exists.
ardit33 1y ago
They have stalled, and the concurency is making things harder to implement right. Basically, Vapor has to be re-written as it is, in order to work will with swift 6+. Which kinda kills already any little moment it had. Was looking to use it with a new project, as it is a nice framework, but going with GoLang on the server side due to all this in flux changes.

afavour 1y ago

There’s a level of self fulfilling prophecy here: people don’t use Swift off Apple platforms because there isn’t a critical mass of people using Swift off Apple platforms. But that said it can be frustrating. A lot of the documentation and tutorials you find out there assume you’re on an Apple platform where, e.g. Foundation APIs are available. And the direction of the language, the features being added etc, very clearly serve Apple’s goals. (Side note: IBM was an early adopter of Swift off-platform but then stepped back: https://forums.swift.org/t/december-12th-2019/31735 https://forums.swift.org/t/december-12th-2019/31735)

rcruzeiro 1y ago
Knowing which parts of Foundation will explode on your face on Linux is most of the challenge of doing non-Apple Swift code.
- jshier 1y ago
  None, if you stick to using the bits from swift-foundation instead of swift-corelibs-foundation. Confusing, but the new code is much better, and in production on Apple's platforms as well.

porcoda 1y ago

I use it as a C++ alternative on Linux. We ported a substantial code base from C++ to Swift last year and it works great. Performance is better in some places, comparable to C++ in others. Productivity is definitely improved over the C++ codebase. We didn’t use rust for this project after evaluating how that migration would impact how it was designed internally, and we decided it wasn’t the right way to go. I think the “swift is only relevant in apple ecosystem” view is inaccurate these days. Swift certainly isn’t the answer to every project, just like rust or any other language isn’t the universal answer to every project. It’s worth considering though if it is appropriate.

rcruzeiro 1y ago
There is this belief that Swift is not really useful outside of the Apple ecosystem or is somehow clunky, and that could not be farthest from the truth. In fact, having written a few backends in Swift, I can say that the experience of writing a Swift backend on Linux was much more ergonomic than what I am used to with writing Swift for iOS.

deleted 1y ago

[deleted]

pkulak 1y ago

You can't really say a language with a garbage collector (Swift) is an alternative to one without (Rust, C++, etc), because a lot of the time, the reason someone is using a non-GC language is because they don't want a GC. EDIT: Yes, ref. counting is garbage collection, before the replies blow up. haha

favorited 1y ago
> a language with a garbage collector (Swift) You can certainly make the case that reference counting is a form of garbage collection, but it is absolutely false to say Swift has "a garbage collector." There is no runtime process that is responsible for collecting garbage – allocated objects are freed deterministically when their reference count hits zero. The same thing is true of `shared_ptr` instances in C++, and there's certainly no "garbage collector" there, either.
- pkulak 1y ago
  That reference counting is done at runtime. It’s a runtime garbage collector. It’s different than a generational GC, but it’s GC. Those cycles to increment and decrement a counter attached to every object at ever touch aren’t free. All the downvotes in the world won’t make that free.
  - favorited 1y ago
    > It’s a runtime garbage collector What does "it" refer to? The function calls to _swift_release_()? Because if function calls are a "garbage collector," then free() is a garbage collector. And if free() is a garbage collector, then the term is too vague to have any useful meaning.
    - pkulak 1y ago
      Yes. Garbage collectors also call free. They call functions. They do all kinds of things. They even increment and decrement reference counters on your behalf. When there’s a system that manages your memory for you at runtime, that’s a garbage collector. Swift is great. And reference counting is exactly the right kind of GC for UIs because there are no pauses. But GC it still is. And it wrecks throughput and is not appropriate for situations where you don’t want GC. And in reference to `shared_ptr`, or Rc and Arc in Rust, that's manual memory management because you're doing it... manually. Swift is like C++ or Rust if you were never allowed to have a reference to anything that wasn't behind an Arc. Then it's no longer manual, it's automatic.

lukeh 1y ago

Also using it in an embedded Linux project [1]. 75% of code written for this project is Swift. The rest is Dart and C/C++. It’s a productive language. [1] https://forums.swift.org/t/an-embedded-audio-product-built-with-swift/77671 https://forums.swift.org/t/an-embedded-audio-product-built-w...

Hashex129542 1y ago

For hobby programming at first I picked Java for the alternative to C++ and then Swift since 10 years. I really thought Swift language is the one which going to replace the Python. How dump I am. It's supposed to be. Because of SwiftUI, the direction of Swift language changed. The so called open source label is not fit to the Swift language. May be we can call it as free programming language by Apple. I used vapor server also and now I think that Swift really has advantage for cross platform development. Just because of SwiftUI they've to adopt nonsense updates. IBM took greater decision on Kitura. Vapor is still with Swift version 5.9; Let's see how it's ends.

viktorcode 1y ago

Unlike Rust, it has some C++ binding, which is extremely useful.