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)
[1] https://forums.swift.org/t/an-embedded-audio-product-built-w...
An example: https://vapor.codes/
The problem is that people only think it’s generally useful in the Apple ecosystem.
I think Swift is vastly underestimated due to it's relation to Apple.
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.
https://news.ycombinator.com/item?id=9947193
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.
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.
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.
EDIT: Yes, ref. counting is garbage collection, before the replies blow up. haha
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.
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.
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.
Ok, what is calling `free` here? Point to the garbage collector. Show me the thing that is collecting the garbage.
> And in reference to `shared_ptr`, or Rc and Arc in Rust, that's manual memory management because you're doing it... manually.
You're also doing it manually when you decide to make a type a class in Swift. You're opting in to reference counting when you write a class, or use a type that is backed by a class.
It also seems that our goalposts have gone missing. Before, "it" (whatever "it" is) was a garbage collector because it happened at runtime:
> That reference counting is done at runtime. It’s a runtime garbage collector.
shared_ptr, Rc, and Arc also manage their memory at runtime. But now, "it's" a garbage collector because the compiler generates the retain/release calls...
But fine, no GC. I wonder why every language in the world doesn’t use reference counting, since it’s not GC AND you don’t have to clean up any memory you allocate. I guess everyone who ever designed a language is kinda dumb.
That's not the reason it uses reference counting. The overhead of scanning memory is too high, the overhead of precisely scanning it (avoiding false-positive pointers) is higher, and the entire concept of GC assumes memory can be read quickly which isn't true in the presence of swap.
That said, precise GC means you can have compaction, which can potentially be good for swap.
I thought Swift uses ARC just like Objective-C? The compiler elides much of the reference counting, even across inlined functions. It’s not like Python or Javascript where a variable binding is enough to cause an increment (although IIRC the V8 JIT can elide some of that too).
I don’t disagree that it’s a runtime GC but there’s a bit of nuance to its implementation that resists simple categorization like that.