Advantages of Swift and SwiftUI? Nevermind, I'll try to answer both:
For Swift it's a modern language that doesn't need to have backward compatibility with C that Objective-C had. It has a very expressive syntax and uses modern idioms you see in JS, Kotlin, Rust, Scala, C#, etc. It has a modern type system with type inference, string templating, Option type, tuples and simpler closures. It's pretty nice actually.
SwiftUI is just a way of writing UIs using Swift and a reactive paradigm. It looks and feels like React but instead of the embedded HTML of React it only uses plain Swift. The previous recommended method used XML (in XIB files) and needed special tooling (Interface Builder), which was nice but not perfect. Also doing git merges in the XML files are much harder.
> For Swift it's a modern language that doesn't need to have backward compatibility with C that Objective-C had.
That doesn't seem accurate. Interoperability with C and Objective-C was a fundamental design requirement of Swift. C interoperability is not particularly pleasant in Swift, but it's certainly there. It has to be there.
Apple has been creating some easier to use Swift wrappers around old UNIX C API. For example, their Network framework, and the just-announced Swift System.
I think GP meant syntactic compatibility. Objective-C is an embedding within C and C++ code and has to be (mostly) compatible with them for the free mingling of each language. Swift is freed from that need, but that doesn't mean it isn't designed for interop (calling between each language).
In any case, I'm not fully convinced which language has the advantage and which the disadvantage in this case. You still have to call C API in Swift, and it's rather painful.
I would also say that Swift by design is very much constrained, you might say held back, by the needs of Cocoa compatibility. For example, Swift takes features that are mere conventions in Objective-C, such as initializer patterns (which can be ignored when they're inconvenient), and makes them into built-in language requirements. This becomes very awkward at times.
Perhaps the worst, "ugliest" feature of Swift is optionals. Why would you even add optionals to a new language if not for the necessity of Cocoa/ObjC compatibility. The language would be so much nicer without them.
Optionals doesn't exist because of ObjC compatibility. They are a hallmark feature in functional languages like Haskell and Scala, and in other modern languages like Rust and Kotlin. Even C++17 introduced std::optional.
And I completely disagree, they are one of the best features of any language and are able to remove a whole class of very annoying bugs.
And sorry, but I didn't understand the part about the initializer pattern... are you talking about constructor overloading? This has also been a traditional feature of OOP languages for decades.
> Optionals doesn't exist because of ObjC compatibility.
The problem is that every Objective-C type is essentially an optional, so any Swift code using Cocoa frameworks, based on Objective-C, is a deluge of optionals. Your entire code base is constantly dealing with them. It's a mess.
> I didn't understand the part about the initializer pattern... are you talking about constructor overloading?
I'm pretty familiar with the Objective-C internals, and Swift optionals are not there because of Objective-C, as there are multiple ways of having compatibility between the two languages (but none as safe as having Optionals).
Like I said, Optionals are an extremely popular feature in most modern languages, and Swift would be very criticized if it had not included it.
Ok, you are talking about constructor overloading, which is a pretty common and uncontroversial feature present in pretty much every OOP language made in the last 30-40 years.
> Ok, you are talking about constructor overloading
No, I'm not. I'm talking about, for example, "Classes and structures must set all of their stored properties to an appropriate initial value by the time an instance of that class or structure is created." Which is not the case in Objective-C.
Also the concept of a "designated initializer", which is again simply a convention in ObjC.
EDIT:
To be clear, I'm not trying to make statements about the history of programming languages, or about general programming concepts. I'm trying to say that the very specific way that Swift implements general programming concepts (which may vary greatly in different languages) was obviously inspired and constrained by backward compatibility with Cocoa and Objective-C. If you were to design a new programming language from scratch, without those backward compatibility requirements, you most likely wouldn't implement things exactly the way Swift does. It would be strange if you did. Swift is very much constrained by backward compatibility, and very much non-ideal as a result.
If you read that entire long initializer document from top to bottom, it's clear that this is all specifically based on Objective-C patterns — as it needs to be for Cocoa compatibility — regardless of whether there are historical antecedents of the general concept.
Sorry but let's maybe agree to disagree? You seem to be pointing to Swift features that are very different from ObjC (as you said yourself), but are very close to other similar multi-paradigm languages. You asked "Why would you even add optionals to a new language if not for the necessity of Cocoa/ObjC compatibility" and I'm answering that other languages have it. It's not that Swift turned ObjC conventions into requirements: it's that in ObjC they were mere conventions, in almost every other new language similar to Swift they are already requirements.
Sure, Swift has ObjC baggage, but those two specific features would be present in any multiparadigm language launched in the same period. Check out Scala, Kotlin and even C#, for example, and you'll see lots of similarities. Swift is going exacly where other languages are converging to.
In fact, the inspiration for the ad-hoc initializer pattern in ObjC you're mentioning probably came from other contemporary languages... maybe C++ or Smalltalk. Optionals in Swift have nothing to do with ObjC: in Swift they come from functional programming tradition, nullability in ObjC is a virtue of being a superset of C. The fact they work together is a virtue of compatibility, but those two Swift features were not specifically designed to serve ObjC.
I think the truth is somewhere in the middle–Swift was not created in a vacuum, of course, but it does have to take Objective-C into account and thus we have the concepts of designated and convenience initializers, or implicitly unwrapped optionals. However, if you look at them more closely it's pretty clear they exist to bridge Objective-C to Swift concepts–fully initialize your objects before you use them, or annotate your code for nullability, which is where Swift wants you do go.
> Perhaps the worst, "ugliest" feature of Swift is optionals. Why would you even add optionals to a new language if not for the necessity of Cocoa/ObjC compatibility. The language would be so much nicer without them.
Conceptually, the ability to represent the lack of a value is quite a common requirement. Swift has specific language syntax and compiler data structuring around the Optional type, but it is just a swift enumeration with an associated value at its core.
IUO (implicitly unwrapped optional) is mostly a compatibility feature however, for languages which were designed around the idea of nullable pointers like objc and C. UIKit and AppKit, for example, assume views have properties which can be nil before the view loads and non-nil afterward. IUO allows you to rely on this convention rather than have to safe or force-unwrap every property for use.
There was an interesting discussion about reactive UIs yesterday (https://news.ycombinator.com/item?id=24599560). Sounds like Swift have it fairly sorted. Is there anything like React Native for Swift rendering to html? A sort of “Swift Non Native”?
I think SwiftUI is still settling, so I expect to see more movement in this are in the short-term future. But I don't see Apple releasing an HTML-emitting-SwiftUI by themselves.
> The previous method used XML (in XIB files) and needed special tooling (Interface Builder)
This isn't really true. Interface Builder was an alternative to writing UI code, but programmatic UI is still allowed and is well-supported. Many developers prefer it to IB.
> It has a very expressive syntax and uses modern idioms you see in JS, Kotlin, Rust, Scala, C#, etc.
Yeah and that's exactly what I would call a disadvantage. I prefer dumb programming languages like Java, C++11 without the auto keyword, and Objective-C. They're much easier to understand because there are fewer ways to achieve the same thing and they don't require keeping as much context in your head while reading the code.
IRL example with Swift: I wanted to fix a logic bug in someone else's code and spent an hour trying to get a field from an object. I could see it in the debugger but every way to get it I could think of produced an uninformative syntax error. There was nothing to google because there were no keywords around it, even. Then the author of the code in question came online and explained that it's an "enum with associated value" (wtf?!) and you have to use this `if let` or `case let` abomination to extract the fields into local variables.
Another IRL example with Swift is that this whole immutability-by-default thing was just driving me insane because I'm too used to the fact that I can overwrite function/method arguments but Swift won't ever let me.
Another problem of these languages is that you have to actually learn them, and there's too much to learn. And good luck understanding anything without that encyclopedic knowledge.
To me, it's all just abstractions that get in the way more than they help, tbh.
C++ has most of its complexity in the standard library, and that is easy enough to look up if you don't understand something. It's relatively barebones as far as the syntax goes. Swift, on the other hand, has way too many features a.k.a. syntactic sugar in the language itself.
Uh, no? Just parsing the language is undecidable, there's problems with "vexing parses" and strange overloads, there's like twenty seven ways to initialize things, there's new syntax every release to do something that has already existed in the language…
Sorry, but in a previous comment you mentioned that you prefer "dumb programming languages like [...] C++11 without the auto keyword". However "too much to learn" and needing "encyclopedic knowledge" is exactly how most people with different levels of familiarity with the language would describe C++ (with or without auto).
To me it sounds as if your problem is purely lack of familiarity with modern languages, rather than them lacking some specific property that your usual languages have.
I mean you can say that for any language. If someone has to learn C or Java, you still need to learn how those languages work, build domain expertise and so on.
Swift is a very nice general purpose language and I’ve been writing code decades in almost most mainstream languages. I much prefer writing Swift code, in face some of my back end projects have been written in 100% swift, this allowed me to reuse models and APIs with the iOS and MacOS counterparts.
How have you written backend code in Swift, were you able to use it in places you would normally use e.g. C++?
I'm asking because I like Obj-C/Swift, and am wondering if it's possible through some clang/LLVM magic to be able to code Obj-C/Swift in environments that expect C or C++, for example like in Qt. Like, could I have a traditionally C++ app (Qt app) but have most of my code be in another LLVM-compatible language.
> Like, could I have a traditionally C++ app (Qt app) but have most of my code be in another LLVM-compatible language
It is possible! I mix Swift and Rust in my day job. I use the C ABI to interface between the two. The Swift layer is very thin and pretty much just a bridge between Rust and Cocoa/UIKit/Metal, but there's nothing stopping you from doing the opposite.
If you're going to bridge Swift with Qt, the sanest way is to use Objective-C++ to wrap Qt calls and call it from Swift.
However keep in mind that the Swift experience in other Operating Systems might not be as good as in Macs. That's why I went with Rust for this project. But things might have changed in the meantime!
I did some searching to see people's experiences substituting other languages for C++ through LLVM, and didn't find much other than samples of translated calls.
Given that there would be a big benefit to this (not having to learn a new language, less manual memory management), are there good reasons this isn't way more common?
If you use the C ABI you can just link a bunch of object files together.
Rust people are doing it a lot for graphics/game stuff, and there's lots of production MacOS apps mixing ObjC/Swift (because they're transitioning), or consuming C/C++. Of course in this case it's mostly Xcode doing the magic, but behind the scenes it's just calling clang.
How worse? How would you even begin to understand this line without an IDE?
auto something = someObject->someFunction();
// and then 10 lines of various operations on "something"
// also imagine that someObject is also auto and returned from somewhere
I've had to deal with code like this. It wasn't pleasant, even with an IDE. There are very few cases where type inference is good and doesn't make your code an unreadable mess.
Step number one is not naming your things "something". I for one am glad I can use "auto" instead of "std::vector<int>::size_type" in my code–in this case the actual type this couldn't matter less; all you need to know is that it's some kind of unsigned integer. The same is true for Swift, where it's generally a lot more useful to know you have some type of sequence rather than "I have a LazyMapSequence<LazySequence<[Int]>.Elements, String>". Plus, C++ is one of those languages where certain things have types that you cannot write down, so auto is required to use certain parts of the language!
Type inference is the usual tradeoff for being able to write statically-typed code efficiently. I think it's better than
MyType something = new MyType(...);
like in old-school Java, is it not? IDEs and LSP-enabled editors are pretty much the standard nowadays, although I agree that it's nice to be able to read code without one.
Also, that code you mentioned seems like bad style with the auto keyword; the type should be obvious.
> IDEs and LSP-enabled editors are pretty much the standard nowadays
There are many places where you see code without IDE-like features. One that comes to mind is everything related to git. Web-based git tools like github, git GUIs, command-line git, you name it.
Besides, it's nice to be able to read and understand the code without needing to download the entire project and importing it into an IDE just for that.
My idea is that you almost always write in an IDE, but not necessarily read in one. Thus, for verbose languages, the IDE would generate most of that example for you (I know for sure IDEA does this exact completion) but it will be perfectly understandable in a git diff.
> There are many places where you see code without IDE-like features. One that comes to mind is everything related to git. Web-based git tools like github, git GUIs, command-line git, you name it.
Both git and web-based git+ services like Github are frequently used through deep editor/IDE integrations, so, no, I disagree that “everything related to git” is a good example here.
I do. The problem is, others don't necessarily do. A good-in-my-world language makes it take more effort to write unreadable code than readable.
Everyone seems to only be judging languages by the code you write yourself, totally oblivious to the fact that reading and understanding someone else's code, including in projects you don't influence, is also an important part of being a software developer.
For Swift it's a modern language that doesn't need to have backward compatibility with C that Objective-C had. It has a very expressive syntax and uses modern idioms you see in JS, Kotlin, Rust, Scala, C#, etc. It has a modern type system with type inference, string templating, Option type, tuples and simpler closures. It's pretty nice actually.
SwiftUI is just a way of writing UIs using Swift and a reactive paradigm. It looks and feels like React but instead of the embedded HTML of React it only uses plain Swift. The previous recommended method used XML (in XIB files) and needed special tooling (Interface Builder), which was nice but not perfect. Also doing git merges in the XML files are much harder.