Hacker News Reader

Comment by thrwawy74 | Hacker News Reader

Is there anything genuinely innovative about Swift or is it just another "cross-platform scripting language" that I'll only see on 1 platform?

The only reason I learned Powershell is because I have to admin for Windows. At least Powershell is interesting for its pipeline and object handling. I get not one spark of joy from Swift, and the comments I see are "at least we're not writing C anymore". Stockholm syndrome.

Sorry this is so negative, but I can't get excited about $NewLanguage unless I know it offers real benefit. I have drunk the Rust koolaid, and for very good reasons. What am I missing in Swift?

View on HN

It’s pleasant to use, that’s the main thing about Swift.

A very Apple thing to be honest, so just like most of the Apple products it’s very good in few thing and good enough in others and probably nothing is completely new.

The overall experience is pleasant. Apple is building just as pleasant tooling around it, Swift Playgrounds is amazing for example. Newbies can learn coding by doing some exercises disguised as games but that’s not what’s amazing, what’s amazing is that you can make full apps with all the libraries and Swift packages and SwiftUI. Apple did good job hiding the boilerplate away, did good job removing the decision making about the project file structure and created an intuitive interface where you can just code without worrying about anything else.

In 2020s, Swift is probably the only language with tooling that lets you just code your ideas and deploy without dealing with anything else. Like creating a Word document and writing your thoughts down straightforward.

I don’t know if submitting from Swift Playgrounds to the AppStore has been released but the beta I was trying last month had this functionality. From idea to market, start to finish integration.

> Is there anything genuinely innovative about Swift

Apple's thing is innovation - taking technology that exists but is clunky and making it accessible.

Swift is intended to be a more accessible alternative to Objective-C. It is memory safe (reference counted like Objective-C's ARC but built into the language) and type-safe, and has modern features such as named parameters, generics, duck typing, closures, multiple values, inline arrays and dictionaries, etc.. It's intended for writing user apps, but is also suitable for writing system frameworks. It also has some (possibly overly) clever syntactic sugar that has enabled SwiftUI's pseudo-declarative API.

Regarding memory safety we have: Swift (mostly reference counting), Rust (mostly compile-time checks), Java (mostly garbage collection), and C++ (smart pointers or manual/unsafe.)

A good point, and it bears emphasising the subtle but important distinction between innovation and invention. Taking an invented thing and honing it into something that seems obvious in its effortlessness is often especially difficult. But often impossible to see that difficulty in hindsight.

Swift doesn't really have to be "genuinely innovative" – it's a modern, ergonomic language which is pretty easy to pick up and and use, has decent performance and a solid type system combined along with the familiarly of a C-like imperative language. It has pretty obvious usability and expressiveness benefits relative to Objective C while being designed for effective interoperability with a massive existing set of codebases.

It actually feels quite a lot like Rust to write it. They're obviously designed for two different use-cases – Apple platform development versus safe systems programming, but they share a lot of similarities in other ways.

Innovation isn't the same as invention. Apple didn't invent the MP3 player or the smartphone, but they certainly innovated with the iPod and the iPhone, which combined technologies into useful and accessible products.

Swift might not change the industry, but it makes life easier for anyone who wants to develop on an Apple platform but finds Objective-C unwieldy. Also it provides a path for Apple to migrate its platforms to memory-safe languages, which can reduce bugs and security vulnerabilities.

Swift isn't a scripting language, it's a memory safe compiled language suitable for systems programming in the Obj/C++/Rust/Go category. But unlike Rust, it's a bit more automatic and you don't feel compelled to micro-optimize every memory allocation and RC operation.

…also, the multithreading design is better and more performant.

…also, it has a stable ABI that supports shared libraries, which no other compiled language except C ever manages to get right.

Powershell and Swift are so far apart in design as well as intended use cases that I'm not sure why you'd even want to compare them. It's like comparing Zsh to C#.

Because, as they said, they're "cross platform" but really only exist in one place.

That's not the case for PowerShell, though. Take a look at the list of supported platforms here:

https://learn.microsoft.com/en-us/powershell/scripting/insta...

I suppose their point is that much as you can install and run PowerShell outside Windows, you can run Swift outside Apple's ecosystem. People just don't do either of those things very often.

With Swift, the support for other platforms is mostly token right now. As in, you can write code in it, but e.g. their sample app for Windows uses Win32 API directly - for Windows developers, that would be already considered outdated 20 years ago.

OTOH PowerShell actually works largely the same across all supported platforms, so it's equally useful on all of them in absolute terms. Now, outside of Windows, we've had decent shells for much longer, so its relative utility is indeed lower on those platforms (although not non-zero, if you find the notion of an object-oriented shell with a rich standard library useful). One particular use case where it comes in handy is when you have to script some automation for both Windows and Linux; e.g. cross-platform builds or CI. So mostly shared code, but in a few places you might need to do "if LINUX then ...".

If I recall Swift has a very interesting ABI for generics.

1. https://faultlore.com/blah/swift-abi/

I appreciated this comment. This is something I hadn't seen :-)

For one, Swift is not a scripting language.

Swift certainly can be a scripting language.

  #!/usr/bin/env swift
  print("hello, world!")

Of course, but so can C++ and Java: https://stackoverflow.com/a/29709521

Implicit main in Swift means you don't need "public static void main..." or other boilerplate.

No reason why Java and C++ couldn't do something similar though.

Top level programming is actually a little too surprising in Swift. For instance, you can access variables before they're declared - so you're not just implicitly inside a main function.

Right, but unlike C++ and Java, the scriptability of Swift was designed by spec. It's not a hack or convolution.

Java being used as a script is now also built in (since Java 11 in 2018): https://nipafx.dev/scripting-java-shebang/

That's kind of one of Swift's things - it is designed to be as accessible as a scripting language but scalable to full applications and system software.

Ideally it gives you some of the convenience and accessibility of a language like Python, combined with runtime efficiency of a language like Objective-C.

print("hello, world") is a cute example since it's a valid program in both Python and Swift.

(Though I still haven't forgiven Python for removing the print statement, which dates back to BASIC antiquity.)

I've never done any Mac or iOS development and even I can see this is a strange question. I don't know why you think it's a scripting language, or how it compares in anyway to powershell?

"It's not Objective-C" is pretty much the only advantage it has. You're not missing anything, it's basically a superfluous language that only exists in its current form because Objective C needed replacing and Apple would never adopt a language they didn't have effective control over. Language-wise, I see zero benefit over Rust, possibly Go (I'm not familiar enough to comment) or even JVM-less Kotlin.

But hey, we're stuck with it now so no use complaining.

Static and concise NPE protection via optional syntax, and the guard construct, both make defensive programming much easier in Swift. Tons of other little things.

Memory management is easier than it is in Rust. It has generics which makes it more flexible than Go [was until its generics were recently introduced]. Kotlin native wasn’t announced until three years after Swift.

I don’t think it’s as simple or one-sided as you’re making it out to be.

I don't consider this:

guard let foo = bar else { ... }

to be any better than this:

if bar().is_none() { ... }

For the record, I find the guard keyword totally unnecessary and I still have NFI what's wrong with this in Swift:

if bar == nil { ... }

I also totally disagree about memory management being "easier" (at least with C-interop), because I think Swift's handling of UnsafePointer/UnsafeRawPointer/UnsafeBufferPointer/mutable variants/withMemoryRebound/etc isn't particularly easy to follow at all.

To be clear though: I don't think Swift is a bad language. It's perfectly adequate. But it's the fact that Apple decided to force Yet Another Programming Language down our throats that, in my opinion, offers no real advantage over many of the other choices available at the time.

"We're Apple and you will only use a language that we control" was, IMO, the driving force behind Swift, not the inherent superiority of the language itself.

The guard keyword behaves like a non-crashing assertion that promotes code readability with a compile-time required early exit. “Don’t bother executing past this point if these conditions are not met” is fundamentally different from “if these conditions are met create a new local scope and then continue executing”.

> Swift's handling of UnsafePointer/UnsafeRawPointer/UnsafeBufferPointer/mutable variants/withMemoryRebound/etc isn't particularly easy to follow at all.

And that’s why we have inout instead? Unsafe* is useful if you need to bit pack frozen structs into a ring buffer and increment the r/w offsets by the stride, maybe? I think inout can handle that as well.

In addition to what replies have already pointed out to you, guard places the assigned new variable in the same scope below. This encourages early exits and avoids pyramids of doom.

swift isnt new, but yeah i agree its not as exciting to think about as rust or Go. I think i prefer it over some of the oddities from TS, but certainly over js.

Swift can do everything Go does but better now that it has async/await because it has real types and a real unsafe API. Calling C from Go is horrendous.

good to know, i could use some convincing

Reply on news.ycombinator.com