This is pretty great stuff, I knew about the raw interop features but had no idea what API Notes offered. Quite cool.

I can't help but feel that Swift will ultimately be the "slow and steady wins the race" safe language of the future. Swift steadily working "first" on both tooling and cohabitability with existing ecosystems is a huge boon for adoption. It understands what an ABI is! If I were doing a greenfield cross platform application I think Swift would be the first thing I reach for now.

The qualms I have with Swift are mostly some of the more recent complex language features that can make Swift code much harder to understand and read, as well as the brainpower required to use Swift concurrency. That and some performance concerns, though many of those seem like they may be solvable with optimizations in LLVM.

▲

pharaohgeek an hour ago | parent | next [-]

I absolutely love Swift. I find it to be such an elegant language. I've done a few macOS/iOS apps with it over the years, but have really come to love it on the server. There are a couple of areas I feel could use some improvement with respect to cross-platform support, but overall the use of frameworks like Vapor have been a breeze to work with.

More support for language interoperability like this will just enhance the cross-platform experience. The Java ecosystem is what makes it so attractive to enterprises. Swift being able to easily take advantage of open-source C/C++ libraries will help with the migration.

▲

zozbot234 an hour ago | parent | prev | next [-]

> It understands what an ABI is!

Rust understands the C ABI, and that's plenty good enough for now. It's hard to guarantee safety anyway when you're linking to what's effectively outside code (not part of the same build) because we don't really have a fully typed equivalent for raw assembly or binary output (unlike your "safe" VM's, where the bytecode always undergoes sanity checks prior to execution) - hence why the raw C ABI often suffices in a practical sense.

▲

aaronbrethorst 9 hours ago | parent | prev | next [-]

It feels like the language designers have never met a feature or paradigm they didn't love and agree to include :-\

▲

arcticbull 6 hours ago | parent [-]

Yeah, Swift started out fairly clear and cohesive and now it's just a katamari of every language feature ever made by anyone plus a whole bunch of home-grown features too. I'm always mixed on this because in isolation the feature is neat and I like it, but the totality of Swift is becoming as overwhelming and inconsistent as C++.

Now some C functions which are indistinguishable from free Swift functions get named parameters, and you can switch on some enumerations from C, and some C objects are ref counted but other ones still need you to do it. It's going to be quite something to keep track of which library is which since there's no way to know apriori.

▲

mpweiher 4 hours ago | parent [-]

While it has gotten even worse, thinking it was clear and cohesive in the beginning is rose tinted nostalgia.

	▲	budgefrankly 6 minutes ago \| parent [-]
		Yeah, Swift looks like someone started trying to port a C# syntax onto an esoteric object-orientated C-dialect (similar to Vala and GObject) then at the last moment noticed Rust 1.0 had been released, tried to patch on some Rust features, and hit release before they were done. It's quite deceptive. Rust seems initially hard to learn, but it's a small language, so you arrive at competency faster than you might think. Swift seems initially easy to learn, but is a broad language with lots of edge-cases, so you're never quite as competent as you think you are, or need to be

▲

mpweiher 4 hours ago | parent | prev | next [-]

> ... some of the more recent complex language features

This isn't recent. The approach that Swift took had this path locked in from the start, the (d)evolution towards ever more spiraling complexity was inevitable from the initial choices.

And this is not 20/20 hindsight, a lot of people, including yours truly, were saying that fron the very start. As an example, take initialization:

2014:

https://blog.metaobject.com/2014/06/remove-features-for-grea...

The swift book has 16 rules and 14 pages just on object initialization. Chris replied in the comments: "the complexity is necessary for <feature we want> and thus simplicity must give way". My reply: "the <feature you want> is incompatible with simplicity and thus must give way".

2020:

called it!

https://blog.metaobject.com/2020/04/swift-initialization-swi...

---

Or the syntax:

https://blog.metaobject.com/2020/06/the-curious-case-of-swif...

→ Swift included all of Smalltalk's keyword message syntax as a special case of a special case of the method call syntax.

---

Rob Rix:

“Swift is a crescendo of special cases stopping just short of the general; the result is complexity in the semantics, complexity in the behaviour (i.e. bugs), and complexity in use (i.e. workarounds).”

https://www.quora.com/Which-features-overcomplicate-Swift-Wh...

▲

pinnochio 2 hours ago | parent [-]

I was excited and optimistic about transitioning to Swift in the Swift 3 days. By Swift 5 I was pining for Objective-C.

One of the arguments for switching to Swift was that it would be easier for new programmers. Now I think it's more of a barrier than Obj-C ever was.

▲

mpweiher 2 hours ago | parent [-]

I don't pine. I use.

Although more and more I am shifting to Objective-Smalltalk: https://objective.st

	▲	pinnochio 2 hours ago \| parent [-]
		That's neat. Unfortunately, in my place of work, going back to Obj-C isn't an option.

▲

pjmlp 5 hours ago | parent | prev | next [-]

That is surely the target for Apple platforms, whatever happens outside is more a nice to have kind of thing.

As proven by the track record of all languages that want to be simple, created as kind of anti-trends, they always tend to evolve into complexity as their userbase grows, as it turns out other programming language didn't got complex just for fun.

Then since they were initially created as kind of anti-complexity movement, the added on features always have warts due to not wanting to break compatibility, and are only half way there.

C23 versus PL/I, ALGOL variants, Scheme R7RS (full report) vs Lisp evolution, Java 26 vs Modula-3/Eiffel, Go 1.26 versus everyone, ...

▲

peterspath 11 hours ago | parent | prev | next [-]

This is a good write up about Swift Concurrency: https://fuckingapproachableswiftconcurrency.com/en/

	▲	aeontech 8 hours ago \| parent [-]
		This is awesome, and deserves its own post!

▲

worldsavior 2 hours ago | parent | prev | next [-]

All the benefits you mentioned are trivial, as in- many languages have them already.

▲

andeee23 8 hours ago | parent | prev [-]

i’m not sure about the work on tooling

just a few weeks ago i was trying to work on a swift project in neovim and found the whole langserver experience pretty bad

and it’s way worse when working on swif ui apps, but i guess that’s more of an apple wanting you to use xcode thing.

i wish there was better tooling, i like the language, but i just switched to nim for my side project

	▲	pharaohgeek an hour ago \| parent \| next [-]
		I do miss JetBrains' AppCode and their support for Swift in CLion. I wish they would open-source those plugins so that they can continue to be used in modern versions of CLion.
	▲	pentamassiv 7 hours ago \| parent \| prev [-]
		I find the Swift tooling very lacking. There's no way to lint dead code, there no way to auto format the files exactly as Xcode would do it and tell the linter those rules so that it doesn't lint your auto formatted code. Xcode project files are impossible to edit except with Xcode and Xcode often has issues and I need to manually empty the build folder. These are just some of the issues I remember