Hacker News

> the server ecosystem was starting to come to life, even supported by IBM.

I was in college at the time and doing some odd freelance jobs to make some money. Unbeknownst to my clients I was writing their website backends in swift, using build packs on heroku to get them hosted.

It was a fun time for me and I love swift but I will admit last year I went ahead and rewrote an entire one of those sites in good ol typescript. I love swift but anything outside of the Apple ecosystem with it just seems like it hasn’t hit critical mass yet.

> Swift has remained largely an Apple ecosystem

Even today, with the fancy Swift 6.3, the experience of using Swift for anything other than apps for Apple platforms is very painful. There is also the question of trust - I don't think anyone would voluntarily introduce Apple "The Gatekeeper" in parts of their stack unless they're forced to do it.

Python 3 barely managed to dethrone Python.

True. Google was even thinking of switching TensorFlow from Python to Swift.

https://github.com/tensorflow/swift

Python's interactive interpreter makes it pretty useful as a shell, for iterative development, and crucially useful in a Jupyter notebook. I've also found CircuitPython's interpreter to be bonkers useful in prototyping embedded projects. (This, on top of the nice datascience, ML, and NN libraries).

Swift just wasn't doing the same things. And even if it did, Swift would compete with other languages that were understood as "a better Python", like Julia. Even then, Swift only came to Linux in 2016, Windows in 2020, and FreeBSD less than a year ago with WWDC 2025.

I think it doesn't help that the mid 2010s saw a burst of Cool and New languages announced or go mainstream. Go, Julia, Rust, TypeScript, Solidity, etc. along with Swift. I think most of us only have space to pick up one or two of these cool-and-new languages every few years.

> could plug into the C/C++ ecosystem. Hence all the numeric stuff people were doing in Python powered by C++ libraries could've been done with Swift.

In 2015-2017 you could interop with C, C++ support wasn't added until very recently.

I do agree with you though and I am not sure what the exact reasoning is, but Swift is definitely an Apple ecosystem language despite the random efforts to gain traction elsewhere.

> around 2015-17 - Swift could have easily dethroned Python.

Why could it?

> it was simple enough - very fast - could plug into the C/C++ ecosystem. Hence all the numeric stuff people were doing in Python powered by C++ libraries could've been done with Swift.

Half a dozen languages fit this description.

> the server ecosystem was starting to come to life, even supported by IBM.

No, not at all. Kitura, Vapor (a fitting name) were just a toys that no serious player ever touched.

Maybe Chris Lattner leaving and creating Mojo also didn’t help in that regard.

Swift for TensorFlow was a cool idea in that time …

The thing what people don't get with C++'s complexity is that complexity is unavoidable.

It is also there in Ada, C#, Java, Python, Common Lisp,....

Even if the languages started tiny, complexity eventually grows on them.

C23 + compiler extensions is quite far from where K&R C was.

Scheme R7 is quite far from where Scheme started.

Go's warts are directly related to ignoring history of growing pains from other ecosystems.

> Swift could have easily dethroned Python.

Just IMO, but... no. To me a "could have easily" requires n-1 things to have happened, and 1 thing not happening. Like, we "could have easily" had a nuclear exchange with the USSR, were it not for the ONE Russian guy who decided to wait for more evidence. https://en.wikipedia.org/wiki/1983_Soviet_nuclear_false_alar...

But even in '15-'17, there were too many people doing too many things with Python (the big shift to data orientation started in the mid/late 90's which paved the way to ML and massive python usage) by then.

The 'n' was large, and not nearly of the 'n' things were in Swift's favor then.

Again, IMO.

That's my read too.

Swift was feeling pretty exciting around ~v3. It was small and easy to learn, felt modern, and had solid interop with ObjC/C++.

...but then absolutely exploded in complexity. New features and syntax thrown in make it feel like C++. 10 ways of doing the same thing. I wish they'd kept the language simple and lean, and wrapped additional complexity as optional packages. It just feels like such a small amount of what the Swift language does actually needs to be part of the language.

>"around 2015-17 - Swift could have easily dethroned Python."

NumPy, SciPy, Pandas, and Pytorch are what drove the mass adoption of Python over the last few years. No language feature could touch those libraries. I now know how the C++/Java people felt when JS started taking over. It's a nightmare to watch a joke language (literally; Python being named for Monty Python) become the default simply because of platform limitations.

> Haven't used it since v3 though.

Since 5.10 it's been worth picking back up if you're on MacOS.

Eh, I don't think Swift would ever have dethroned Python. What pain point would it practically solve? I don't use Python often but I don't hear folks complaining about it much.

I do, though, think Swift had/has(?) a chance to dethrone Rust in the non-garbage collected space. Rust is incredibly powerful but sometimes you don't really need that complexity, you just need something that can compile cross-platform and maintain great performance. Before now I've written Rust projects that heavily use Rc<> just so I don't have to spend forever thinking about lifetimes, when I do that I think "I wish I could just use Swift for this" sometimes.

You're right, though, that Swift remains Apple's language and they don't have a lot of interest in non-Apple uses of it (e.g. Swift SDK for Android was only released late last year). They're much happier to bend the language in weird ways to create things like SwiftUI.

> Swift could have easily dethroned Python

No way something that compiles as slowly as Swift dethrones Python.

Edit: Plus Swift goes directly against the Zen of Python

> Explicit is better than implicit.

> Namespaces are one honking great idea -- let's do more of those!

coupled with shitty LSP support (even to this day) makes code even harder to understand than when you `import *` in Python.

Edit 2: To expand a little on how shitty the LSP support is for those who don't work with Swift: any trivial iOS or macOS project that builds fine in Xcode can have a bunch of SourceKit-LSP (the official Swift LSP) errors because it fails to resolve frameworks/libraries. The only sane way to work with Swift in VS Code or derivatives I've found is to turn off SourceKit diagnostics altogether and only keep swiftc diagnostics. And I have the swift-lsp plugin in Claude Code, there's a routine baseline of SourceKit errors ignored. So you have symbols without explicit namespaces, and the LSP simply can't resolve lots of them, so no lookup for you. Good luck.

Dethroned Python? The Apple language, seriously. Where is numpy for swift?

It's been a long time since I came across Nim. I thought it was really interesting about 12 years ago. What made you land on Nim instead of any of the more obvious alternatives?

LISP like McCarthy LISP?

How so? I can indeed target every layer of the software stack using Swift, today.

E.g. ClearSurgery[0] is written fully in Swift, including the real-time components running on the Linux boxes.

[0] https://clearsurgery.vision

I tried Swift a few months ago in a project that made use of a bunch of bigger dependencies and I was instantly shocked by the compilation times. It's quite unimaginable to me using Swift for everyday work because of that. Especially when coming from the fast compile times of Go. But it's really unfortunate because I really enjoyed writing Swift because it feels like a very well made language. But iterating on some code and trying to get quick feedback is pure pain.

C++ interop got attention because it helps Apple absorb low-level codebases that already moved past pure C. Exporting Swift to plain C mostly means more DIY FFI spaghetti.

Once enums, ownership rules, and nullability cross that boundary, the generated header stops looking like a neat bridge and starts looking like one more place for ABI bugs to hide. Closures make it weirder fast, because now your error handling and calling conventions can drift just enough to produce the kind of bug that wastes a whole afernoon.

They had it earlier, as an underscored attribute.

You already had ObjC export so it was arguably low priority given the crossover

it's been there for a while as an experimental feature. I used it in a project

Anything similar for Windows and Linux?

For Windows there's a 5 year old blog post: https://www.swift.org/blog/swift-on-windows/

For Linux there's a guide for GNOME: https://www.swift.org/blog/adwaita-swift/

It would be really nice if instead we could just do one style of development and then ship a set of libraries as used to work for OpenSTEP (which was why it had "OPEN" in the name).

That is going to be used... less than Swift for the servers

Both are apart of the toolchain now, no external dependencies required: `swift format` and `swift format lint` to access them

skip.dev helps

There are still challenges with basics like compression, which tends to involve trawling Github for the least dubious toy project. Even Apple's Compression framework is missing important algorithms like ZSTD.

Another problem is the Apache Software Foundation don't seem to have any Swift maintainers, which means there really aren't any good pure Swift libraries for Arrow or Parquet.

There are some really good open-source libraries from Apple like Swift Collections or Swift Binary Parsing.

As of very recently, the entire stdlib (i.e. "Foundation") is open source and available on all platforms Swift targets. For a while, the Linux builds had a much smaller/limited version of Foundation, but it's fully supported now.

A good source of available packages is the Swift Package Index. You can search here packages compatible with Linux[0].

[0] https://swiftpackageindex.com/search?query=platform%3Alinux

It is a markdown thing. It removes the "copy" button from the code block when the markdown is rendered. Search for "nocopy" on this page.

https://docs.instruqt.com/tracks/challenges/using-markdown-e...

If you look at the code above, the temperature and weather are selected independently randomly. That alone is not indicative of AI-generated code; a human could write something similar for demo/learning purposes.

>I heard about how beautiful it is

This used to be the case around Swift 4, but since then they've added so many features and keywords to the language. Now the simplicity and elegance is gone.

Also it seems like there was a marked change in the culture of Swift. It somehow attracted a lot of the "ackchyually" crowd which resulted in a lot of massively complicated features. I liked to occasionally browse the evolution docs and they got more and more complex over time.

I find rust much noisier, especially at its basics where you write “for item in items” instead of using iter()

What are you using for rust-swift interop?

I remember jumping into Swift from Obj-C in 2014 and using words like "beautiful" and "expressive" to describe syntax, and saying things like "you can tell what language someone is coming from by how they code in Swift". Now it's grown as it has - sometimes feels like season 4 of Lost. Makes me feel old too.

I was excited about it when it first came out, but haven't heard anything about it since.

Given that Swift has one of the slowest compilation times, this is a valid criticism.

I still have hope Swift will break free like C# has. I hope one day something like Vapor or Kitura takes off.

but still a good update