The fact that Apple provides all these incredible platform specific frameworks and libraries for graphics, audio, games, GPU kernel programming, and more, it’s just the icing.
How exactly are protocols a Swift "upgrade" to OO programming? They were in Objective-C since the mid 90s, adopted by Java as interfaces, copied by C# etc.
Also, protocols in Swift have a huge performance downside, because they decided to have them work across structs and classes: if you use a protocol in a function argument, the compiler doesn't even know the size of the argument at compile time, so copying the arguments has to be dynamically dispatched unless the compiler can figure it out in an extra optimisation pass...that's not possible when doing separate compilation.
> Runs reasonably fast, on par with Go or Java.
A downgrade...particularly considering the epic compile times.
> named parameters
Also there since the 80s, in a less weird way.
https://blog.metaobject.com/2020/06/the-curious-case-of-swif...
> ...professionally used about half a dozen languages ...
What languages were those, if I may ask?
Never had a problem with long compile times -- once you have your initial build, 90% of the time or more the incremental build process is very fast.
The languages I used for about 15 years were ObjC, C, C++, Clojure (and other langs before that). I find Swift to be a thoughtful blend of the key features of these four languages -- each of the things I like most about those langauges are in Swift, but it's the syntax in particular that I like most.
Hmm...not sure how else to interpret "upgrade to OO programming with use of protocols" other than that there was an upgrade to OO, and that upgrade was with the use of protocols. Now it looks like you meant an upgrade of the way protocols are used in OO, but you won't say how they Swift's protocols actually constitute an upgrade.
OK. ¯\_(ツ)_/¯
Typically you would write more protocol-oriented code - rather than using inheritance (which is mostly there for Objective-C compatibility) you define protocols and implement them for types.
This is a lot closer to traits in Rust than interfaces in Java. Among other things, a developer can define how a third party type implements a protocol they control, without subclassing or wrapping, as long as it does not require additional data.
No need for Google, as mentioned, I know both languages.
As for protocols not being encouraged in Objective-C, I migth own the wrong NeXTSTEP manuals.
(as a sibling comment pointed out, swift protocols are typically used for things that in objc you would use inheritance)
The kind of documentation that inspired Java authors.
https://cs.gmu.edu/~sean/stuff/java-objc.html
https://en.wikipedia.org/wiki/Portable_Distributed_Objects
https://en.wikipedia.org/wiki/Distributed_Objects_Everywhere
Having to deal with weakself, no reference cycles, very limited closures, having to deal with Xcode, no integration with any other IDE because Apple Apples, debatable generics, SPM, debatable cross platform abilities, fucking Tasks and Actors, SwiftUI being locked to versions of Swift, extremely limited community, few high quality open source libraries for something that only performs as well as Java is quite the hard sell.
For that price, you could also get Kotlin which fixes most of Java's problems and provides access to all the JVM as well as Kotlin/Native, with top tier DSL abilities and a really well thought out stdlib, coroutines, reified funs and much more.
Swift has LSP integration, and has an official extension for VSCode, which works very well. They even have a blog post about it https://www.swift.org/blog/vscode-extension/
2016: https://9to5mac.com/2016/02/22/ibm-swift-cloud-kitura/
2016: https://www.infoq.com/presentations/swift-server/
2020: https://www.infoq.com/news/2020/01/ibm-stop-work-swift-serve...
You can run it in docker: https://hub.docker.com/_/swift
for now
just saw an article about IBM deleting most of their website because its a mess. It was some linkedin developer's post.
(Also, it’s Xcode)
It is the most similar in terms of language features and style but it has access to Java's unparalleled library and tooling ecosystem.
The standard library is becoming cross-platform as we discuss it here.
I'd argue that it's too late already, the ship has sailed, Swift is heading the same way as C#.
Is it just that the maintenance cost is not worth it? Or would it threaten its ecosystem in a way that I don't understand?
It would seem that making Swift cross-platform would make Apple's ecosystem more accessible to developers. The barrier to entry would be lower if developers only needed to learn the APIs and not a whole new language and its tooling too. This would help the ecosystem stay healthy for a longer time.
The greatest barrier to entry is XCode. It's archaic, impossible to extend, and has a very wide surface that would overwhelm any development team.
(Java works fine on macOS, but developers want to deploy to iOS.)
[1]: https://learn.microsoft.com/en-us/dotnet/maui/ios/cli
[2]: https://docs.avaloniaui.net/tutorials/developing-for-mobile/...
Hence why Kotlin only really matters on Android.
i think kotlin has more use outside compared to swift.
But a language has to start somewhere, so i wouldn't hold it against swift. It's a fairly well done language regardless, and nothing apple specific about it tbh (which are all just libraries).
It was JetBrains pet project to fix archaic stuff in Java without making a Scala. It was designed from the get go for a wide base (as wide as java).
I'm not sure how it became Android's main target, but I doubt it was the original purpose.
Honestly the only times I've evaluated Kotlin for personal projects was bc of that flexibility.
If that was the case, they would have adopted Dart instead of keeping an high dependency on the Java ecosystem for Android.
Android Studio, Gradle, Kotlin compiler, the libraries that Android depends on from Maven Central, all Java.
Try to use Kotlin without the Android ecosystem, it is just syntax sugar for the JVM.
I agree and would go so far as to say that Dart is a better comparison to Swift than Kotlin is.
It helped a lot that I think Jetbrains took advantage of all they could to make development in Kotlin very smooth, I remember back then people joked how Kotlin worked so flawlessly on Android Studio almost like it was the main language while on Xcode Swift was slow, the highlight would stop working constantly, refactoring was not supported, often indexing the project would hang forever etc.
It's like Rust in that it offers memory safety by default without a big performance hit.
Apple has been writing OS components in Swift for a while now. It certainly doesn't seem to be producing the performance issues we saw when Google attempted to write components for Fuchsia in Go or Microsoft's effort to create new features for Longhorn in .NET.
My experience with Swift is somewhat limited, because every time I've tried to use it, I've run into glaring performance issues and had to switch language. It might be reasonably performant compared to Go or .NET, but it's nothing like Rust.
Do you have a reference somewhere I can read up?
Add a little bit of salt to insult you need it to be atomic if you want it to run on SMP. This means for each time you have create/release the lifetime of an object you will make a lot of memory barriers, and create a lot of cache contention.
But in practice the overhead is actually nought, and most of the time you rather deal with I/O bound problem more than an additional atomic increment operation. Modern processor is fast enough to deal with them in few cycles in around the order of 10 nanoseconds
Hopefully the upcoming ownership functional will help in those cases.
Most of the time it’s possible to avoid atomic instructions and still be thread-safe. https://dl.acm.org/doi/10.1145/3243176.3243195:
“BRC is based on the observation that most objects are only accessed by a single thread, which allows most RC operations to be performed non-atomically. BRC leverages this by biasing each object towards a specific thread, and keeping two counters for each object --- one updated by the owner thread and another updated by the other threads. This allows the owner thread to perform RC operations non-atomically, while the other threads update the second counter atomically. We implement BRC in the Swift programming language runtime, and evaluate it with client and server programs. We find that BRC makes each RC operation more than twice faster in the common case. As a result, BRC reduces the average execution time of client programs by 22.5%, and boosts the average throughput of server programs by 7.3%.”
I remember reading that this made it into Swift, but cannot find it, so I’m not sure anymore.
And of course, the Swift compiler tries to avoid unnecessary refcount updates.
According to information released when the M1 came out: retaining and releasing an NSObject takes ~30 nanoseconds on current gen Intel, and ~6.5 nanoseconds on an M1
(or if going with BRC, correspondingly there shouldn't be a advantages for this custom CPU feature)
So they went with plan B, having the compiler automate the retain/release messages used by the Cocoa framework.
Everywhere else in Objective-C, the memory is still manually managed, or via memory pools.
Chris Lattner (of LLVM fame) did design the language with the goal of hiding complexity until it is needed.
> The concept of progressive disclosure in Swift, where you can start with something very simple and then learn complexity as you go, was totally driven by making it teachable. I personally spent a lot of time trying to make sure that the introduction to Swift could just be print("Hello World"). No semicolons, no \ns, none of that public static void main stuff. Making it simple and approachable was a strong goal, and not in a weird way where in a teaching environment there is this “Swift Prime” language that’s similar but different.
https://oleb.net/blog/2017/06/chris-lattner-wwdc-swift-panel...
You might be surprised (I was). Most of the benchmarks I’ve seen place it more in the neighborhood of golang and v8, rather than the C, C++, rust neighborhood you might expect.
Another commenter in this thread highlighted that the ref-counting GC is what keeps it out of the C / Rust performance neighborhood.
So not even sure that GC has always a perf cost is always true.
Not saying it doesn't in some cases, just so that we are clear but the truth seems to be more nuanced.
[0] https://arc.net/
It took real effort from Microsoft into the Open Source space to make it more widely popular. Far away from Java or JavaScript, but I see many similarities between the development and evolution of Swift and C#.
Almost everything starts as a domain specific language. Same goes for JavaScript. First browser only, then through Node, suddenly JavaScript everywhere.
Python gained massive traction through Jupyter. Before that, I found Python a clumsy alternative to JavaScript. Since then I have changed my mind. ;)
I tried Swift for Linux, and soon realized it was a meh experience (NS this, NS that... NextStep is still there) and switched back to Rust.
It could have been a strong Rust alternative.
“No one”
Yet The Browser Company (The one that is hyping the Arc Browser) is writing their browser in Swift to support Windows. [0] which that is their main product.
The Browser Company is not “No one”.
[0] https://m.youtube.com/watch?v=Xa_fNuaSE_I
EDIT: So this video doesn't show someone choosing Swift outside of Apple and using on a different platform (Windows) and doesn't disprove the claim of "No one outside Apple chooses Swift"?
Surely you can do better than some of the very low effort replies below.
Brave (VC funded) is also a Chromium wrapper and Edge (Microsoft owned) is also one as well and both of the somehow managed to beat Firefox in usage. So what is you point?
Chrome and its derivatives is the reason why browsers like Firefox is failing to keep up and continues to lose users.
Using anything other than Chrome for a modern web browser is a losing battle. (Brave already tried that with Firefox and quickly switched to Chrome)
I was answering a question asking what it was. Are you saying my answer was wrong?
> Brave (VC funded) is also a Chromium wrapper and Edge (Microsoft owned) is also one as well and both of the somehow managed to beat Firefox in usage.
Well that's just false.
Firefox has 7.7% marketshare.
Brave comes in at less than 1 tenth of a percent.
Edge, does better after all it is the _default_ browser on the most popular desktop OS by a massive margin. It gets <6% of the market.
So Firefox has greater market share than both of those combined.
> Chrome and its derivatives is the reason why browsers like Firefox is failing to keep up and continues to lose users.
You mean Chrome. None of the "derivatives" other than Edge (due to default browser syndrome) and Opera (which gets 2%) have any marketshare, and neither does anything to prevent Google from doing whatever it wants.
> Using anything other than Chrome for a modern web browser is a losing battle.
The reason is very very simple: Chrome is the modern IE, and making content that only works in Chrome (or wrappers) is considered acceptable by the same mediocre developers that made IE only sites a decade ago.
On the other hand, I get where you are coming from: people also said the same thing about using anything other than IE.
No. That's an exciting fictional world in which you live, and was not the case. Even in the last years preceding Google's chrome release and massive marketing push, when Firefox and Safari were taking "significant" marketshare, it was assumed IE would be forever, and IE-only sites were still common (and the norm in "enterprise" software).
There is literally no difference between a developer that says everyone uses/should use chrome, and a developer a decade ago saying the same thing about IE.
[0] https://arc.net
Sorry for the joke, know it is frowned upon, did it anyway.
iOS/macOS devs use Swift on other platforms because it's the only language they know, yeepidodadey. Ignore the fact that 99% of their project is cinterop with Chromium
It's valuable to Apple to have a language perfectly tuned to their stack, as the official entrypoint to all their APIs. If you need to use those APIs, you're excited about Swift. If you don't, you aren't
Many people are more than happy to do all their career on a specific platform.
And not at all compatible or easily bridgeable with obj-c, which was not optional.
Swift for example defaults to copyable value types and reference types that are refcounted because that is what is most often needed for evented application code, while Rust defaults to non-copyable objects (with wrappers for things like reference counting) because of its systems development focus.
Swift also had a hard requirement of a decade of co-existance with Objective-C. A significant number of Swift types toll-free bridge with objc (and corefoundation) alternatives, and that had a considerable impact on the standard library. Their base library would be different from Rust's "std" due to needing different implementations of strings, vectors, dicts and so on.
The two do take quite a bit of inspiration from one another, and will gradually grow to support an ever-larger overlapping set of use cases, but the design constraints of the existing language will still mean that one or the other is better for a specific task.
EDIT: wait, I'm reading that swift does not have a garbage collector. I guess I don't see how it differs from Rust then.
EDIT2: ah I see, everything's a smart pointer basically and memory's released at the end (RAII-style), whereas Rust has the borrow checker (but it's still RAII-style). I guess both implement RAII ideas, but Rust seems to do it at compile time and Swift at run time.
That's like...Apple's whole deal. Proprietary everything top-to-bottom.
I do quite like Swift overall -- it’s usually terser than Obj-C and I like the much stricter and more expressive type system. But you pay for that with much longer compile times, and the tooling feels much the same (Xcode is still Xcode).
The decline in the docs is due to a number of factors, but I would say mainly it's (1) the relentless annual major OS update schedule, (2) the proliferation of OS (macOS, iOS, watchOS, tvOS, xrOS?), (3) the dual language stack, (4) Apple personnel turnover.
Apple had a bad experience with GC in ObjC with libauto and learned their lesson that C and GC just don’t mix. You can never have a truly modern GC in C, because C cannot provide any of the guarantees that a GC needs to move objects around.
Using a modern GC entails sealing the language off in a bubble. Since Swift is mostly used to interface with system frameworks, you would end up paying a cost when interfacing with the system frameworks written in ObjC, making your modern GC useless most of the time.
It's a modern statically compiled language with complex generics, that supports providing a generic interfaces in libraries with retaining ABI compatibility. Which no other modern "system" language supports. That's fairly technically interesting to me.
> We have so much more than that and you just went with reference counting
Like what?
The options for memory safe shared ownership are refcounting or GC.
Assuming you're talking about rust, that's just C++: object lifetime is lexical, and if you need it to last longer you have to use Arc/Rc/shared_ptr. The purpose of the lifetime and borrow checkers is to ensure exclusive access, and reduce the copy/destruction churn that you get from the C++ model (a hypothetical C++ that only allows the use of unique_ptr instead of raw pointers - obviously C++'s type system and approach to memory safety is not a Good Thing).
But it's important to realize rust did not create a new solution to object lifetime management for shared objects.
It's also important to realize that rust was designed in an environment where there was no existing code to interoperate with, whereas Swift was designed to work with the existing Darwin APIs and objective-c which are all refcounted. So even if no refcounting was the goal you'd end up with a new language, designed for a specific environment, and the default behaviour would not be correct.
Now that the language is more established, and it's less critical for every part of the language to have objc interop they are working on pure ownership semantics, for the same reason as rust: it saves copies without requiring a refcount[1]
[1] https://github.com/apple/swift/blob/main/docs/OwnershipManif...