[ratww]

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.

[_qulr]

> 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.

[Jtsummers]

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).

[ratww]

No, it is accurate. Notice I didn't say interoperability, I said backwards compatibility.

Objective-C is a superset of C, so any valid C code is also valid Objective-C code, including all the pitfalls and footguns.

This is similar to the relationship between C and C++, however C++ isn't strictly a superset of C.

[_qulr]

> I said backwards compatibility

This phrase isn't entirely clear.

> Objective-C is a superset of C

This phrase is clearer.

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.

[_qulr]

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.

[ratww]

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.

[_qulr]

> 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 talking about this: https://docs.swift.org/swift-book/LanguageGuide/Initializati...

[dwaite]

> 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.

[chrisbrandow]

Every object in Objc is already optional. Swift merely formalizes it so that it's easy to reason about.

[aidos]

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”?

[extra88]

SwiftWebUI [0], "write SwiftUI Views which display in a web browser." HN discussion [1] from last year of SwiftWebUI.

[0] https://www.alwaysrightinstitute.com/swiftwebui/

[1] https://news.ycombinator.com/item?id=20320820

[ratww]

I remember seeing this project here in HN (or was it Reddit?), but it's more of a proof of concept:

https://github.com/zhuowei/marina

The code itself is pretty easy to understand: https://github.com/zhuowei/marina/blob/master/marina_html.sw...

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.

[machello13]

> 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.

[pavlov]

Mix & match was always the best way, IMO.

Use IB to build small components and highest-level layouts.

Use code for everything in between, as well as individual views.

[ratww]

That's true, thanks. I amended my answer to say "previous recommended method".

[grishka]

> 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.

[julius_set]

That’s not a problem with the language that’s just you not knowing how to use it, two very different things.

Associated values with enums are very powerful features of the language.

[grishka]

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.

[uryga]

> good luck understanding [Swift] without encyclopedic knowledge.

> I prefer C++11

C++ is like the prototypical example for "languages that require encyclopedic knowledge" so this seems like a weird comparison

[grishka]

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.

[saagarjha]

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…

[ratww]

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.

[julius_set]

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.

[hajimemash]

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.

[ratww]

> 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!

[julius_set]

There’s a very vibrant backend community for Swift, Vapor is growing and used in production for a lot of companies.

https://vapor.codes

[saagarjha]

> C++11 without the auto keyword

That's still a massive language; the part you removed makes it basically be C++03 but even worse :/

[grishka]

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.

[saagarjha]

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!

[snazz]

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.

Do you have a better solution in mind?

[grishka]

> 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.

[dragonwriter]

> 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.

[pjmlp]

I use all such tools mostly from the comfort of my IDE.

[vips7L]

You just need to use auto properly.

auto/var/val etc are best used when you can tell the type from the rvalue.

    var m = new HashMap<String, List<Pair<X, Y>>>();

    var m: Map<String, List<Pair<X, Y>>> = obj->someFunc();

All of the examples you have should be caught in linting or code review.

[grishka]

> You just don't know how to use auto properly.

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.

[saagarjha]

Believe me, we've read a lot of code written by other people. There's a point where you read

  HashMap<Integer, ArrayList<String>> mapping = new HashMap<Integer, ArrayList<String>>();

enough times that you start to get tired of reading stuttering code, too.

[vips7L]

By your logic we shouldn't program because someone else MIGHT mess it up.

Should we remove every feature that someone might misuse?