Rendered at 13:02:31 GMT+0000 (Coordinated Universal Time) with Cloudflare Workers.
dzonga 2 days ago [-]
good to see incredible stuff being shipped in Swift. Haven't used it since v3 though.
around 2015-17 - Swift could have easily dethroned Python.
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.
the server ecosystem was starting to come to life, even supported by IBM.
I think the letdown was on the Apple side - they didn't bring in the community fast enough whether on marketing, or messaging - unfortunately Swift has remained largely an Apple ecosystem thing - with complexity now chasing C++.
willio58 2 days ago [-]
> 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.
isodev 2 days ago [-]
> 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.
mathverse 2 days ago [-]
You can use swift on the server but what for? You have a gigantic ecosystems in languages X,Y,Z.
Even Apple does not use Swift on the server (AFAIK) so why would you?
jshier 2 days ago [-]
What, of course Apple uses Swift on the server, that's the only reason they're investing in any of this. Many of the foundational Swift on the server libraries were written at Apple and later opened, like SwiftNIO.
You could have easily fact-checked before forming an opinion, but at least the buffoon down there agreeing with you is worse
vips7L 2 days ago [-]
Man you gotta touch some grass instead of just insulting people.
unconscionable 2 days ago [-]
Smoking grass can also help with this
jen20 1 days ago [-]
I personally worked on several server-side Swift projects at Apple.
isodev 2 days ago [-]
> Even Apple does not use Swift
Exactly true - they've created all these "working groups" of open source / volunteers to care for Android / Server / Wasm / ... all while being constraint "as an Apple product". Of course the end result is crappy
mathverse 2 days ago [-]
Yea there is no incentive. Why use Swift on the server or in k8s when you have gazillion other languages that are performant and have the ecosystems.
vmsp 2 days ago [-]
True. Google was even thinking of switching TensorFlow from Python to Swift.
That’s really because Chris Lattner was at Google Brain at the time. Don’t think it ever took off in meaningful ways
mark_l_watson 2 days ago [-]
I was enthusiastic about early TensorFlow in Swift efforts, sorry when the effort ended. My interest then flowed into early Mojo development for a while.
I wrote an eBook on Swift several ago but rarely update that book anymore. Count me as one of the many developers who for a while thought Swift would take over the world. At least Swift is a fun language to use, and now with LLM coding tools writing macOS/iOS/iPadOS apps is fairly easy.
c-fe 2 days ago [-]
funnily enough, I talked recently to someone working on the swift compiler (not an Apple employee) to make Swift functions differentiable. So its not all dead yet
I'm sorry, that's absolutely bullshit. In fact, I wish we had left everyone who complained behind—the python community would have been happier and healthier for it. Absolute crybabies who wanted to be catered to without caring for how intractable the problems with python2 were—e.g. dealing with unicode was a royal pain in the ass, and the bytes/string divide completely fixed it. IMO, it was the best-executed breaking change I've ever witnessed in a language.
In comparison, e.g. Scala 2 -> Scala 3 was an absolute nightmare—it just didn't have the same vocal wailing from maintainers in the community (or, I suppose, a fraction of Python's popularity to begin with).
crest 2 days ago [-]
Being to aggressive in breaking stuff gets you a shitshow like Node.js or Ruby. Long-term source code compatibility is a very useful feature for open source and a sign of a mature eco system. Feel free to add stuff, but once it's part of a stable release it has to be maintained long after a "better" way to do it comes along.
throwaway27448 2 days ago [-]
Javascript would heavily benefit from breaking changes. The reason why it still sucks ass to use today is because this won't ever happen.
I can't speak for node.js specifically but who gives a shit
> Long-term source code compatibility is a very useful feature for open source
Sure, until you need affordable maintainers. Maintainability must be balanced with patience for bad software. Cf the insane maintenance cost of perl scripts
jwlake 2 days ago [-]
nodejs itself doesn't have very many breakages; i have plenty of code that is unchanged from 0.12 to 24. npm is a whole other kettle of fish but I don't think you can blame the core project for the sins of everyone that publishes to the package manager. Python2 -> Python3 on the other hand had a lot of breakage in "standard" code.
lynndotpy 2 days ago [-]
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.
wiseowise 2 days ago [-]
> 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.
hocuspocus 2 days ago [-]
After that, and IBM losing interest, Apple did hire a few competent people (including contributors to Netty and Akka) to build the Swift Server Workgroup.
But I don't know why I'd pick Swift on the server when Rust is better in almost every dimension, with a thriving and more community-driven ecosystem.
mathverse 2 days ago [-]
I think it's not about that but about dogfooding Swift on the server. Apple uses Go, Java etc for a lot of its server components and refused to invest in hiring people that would extend the ecosystem for server Swift.
Thats the problem.
hocuspocus 2 days ago [-]
It certainly doesn't help, but among big tech, Apple is not the only company where teams are siloed and independent. Microsoft has people writing Java or Go instead of C# too.
I assume the server side usage is not zero, but not enough to reach a critical mass, you're probably right there.
tarentel 2 days ago [-]
> 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.
rasmus1610 2 days ago [-]
Maybe Chris Lattner leaving and creating Mojo also didn’t help in that regard.
Swift for TensorFlow was a cool idea in that time …
troupo 2 days ago [-]
Lattner probably left because Apple didn't give the team any breathing room to properly implement the language. It was "we must have this feature yesterday". A lot of Swift is the equivalent of Javascrip's "we have 10 days to implement and ship it":
Swift has turned into a gigantic super complicated bag of special cases, special syntax, special stuff...
We had a ton of users, it had a ton of iternal technical debt... the whole team was behind, and instead of fixing the core, what the team did is they started adding all these special cases.
--- end quote ---
groundzeros2015 2 days ago [-]
For this language to become default at Apple they had to be doing a massive amount of internal promotion - in other words they knew where it was going.
And then if that's the case, how were they not ready to solve the many problems that a big organization would run into? And all the schedule constraints that come with it?
mpweiher 2 days ago [-]
> Swift has turned into a gigantic super complicated bag of special cases, special syntax, special stuff...
That's true, but only partly true. It already was a gigantic super complicated bag of special cases right from the start.
Rob Rix noted the following 10 years ago:
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).
Apple's new Swift language has taken a page from the C++ and Java playbooks and made initialization a special case. Well, lots of special cases actually. The Swift book has 30 pages on initialization, and they aren't just illustration and explanation, they are dense with rules and special cases
Of course, that doesn't mean that it didn't get worse. It got lot worse. For example (me again, 2020):
I was really surprised to learn that Swift recently adopted Smalltalk keyword syntax ... Of course, Swift wouldn't be Swift if this weren't a special case of a special case, specifically the case of multiple trailing closures, which is a special case of trailing closures, which are weird and special-casey enough by themselves.
A prediction I made was that these rules, despite or more likely because of their complexity, would not be sufficient. And that turned out to be correct, as predicted, people turned to workarounds, just like they did with C++ and Java constructors.
So it is true that it is now bad and that it has gotten worse. It's just not the case that it was ever simple to start with. And the further explosion of complexity was not some accidental thing that happened to what was otherwise a good beginning. That very explosion was already pretty much predetermined in the language as it existed from inception and in the values that were visible.
From my exchange with Chris regarding initializers:
"Chris Lattner said...
Marcel, I totally agree with your simplicity goal, but this isn't practical unless you are willing to sacrifice non-default initializable types (e.g. non-nullable pointers) or memory safety."
Part of my response:
"Let me turn it around: Chris, I totally agree with your goal of initializable types, but it is just not practical unless you are willing to sacrifice simplicity, parsimony and power (and ignore the fact that it doesn't actually work)."
Simplicity is not the easy option. Simplicity is hard. Swift took the easy route.
[...] when you first attack a problem it seems really simple because you don't understand it. Then when you start to really understand it, you come up with these very complicated solutions because it's really hairy. Most people stop there. But a few people keep burning the midnight oil and finally understand the underlying principles of the problem and come up with an elegantly simple solution for it. But very few people go the distance to get there.
-- Steve Jobs (borrowed and adapted from Heinelein)
That is why I wish Apple to abandon Swift and continue to use Objective-C instead.
Also a reason why Craig needs to go.
troupo 1 days ago [-]
This is brilliant. Thank you!
hirvi74 2 days ago [-]
To be fair, I think such a fate in inevitable for most languages after many years of changes and development.
msie 2 days ago [-]
[dead]
pjmlp 2 days ago [-]
It remains to be seen how much Mojo has learnt from that effort.
NVidia, AMD and Intel now have doubled now into giving Python GPU JITs, and Julia, the same capabilities as their CUDA, ROCm, and SYSCL offerings with C++.
With Julia and Python having their 1.0 long behind them.
iamcalledrob 2 days ago [-]
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.
72deluxe 2 days ago [-]
I get this feeling with C#. I have been here since its release. I looked at Swift and then they moved very quickly at the beginning, so the book I had to teach me was out of date moments after it was printed. With all the complexity being thrown in, I stuck with C++ because at least it was only 1 language I had to keep track of (barely)!
CharlieDigital 2 days ago [-]
C# is the other direction, IMO.
I've been using C# since the first release in 2003/4 timeline?
Aside from a few high profile language features like LINQ, generics, `async/await`, the syntax has grown, but the key additions have made the language simpler to use and more terse. Tuples and destructuring for example. Spread operators for collections. Switch expressions and pattern matching. These are mostly syntactic affordances.
You don't have to use any of them; you can write C# exactly as you wrote it in 2003...if you want to. But I'm not sure why one would forgo the improved terseness of modern C#.
Next big language addition will be discriminated unions and even that is really "opt-in" if you want to use it.
hirvi74 2 days ago [-]
> Next big language addition will be discriminated unions and even that is really "opt-in" if you want to use it.
I was excited for DU until I saw the most recent implementation reveal.
The C# impl is still early and I think what will end up happening is that a lot of the boilerplate will end up being owned by source generators in the long term. C# team has a habit of "make it work, make it better". Whatever v1 gets released is some base capability that v2+ will end up making more terse. I'm happy and OK with that; I'd rather have ugly unions than no unions (yes, I already use OneOf)
pjmlp 2 days ago [-]
Ah Source Generators, after all these years still badly documented, when searching you most likely will find the original implemenation meanwhile deprecated, have poor tooling with string concatenation, and only have a few great blog posts from .NET MVPs to rely on.
CharlieDigital 2 days ago [-]
:shrug: we're using them very effectively and there are plenty of resources at this point.
Very useful for reducing boilerplate and we can do some interesting things with it. One use case: we generate strongly typed "LLM command" classes from prompt strings.
pjmlp 2 days ago [-]
There are plenty of resources, outside Microsoft Learn that is, and the content is mostly understandable by those of us that have either watched conference talks, or podcasts on the matter.
Now having someone diving today into incremental code generators, with the best practices not to slow down Visual Studio during editing, that is a different matter.
They are naturally useful, as a user, as a provider, Microsoft could certainly improve the experience.
willtemperley 2 days ago [-]
Which keywords would you get rid of and why? You don't have to use all of them!
fauigerzigerk 2 days ago [-]
I would remove result builders and all other uses of @attributes that change the semantics of the code (e.g property wrappers).
I would remove the distinction between value types and reference types at the type level. This has caused so many bugs in my code. This distinction should be made where the types are used not where they are defined.
I would remove everything related to concurrency from the language itself. The idea to let code execute on random threads without any explicit hint at the call site is ridiculous. It's far too complicated and error prone, which is why Swift designers had to radically change the defaults between Swift 6.0 and 6.2 and it's still a mess.
I would remove properties that are really functions (and of course property wrappers). I want to see at the call site whether I'm calling a function or accessing a variable.
I would probably remove async/await as well, but this is a broader debate beyond Swift.
And yes you absolutely do have to know and use all features that a language has, especially if it's a corporate language where features are introduced in order to support platform APIs.
fingerlocks 2 days ago [-]
I agree with you about result builders, silly feature that only exists for SwiftUI.
But a lot of what you said, except for the concurrency and property wrapper stuff, largely exists for Obj-C interop. The generated interface is more readable, and swift structs act like const C structs. It’s nice.
quietbritishjim 2 days ago [-]
I'm not a Swift user, but I can tell you from C++ experience that this logic doesn't mitigate a complex programming language.
* If you're in a team (or reading code in a third-party repo) then you need to know whatever features are used in that code, even if they're not in "your" subset of the language.
* Different codebases using different subsets of the language can feel quite different, which is annoying even if you know all the features used in them.
* Even if you're writing code entirely on your own, you still end up needing to learn about more language features than you need to for your code in order that you can make an informed decision about what goes in "your" subset.
cloogshicer 2 days ago [-]
But you have to know all of them to read other people's code.
To answer your question: I would immediately get rid of guard.
Also, I think the complexity and interplay of structs, classes, enums, protocols and now actors is staggering.
willtemperley 2 days ago [-]
I'm surprised, guard is really useful, especially when unwrapping optionals. It's terse, explicit and encourages defensive programming.
internal should definitely go though.
cosmic_cheese 2 days ago [-]
The absence of guard in Kotlin is one of those things that regularly trips me up when bouncing between it and Swift. Rather than Swift losing guard I’d prefer if Kotlin gained it.
iamcalledrob 2 days ago [-]
I think the ?: operator ends up being a decent alternative, e.g.
// Swift
guard let foo = maybeFoo else {
print("missing foo")
return false
}
// Kotlin
val foo = maybeFoo ?: run {
print("missing foo")
return false
}
Unless there's a use case for guard I'm not thinking of
cosmic_cheese 1 days ago [-]
It’s a decent alternative, but to someone not familiar with the language what’s going on isn’t as clear.
That number is unfairly exaggerated. The list includes ~40 internal keywords used only by language developers, plus dozens of tokens that would be called preprocessor directives, attributes, or annotations in other languages (e.g. `canImport` as in `#if canImport(...) #endif`; `available` and `deprecated` as in `@available(*, deprecated) func`).
That file is the compiler's list of reserved keywords, so some of them may not have been added to docs, or they're experimental/internal/...
I'm not 100% sure but I think the swift doc you linked is missing at least a dozen keywords so the truth probably lies in the middle
dematz 2 days ago [-]
Ah makes sense, personally I wouldn't consider reserved but unused words as keywords in the sense that you don't need to know them to read the language (even though they're keywords in some other technical sense). I was curious because I just tried counting number of keywords by language and it seemed surprisingly ambiguous/subjective/up to the language to say what's a "keyword" vs some type of core module. So my attempt (https://correctarity.com/keywords) probably has mistakes...
rudedogg 1 days ago [-]
> You don't have to use all of them!
You sure pay for the language complexity in high compile times though. Swift is slow, like really slow. I’ve been with it since like v1.2, and its been getting progressively worse for a while IMO. Complex language features (Lets do a borrow checker! Lets do embedded!) and half of the shit isn’t being used internally as far as I can tell
Focusing on the keywords rather than the macros, I think the rest of them have legitimate use cases, though they're often misused, especially fileprivate.
merlindru 1 days ago [-]
this is gonna sound ranty, but it's straight from the heart:
i think most of them are pointless. not every feature needs to be a new keyword. stuff could be expressed within the language. if the language is so inflexible in that regard that it's impossible to express stuff without a keyword, use macros for gods sake.
why is there a need to have a "convenience func" declaration?
why is "didSet" a keyword?
what about "actor"? most other languages don't have nearly as many keywords and manage to express the idea of actors just fine!
eptcyka 2 days ago [-]
You can take this approach in personal projects - with teams you need to decide on this and then on-board people into your use of the language. This does not work.
willtemperley 2 days ago [-]
Yes exactly, it’s easy to blame a language when really it’s a team problem.
msie 2 days ago [-]
I felt that too many smart people were getting involved in the evolution of the language. There should have been a benevolent dictator to say NO.
michaelcampbell 2 days ago [-]
> 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.
zem 2 days ago [-]
I had a similar journey with F# - the language looked excellent and I really wanted to make it one of my go-to languages, but every time I tried to use it I found bits that would only work on windows (especially around desktop apps). I finally just gave up, though I hear it has gotten better at being truly cross-platform these days.
davidwritesbugs 2 days ago [-]
Same and not to mention reames of weird .Net errors that were never fixed and hard to understand or speculate about
oefrha 2 days ago [-]
> 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.
vovavili 2 days ago [-]
>No way something that compiles as slowly as Swift dethrones Python.
This must have pushed Chris Lattner towards making Mojo both interpreted and compiled at the same time.
2 days ago [-]
commandersaki 2 days ago [-]
Plus Swift goes directly against the Zen of Python
The Zen of Python is how we got crap like argparse where arguments are placed in the namespace instead of a dict.
coldtea 2 days ago [-]
I wouldn't change that in any way. I'd might make it an Arguments class, but I wound't make what parser returns merely a dict.
commandersaki 2 days ago [-]
Yeah, so what happens when you have an option with a '-' in it that isn't valid as a variable name (I know what happens). It's just stupid.
coldtea 2 days ago [-]
The same thing you'd do yoursef if you wanted to assign it to a namesake local variable even if it was in a dict to begin with: you'd make the dash an underscore.
commandersaki 2 days ago [-]
It would be extremely unlikely that you would replicate the name as a local variable if it was in a dict, but regardless a dict doesn't have that limitation. The namespace thing is atrocious and bad design -- no straightforward way to iterate over them, merging/updating them is awful, collides with keyword methods (keys, items, etc.), and so on; thankfully more modern argument parsing libraries didn't repeat this mistake. It's just a shame this ended up in the standard library, but then Python standard library has never really been any good, e.g. logging and urllib1234567.
coldtea 2 days ago [-]
>It would be extremely unlikely that you would replicate the name as a local variable if it was in a dict
If you had some feature flag args, you'd keep accessing them via the dict? Highly unlikely...
bossyTeacher 2 days ago [-]
> Explicit is better than implicit.
That's funny. To me magic is implicit by definition and Python strikes me as a very magical language compared to something like Java that is way more explicit.
robmccoll 2 days ago [-]
Until you start using frameworks like Spring and then everything is so painfully magic that no one knows how the program actually runs.
wiseowise 2 days ago [-]
Magical language how? And you should see what reflection based Java monstrosities do in the background.
pjmlp 2 days ago [-]
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.
embedding-shape 2 days ago [-]
> Even if the languages started tiny, complexity eventually grows on them.
And then of course the case that proves the opposite, Clojure. Sure, new ideas appear, but core language is more or less unchanged since introduced, rock solid and decades old projects still run just fine, although usually a bit faster.
pjmlp 2 days ago [-]
That is because Clojure is done, there is hardly anything being done other than probably what matters to NuBank and Datomic mostly.
Also its market share adoption kind of shows it.
zdragnar 2 days ago [-]
That's a pretty far cry from "complexity is unavoidable". Reading that to me implies that the complexity is inherent in programming language design, whereas this follow-up argument seems to say that complexity is the result of tacking on new features.
The latter is a bit tautological, since the size of the language grammar is itself a measure of complexity.
pjmlp 2 days ago [-]
I think they even haven't adopted newer JVM features, it is a hosted language designed to depend on its host, plus it is a Lisp.
The complexity would be to grow like Common Lisp, instead it is up to Clojure folks to write Java, C#, JavaScript code, therein lies the complexity.
iLemming 2 days ago [-]
> I think they even haven't adopted newer JVM features
You don't know what you're talking about. Not only Clojure steadily adopting newer JVM features (for when that makes sense) - java streams, functional interfaces, qualified method values, interactive lib loading, JDK21 virtual threads, etc., Clojure constantly explores beyond the JVM - e.g., Jank targets LLVM and has C++ interop.
Pick some hardcore JVM topics and try searching what Clojurists think about them - GC, profiling, concurrency, etc. There's tons of interesting, deeply involved things constantly being hacked together by incredibly knowledgeable folks. You're casually name-dropping "complexity" maybe without even realizing that it's a community that includes people who have written production experience reports on Shenandoah GC, built profiling tools that work around safepoint bias, and given conference talks on tri-color marking algorithms. Dealing with complexity is their bread-n-butter. Challenging Clojurists to debate about "complexity" is like dropping "the brain has neurons" around a group of neurosurgeons. They'd quietly say nothing, so you can "win your argumentation", but they'll just... know.
pjmlp 1 days ago [-]
I was talking about the JVM bytecodes for dynamic languages.
Also I remember watching a recent talk, where virtual threads was still "being considered".
Having to write portable code that has to take into account the host differences, and difference in execution semantics, and still delivery the same outcome, is also complexity that keeps neurons busy.
iLemming 20 hours ago [-]
Let's see.
> JVM bytecodes for dynamic languages
You're talkiing about invokedynamic - bytecode instruction added in Java 7, specifically to make dynamic language dispatch efficient, right? Explained simply: JVM was designed for static types - method calls resolved at compile time. In dynamic langs you don't know the type of something until runtime had to hack around, typically by boxing everything and doing manual type checks. This was slow and awkward. JRuby/Groovy adopted it eagerly. Clojure's dispatch model though is different. Most calls are either: direct interop (already statically typed), or calls through a Var (is a reference to a function value, not a dynamic method lookup). The Var indirection is a different shape of problem that invokedynamic doesn't solve as cleanly. It's not that it's useless, just that the fit isn't as natural.
> virtual threads was still "being considered"
That is an outdated info. Clojure 1.12.0 shipped two years ago with virtual thread support, but the integration with core.async's thread pool model was not there (so you were not completely incorrect). However, core.async later reimplemented go blocks using virtual threads when available. The improvements are still underway https://clojure.org/news/2025/10/01/async_virtual_threads
> take into account the host differences
Okay, this one is genuinely not that straightforward. The #? reader conditional in .cljc files is a clean, minimal mechanism. I don't really know any other language that can target completely different platforms from a single namespace as cleanly - even in Nodejs you can't in practice do it as nicely. Kotlin Multiplatform is probably the closest competitor - but its `expect/actual` mechanism requires separate source sets, separate files, and considerably more boilerplate. You're not writing in the same namespace; you're wiring together parallel declarations. Scala.js and GHCJS are essentially separate compilation targets with thinner sharing stories. But yes, it still can get complicated - different hosts have meaningfully different concurrency and I/O models, so it's rather "shared logic, host-specific edges" rather than "write once run anywhere". I still think Clojure handles this all far more elegantly than alternatives.
So pragmatically speaking, you're pointing at complexity at the implementation/runtime layer, while Clojure's complexity reduction happens at a different layer entirely - data model, immutability by default, simpler concurrency reasoning, REPL workflow. Those layers mostly don't interfere with each other. You mentioned real concerns at the platform engineering level, but they in practice don't touch what Clojure is actually trying to simplify. Someone writing Clojure code never experiences invokedynamic problems one way or the other.
honr 2 days ago [-]
The current market share shows how far you can go with just being a better Java.
If (or when? I haven't checked recently) a decent and well-thought-out LLVM backend emerges for it, ideally with some new underlying complexity seeping through, the market share might expand overnight.
And as for C++, while some complexity is certainly unavoidable, a rigorous complexity control is desperately needed. Ideally, the same way Bell Labs folks did when they initially conceived Go from Algol68 and C and similar (before or after joining Google; I couldn't tell), and Rich Hickey did when he initially designed Clojure. Some people are managing the complexity using style guides and clang-tidy checks. Which is great in that doing so doesn't need lengthy language committee decisions. But that approach hasn't been enough to make code _sufficiently_ safe; every now and then an enterprising engineer or team finds a way to abuse a feature in a way that produces unsafe or unpredictable results. Rust is a bit better and solves a few of the common problems, but sadly the list of potential issues (of using Rust in a codebase at scale; Engineers' faults, not Rust's) is long and growing. My verdict is we need both complex and simple LLVM languages, ideally co-designed to have no interop problems by design, while allowing expressing some logic in the simple parts and some logic in the complex parts. Or better, a 3 tier design would be nearly perfect: expressive config language, glue and research language, and core building blocks language. I think a clojure-style language can be designed to achieve all three.
pjmlp 2 days ago [-]
All good, except that going forward the new languages to be designed are going to be specifications and formal verification for agents.
I think the way of classical programming languages is behind us, unless AI implodes and we are back to programming without it.
embedding-shape 2 days ago [-]
> That is because Clojure is done
Yes, that's one approach to avoiding ever growing complexity, maybe the other languages should try it sometime ;)
With that said, everything around Clojure keeps improving and getting better. While the language doesn't have static types, clojure.spec offers something that is even better than static typing (imo), and doesn't even require any changes to the core language. Something else other mainstream languages could learn too.
pjmlp 2 days ago [-]
Is Typed.Clojure finally stable and sound?
In theory we only need parentheses, prefix operators and a REPL, but mainstream never went down that route.
Anyway the complexity then ends up being custom DSLs and macros.
iLemming 2 days ago [-]
> Is Typed.Clojure finally stable and sound?
It feels like as if you're operating with a few keywords you picked up without fully understanding the meaning of them. Typed Clojure was a PhD research project. Experimental. CircleCI experimented with it at one point but the friction was high enough that it never became a standard practice - the annotation burden was significant. You'd be writing a lot of type scaffolding for a language whose entire value proposition includes getting things done with less ceremony. Clojure's power comes heavily from its data orientation. Maps, sequences, heterogeneous data flowing through pipelines. Traditional type systems are deeply uncomfortable with that style. You end up either constraining how you write Clojure, or writing very complicated types to describe simple data flows. Types are there, Clojure does have types, and OMG, non-clojure coders have no idea how expressive they can be. There's just no static checking and that's for good reasons.
Does Typed Clojure solve complexity? - No, not really. Complexity is about incidental complexity from complecting things - and a type system doesn't untangle that (according to Rich Hickey). You can have beautifully typed spaghetti.
I'm not against static typing, and I have used languages with really nice type systems. But honestly, whenever this point pops on forums and people be like "meh, Clojure is not typed" - I immediately know - they probably have only shallow experience working with Clojure code.
pjmlp 1 days ago [-]
No, I happen to know that some things that people throw around haven't delivered their initial expectations.
Just as you confirmed with your lengthy reply, by following up to my question.
iLemming 20 hours ago [-]
What do you know about "initial expectations" of Typed Clojure specifically? I for one have worked with Ambrose on the same team, he's a good friend of mine and we discussed his dissertation at least a few times. I don't argue about static vs. dynamic typing without specific context, because it always matters. I have intimate understanding for why Clojure is how it is. I'm not defending it blindly - just like any other PL it has its own warts, but you're picking the wrong ones to criticize its face value.
iLemming 2 days ago [-]
> That is because Clojure is done
First of all: Clojure is not "done". Latest commits were 3 months ago - https://github.com/clojure/clojure. Secondly, the language intentionally not 'all batteries-included' PL. The core is meant to be a stable, minimal substrate. Most action happens in libraries and tools - core.async, spec & malli, babashka, nbb, etc. Check the activity in Clojurians Slack. It's a small but unusually vibrant community, every single day there are news and announcements - updates, etc. It is done-ness in the good sense - like a well-designed tool that doesn't need to keep changing its handle.
> market share adoption kind of shows it
NuBank being the world's largest digital bank and running Clojure at scale is not "adoption"? Besides, there's Apple, Cisco, and tons of smaller companies running on it.
> there is hardly anything being done
They are making a documentary https://www.youtube.com/watch?v=JJEyffSdBsk
Please don't say: "well, there are documentaries about dinosaurs" or something.
I've been using Clojure for over ten years - in different teams, companies, industries. For my own projects and professionally. I've heard about it "dying" back then. I keep hearing about it dying every year and I promise you - nothing like that (even remotely) happening. Yes, the hype is gone (was it ever real?), but the language, community, library ecosystem, tooling - all of that only getting better.
There's no "killing" of Lisp. As long as programming languages remain relevant, there will always be some Lisp-dialect around. It probably never will become mainstream, yet it never completely disappears. There's no killing of Lisp, because it would be like killing "graph theory" or something. Graph theory doesn't need a Fortune 500 company funding it to remain true. Similarly, a small community keeping a Lisp dialect alive is all it takes - and there will always be people drawn to the clarity you get when you strip a language down to its lambda-calculus bones and see the whole thing fit in your head at once.
Rich Hickey has made this point himself - Clojure isn't trying to be the most popular language, it's trying to be correct about certain things. And correctness doesn't go out of fashion.
omcnoe 1 days ago [-]
The issue with C++ complexity is that the standard development model is dysfunctional.
They aren’t able to bring concepts like “a file” into the standard because one standards body member maintains a compiler in some baroque ancient environment without the concept of a fs. Too much is forced to implement at the library level instead of in the compiler, and end up feeling half baked for real users (modules, coroutines etc).
pjmlp 1 days ago [-]
Just like any other language under ISO, like Ada, Fortran, COBOL and guess what, C the FOSS beloved language.
pjmlp 1 days ago [-]
Python has been slowly growing since 1990's.
Python powered by C++ libraries comes from HPC folks, places like CERN and Fermilab, they would hardly touched Swift instead.
ramesh31 2 days ago [-]
>"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.
Terretta 2 days ago [-]
> Haven't used it since v3 though.
Since 5.10 it's been worth picking back up if you're on MacOS.
afavour 2 days ago [-]
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.
fainpul 2 days ago [-]
> just need something that can compile cross-platform and maintain great performance.
I think Go has already taken that part of the cake.
afavour 2 days ago [-]
Go is garbage collected, though. Rust and Swift still occupy a niche Go doesn't.
mathverse 2 days ago [-]
ARC is a form of garbage collection. Swift does not fare better than Go usually.
WD-42 2 days ago [-]
Dethroned Python? The Apple language, seriously. Where is numpy for swift?
0x3f 2 days ago [-]
> Swift is designed to be the language you reach for at every layer of the software stack.
It's a nice lang for sure, but this will never be true with the way things are. Such wasted opportunity by Apple.
frizlab 2 days ago [-]
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.
I _can_ do the same with Rust, doesn't mean it's "the language I reach for" for making e.g. a website. Because the tooling, ergonomics, hireability factor, etc. are still very harshly against it.
Same with Swift, but I'd call that more of a wasted opportunity because Apple, unlike Rust Foundation, has a mountain of money to make it happen, and yet they don't seem to care.
frizlab 2 days ago [-]
> They don't seem to care.
I don’t believe that’s true. Things are moving constantly, and in the right direction. Then again it would help if you cited particular grievances, because being a regular (cross-platform/cross-target) Swift user I am not sure what you are talking about…
I did not choose ClearSurgery’s example randomly. I was at a conference recently where the CTO was here, and he explicitly told us they were moving fast thanks to the Swift ecosystem. (I am not working there personally, nor am I affiliated.)
merlindru 2 days ago [-]
they seem to be adding more and more keywords
if they really want me to use this lang for everything, they'd have to 1. massively improve compilation speed, 2. get the ecosystem going (what's the correct way to spin up an http server like with express?) and 3. get rid of roughly 150 of the 200 keywords there are
especially w.r.t. the last one, of course everyone frets at huge breaking changes like this, so it won't happen, so people won't use it
zffr 2 days ago [-]
> 3. get rid of roughly 150 of the 200 keywords there are
I don't understand this point. Could you explain?
The new keywords enable new language features (ex: async/await, any, actor), and these features are opt-in. If you don't want to use them, you don't have to.
What are they keywords you think should be removed?
hbn 2 days ago [-]
> these features are opt-in. If you don't want to use them, you don't have to.
Using a language is more than just writing it with a pre-established knowledge of what subset of features you think is worth the tradeoffs. More keywords/features means when you try to figure out how to do something new, there may be 15 different ways and you need to analyze and figure out which is the best one for this scenario, which ones are nonstarters, etc.
That's was more or less the whole design goal of Go. It was made by C++ programmers who were fed up with how many features were in the language, so they kept the feature set limited. Even the formatting is decided by the language. You may not agree with every decision, but what matters is decisions were made and they're standardized, so everyone is on the same page. You can read anyone else's code, and you know exactly what's going on.
merlindru 1 days ago [-]
besides it being almost impossible to understand what "the right way of doing stuff" is with Swift (or any bloated language), i absolutely _do_ have to use the keywords.
reading someone else's code is part of working with the language (as is understanding LLM output nowadays). i can't just make others not use the keywords i don't know/beed/like. especially if working within teams, or using OSS.
zffr 20 hours ago [-]
Fair point, I had not considered needing to read and understand code you didn't write yourself.
Especially in a corporate setting, not understanding a keyword you see in a PR could lead to bad code being checked in.
hu3 2 days ago [-]
> I don’t believe that’s true. Things are moving constantly, and in the right direction.
Hah! I'll use that argument if I ever get PIP'd.
No but seriously, constantly moving doesn't mean fast enough. Swift took took long to have cross-platform support.
And it is still uberslow to compile. To the point of language servers giving up on analyzing it and timeout.
ModernMech 2 days ago [-]
Not just uber slow to compile, because as a Rust dev I could take that. But it rejects correct programs without telling you why! The compiler will just time out and ask you to refactor so it has a better shot. I understand that kind of pathological behavior is present in many compilers but I hit it way too often in Swift on seemingly benign code.
frizlab 1 days ago [-]
Did that happen recently (the compiler just bailing out)?
Because they got much better at that, and it’s been a long while since that happened to me. Like “I don’t even remember when was the last time it happened” long.
ModernMech 20 hours ago [-]
The last time I used Swift was 4 months ago. It was recent enough that I'm still salty about it! :P
zarzavat 2 days ago [-]
I don't know why anyone would want to use Apple tools if they are not developing for Apple platforms. Apple barely maintains compatibility for their own platforms, using Swift on a non-Apple platform is setting yourself up for doubule pain.
myHNAccount123 2 days ago [-]
> Apple barely maintains compatibility for their own platforms...
You're commenting on a post about an update... that they apparently don't do? What?
groundzeros2015 2 days ago [-]
Why are you interpreting this comment as "never receives updates"? It takes great effort to maintain API compatibility, some things aren't improved or are implicitly deprecated.
myHNAccount123 2 days ago [-]
2/10
frizlab 2 days ago [-]
That was true for Swift 2, maybe a little for Swift 3, but it has not been true since a long time now…
ethin 2 days ago [-]
In a way it still is true. Swift works on Windows and Linux until it doesn't. It's taken until a couple years ago for other build systems to get swift support (which I suppose is the fault of said build system, but Swift taking so long to be cross-platform contributed to that), and even now it (still) doesn't quite work right. C interop is a mess requiring hacks to generate clang modules to actually get Swift to see them (and CMake for example provides no easy way of doing this, or last time I checked it didn't). Oh and Swift tends to take over the linker and compilation pipelines when you enable it, at least with CMake, because... Reasons? I honestly don't know why. It causes very weird errors when I integrated Swift code into my C++ project that were a pain to actually diagnose. I eventually got it working, but still, it wasn't simple or seamless.
hu3 2 days ago [-]
If cross platform support took so long, it's a major red flag.
Plus Swift is arguably too unnecessarily complex now.
And there's Rust/Zig so why use Swift for low level?
> Plus Swift is arguably too unnecessarily complex now.
I would argue the allegations of complexity against Swift are greatly exaggerated. I find the language to be very elegant and expressive in syntax, high in readability, and fairly terse. Other than that, Swift feels near identical to every other OoP language I have used.
michaelcampbell 2 days ago [-]
That it's designed for a thing and becoming the go-to choice for that thing can be far apart indeed.
jkman 2 days ago [-]
Out of curiosity, could you point to a tech blog or something else going over clearsurgery's stack? That's really interesting
florentmorin 2 days ago [-]
It just works.
One language. Many platforms. Incredible performance.
With a simple tooling. No ugly script. Everything is naturally integrated.
wiseowise 2 days ago [-]
> No ugly script
What’s that supposed to mean?
foltik 2 days ago [-]
The typical Apple sales pitch. Forgive me for assuming it’s only surface level.
skydhash 2 days ago [-]
Isn’t that Go?
yunwal 2 days ago [-]
Go and “simple tooling” don’t really belong in the same sentence. Powerful tooling, sure, but simple?
g947o 2 days ago [-]
Would be helpful if you elaborate which part is not simple.
Coming from C++ and JavaScript, there aren't many languages that can claim to have "simpler" tooling than Go.
shepherdjerred 2 days ago [-]
The tools aren’t bad any more, but you do need a few liners to write safe code. But that’s the case for most languages
cdcarter 2 days ago [-]
I spent last week (with Opus, of course) porting the xv6-riscv teaching operating system to a bunch of different languages. Zig, Nim, LISP, and Swift.
The improvements in embedded Swift have definitely made it one of the most enjoyable/productive languages to work on the OS. I feel like I can build useful abstractions that wrap raw memory access and make the userland code feel very neat.
On the other hand, the compilation times are SO bad, that I'm really focusing on the Nim port anyway.
sspiff 2 days ago [-]
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?
cdcarter 2 days ago [-]
I was looking for something that allows easy access to direct memory, with a syntax thats a little easier to explain than C. Frankly, zig was not actually a real viable option based on that syntax requirement but I still wanted to explore it.
Nim really is clean and simple.
seanw444 2 days ago [-]
Nim is really incredible. The only things I cannot get over is the fact that it goes the inheritance route in a way I find to be hacky and fragile (no more than one level, really?) and traits are not a core feature. If Nim's primary approach was composition + Rust-style traits (that work at compiletime and runtime), I'd have a hard time wanting to use anything else.
functional_dev 2 days ago [-]
yeah, Nim is great for that... much easier to explain to others than C or Zig especially for math code
flykespice 2 days ago [-]
Yeah, for a language that claims to be a better modern alternative to C, zig verbose syntax is really an eyesore to look at compared the very same codebase written in C...
I lost immediately any interest on it
PKop 2 days ago [-]
How about Odin?
nesarkvechnep 2 days ago [-]
LISP like McCarthy LISP?
drzaiusx11 2 days ago [-]
No mention of compilation speed improvements? Very unfortunate. Compilation times slower than rust really hampers the devx of this otherwise decent language.
roflcopter69 2 days ago [-]
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.
wahnfrieden 2 days ago [-]
Tuist is necessary for substantial projects
ttflee 2 days ago [-]
> Swift 6.3 includes the first official release of the Swift SDK for Android.
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).
migueldeicaza 2 days ago [-]
Swift on Windows has been part of the official distribution for a long time:
The blog posts seems to place higher on search results --- maybe arrange to have it edited?
Which GUI toolkit(s) does that install support?
fassssst 2 days ago [-]
None, you’re on your own. The Browser Company made bindings for WinRT so you can use WinUI imperatively but it’s non trivial to set up.
myko 2 days ago [-]
I haven't shipped any Swift on Windows myself but I have a production Linux system using Swift (and C++ interop) and it works really well
gregoriol 2 days ago [-]
That is going to be used... less than Swift for the servers
iamcalledrob 2 days ago [-]
Interestingly, Kotlin has a pretty solid cross-platform story.
I'd pick it over Swift if targeting Android since it can build and run in the JVM as well as natively -- and has Swift/ObjC interop. Its also very usable on the server if you wanted to, since you can use it in place of Java and tap into the very mature JVM ecosystem. If that's what you're into.
And I have a lot more faith in JetBrains being good stewards of the language rather than Apple, who have a weird collection of priorities.
ljm 2 days ago [-]
Kotlin is practically a no-brainer when you have JVM at your finger tips, versus something like Swift which is comparatively young.
I tried to use Vapor with Swift recently and struggled to get something working because the documentation looked comprehensive, but had a lot of gaps. I ended up throwing it out because I didn't have the time to dig through the source to understand how to do something, when I could use a mature framework in any other language instead.
The promise is there but I'm just not ready to invest. My youthful days of unbounded curiosity are coming to an end and these days I just want to get something done without much faff.
well_ackshually 2 days ago [-]
Mind you, Kotlin/Native (which is what gets used when you're compiling for iOS) doesn't have access to the JVM.
However, the Kotlin community is fundamentally all about open source, whereas Apple & iOS Devs have an allergy to it. The quality and quantity is already miles above the vast majority of what's in the Swift ecosystem. https://klibs.io has all the native compatible libs. And if you're targeting a platform where the JVM is available then yeah, it's massive. Compose makes UI tolerable compared to JWT too. Even large projects like Spring are Kotlin first nowadays.
wiseowise 2 days ago [-]
JetBrains has monetary interest in promoting Kotlin beyond Android, there’s zero incentive to promote Swift as the language outside of iOS and Mac. They don’t need to capture minds of devs for them to develop for Apple devices.
victorbjorklund 2 days ago [-]
I don't know. Could be nice for those developers that prioritize iOS and now they could keep writing Swift also for Android.
Is it gonna be what you primarily use if you wanna write an Android app? Probably not.
Is it gonna displace react Native? Probably not. Is it gonna reach the levels of flutter? Maybe.
ChrisMarshallNY 2 days ago [-]
The language doesn’t really matter. The underlying SDK/framework is where the action is at.
However, I suspect that we may not be too far off, from LLMs being the true cross-platform system. You feed the same requirements, with different targets, and it generates full native apps.
p2detar 2 days ago [-]
> from LLMs being the true cross-platform system
Fully agree. I have zero Swift knowledge and currently use LLM to write a native app. I'm well aware of the SDKs and concepts in iOS development, so even if something's wrong I got intuition where to look and how to make the LLM fix it.
tonyedgecombe 2 days ago [-]
I’m not sure about that but porting libraries from one language to another seems well within their capabilities.
ChrisMarshallNY 2 days ago [-]
I don't think we're there yet, but I suspect that it's just a matter of time.
It would certainly be quite profitable. Money tends to drive progress.
wiseowise 2 days ago [-]
> Is it gonna reach the levels of flutter? Maybe.
Never. It won’t even reach Compose level, Flutter level DX is unattainable for any framework outside Flutter.
wiseowise 2 days ago [-]
This is going to be used much more than Swift for servers. Swift is a primarily client-side mobile language. It makes sense that you tap into reusing the logic.
rirze 2 days ago [-]
Just like .NET for linux... right? RIGHT?
jkman 2 days ago [-]
At least a very common .NET web app framework is often deployed on linux. Powershell for linux might be more apt lol
quangtrn 2 days ago [-]
[dead]
mikusnuz 2 days ago [-]
The noncopyable types improvements are the most underrated part of this release. Finally makes it practical to model unique ownership in Swift without fighting the compiler.
sirwhinesalot 2 days ago [-]
> Swift 6.3 introduces the @c attribute, which lets you expose Swift functions and enums to C code in your project. Annotating a function or enum with @c prompts Swift to include a corresponding declaration in the generated C header that you can include in your C/C++ files
Why did this take so long to be added? Such strange priorities. Adding an entire C++ compiler for C++ interoperability before adding... C exports. Bizarre.
hrmtst93837 2 days ago [-]
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.
saagarjha 2 days ago [-]
They had it earlier, as an underscored attribute.
dagmx 2 days ago [-]
You already had ObjC export so it was arguably low priority given the crossover
asimovDev 2 days ago [-]
it's been there for a while as an experimental feature. I used it in a project
asimovDev 2 days ago [-]
I remember building dylibs in Swift for use in C programs, had to use @cdecl annotation iirc to achieve that, which was experimental. Good to see it's finally official
w10-1 2 days ago [-]
Beyond the marketing view... here are the (incomplete) changes:
Overall 6.3 ended up mostly about integration: stdlib, c/c++ (often driven by swift-java interop needs), and builds.
SPM (swift package manager) is slowly reaching out to take over xcode build features (e.g., resources most recently), and they have been inching and hacking their way to a new swift-build engine (now experimental) and "prebuilt" modules for the compiler/IDE macro support. Things Go Wrong all the time when trying to replace parts while driving, and there's very little visibility or control over the interactions between SPM and Xcode.
Conversely to integrations, endogenous language progress seems relatively quiet because there's a lot of behind-the-scenes work extending the initial blush of lifetime controls to iterators, stdlib types, etc. (never mind parameter packs). They're in year 4+ of building out the function-coloring of concurrency and isolation domains (6.2 had an "easy" mode that caused lots of problems), so adding year 2+ dataflow coloring of lifetimes is doubly complicating.
Naturally, diverse support for exciting new features results in quite a spread in the third-party library ecosystem of support for various language features. And now with AI entrepreneurs rewriting and porting any project that can score hits and kudos, the usual open-source authorities are losing their steam.
Finally, there's the baseline platform complexity of multiple OS and devices, physical and simulator debugging support, cloud CI...
So: that makes four dimensions of complexity. As a Swift developer you'd have to be very careful to stay on a working path as things shift underneath you.
Perhaps using it in both SPM and Xcode will lead to improvements, but I'm not especially optimistic.
myHNAccount123 21 hours ago [-]
I mean... "In projects with many local Swift packages (~160 packages, ~2,100 targets), the "Compute target dependency graph" phase takes 60+ seconds"
I'm doubting this is a comparable setup for the vast majority of swift users. Is it unfortunate for people who land on this edge case - yes.
My experience shows it's fast and our iOS apps build faster than a feature parity Android app.
lijunle 2 days ago [-]
How is the toolchain? Does Swift Lint and Swift Format support the newest version. Honestly, the modern program language should have the built-in formatter and recommend lint rules. It is not just shipping a program language, it is a while ecosystem.
qn9n 2 days ago [-]
Both are apart of the toolchain now, no external dependencies required: `swift format` and `swift format lint` to access them
jshier 1 days ago [-]
SwiftLint and SwiftFormat are different tools than swift-format, which is what is included with Swift itself. swift-format is less capable than either, or similar tools from other ecosystems. Personally I use the other two. And they don't usually require updates for new language versions, and when they do, they update quickly, as they aren't part of the Swift toolchain and subject to its glacial release process.
jbverschoor 2 days ago [-]
In an effort to use swift for scripting, without the startup cost:
Whats the stdlib situation for swift in comparison to newish languages like go or rust. I know its not batteries included lke python - and doesnt have a massive dev ecosystem of helper libs seeming to be mostly tied to macOS/iOS operating system API/ABI.
willtemperley 2 days ago [-]
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.
marcprux 2 days ago [-]
> There are still challenges with basics like compression
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.
gloosx 2 days ago [-]
>nocopy for disabling copy-to-clipboard
Im curious how is this used?
OnionBlender 2 days ago [-]
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.
Okay so the module import thing is interesting and feels like 1) it should have been included on day one and 2) might have made Swift more viable for projects like Ladybug
vladde 2 days ago [-]
i worked with SwiftUI for about two years, and i think it's a really nice language. the compiler is very slow though.
but i think it's too coupled to Apple still. when i tried getting anything running on non-Apple, i had so much trouble i decided then to not even bother.
wahnfrieden 2 days ago [-]
skip.dev helps
wwalexander 2 days ago [-]
Re: module name selectors, wasn't this already possible, e.g. ModuleA.getValue()? Though I suppose this disambiguates if you also have a type called ModuleA.
jshier 2 days ago [-]
Yes, exactly. It also allows you to disambiguate overloaded function. e.g. thing.ModuleA::doThing() vs. thing.ModuleB::doThing(), which wasn't possible with the previous syntax.
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.
jwlake 2 days ago [-]
did they ever add #define? bridging constants from the build system to swift with static NSString * const kConstValue = @XSTR(CONST_VALUE); is soooo annoying.
fingerlocks 1 days ago [-]
Only integers for #defines in C-headers, enabled with a recent-ish compiler flag. Swift has a #define but it’s just an ifdef list of flags assigned to one compiler setting.
But you can bridge build setting variables using some clever xcconfig macros that combine both preprocessor systems.
pkpowell 2 days ago [-]
Anyone else think the weather in the screen shot at the top of the page is a bit off? Snow in Lisbon (apparently it snowed there once in 2006), rain in Reykjavik at -1°. AI slop?
sheept 2 days ago [-]
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.
2 days ago [-]
dbvn 2 days ago [-]
I want to like swift so bad
gigatexal 2 days ago [-]
My chances of landing at Apple increased when they launched Swift. I am too dumb to learn objective C but swift I can do.
slopinthebag 2 days ago [-]
Swift truly is one of the languages of all time. I started a mobile app with the UI built in Swift and the core in Rust. The amount of implicit and hidden behaviour, magical fields being generated on objects because of certain annotations, the massive amount of @decorators...it's too much. I'm going to have an LLM generate the SwiftUI and touch as little of it as possible.
It's also strange because before I learned Swift, I heard about how beautiful it is but I find it much noisier than Rust.
trevor-e 2 days ago [-]
>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.
qn9n 2 days ago [-]
I find rust much noisier, especially at its basics where you write “for item in items” instead of using iter()
slopinthebag 2 days ago [-]
Idk, I don't swift is objectively noisy but there is something about reading it that just hurts my brain. Stuff like
ForEach(vm.sorted(by: \.name)) { user in
row(for: user)
}
\. looks like a syntax error to me, wtf. Also, "in" instead of -> ???
.padding(.vertical, 4)
I also really dislike how you can leave off the type name, meaning you never actually know what that Type is unless you literally inspect the signature of the caller.
Wouldn't that be smth and smh is "shaking my head"?
I'm not a native English speaker, just interested in the vernacular.
TekMol 2 days ago [-]
Swift reminds me a lot of Flash back in the day.
While the Flash guys had to use a native development environment and compile their stuff, I could just edit JavaScript in a plain text file and hit reload.
20 years later, and some of the same friends now swear by Swift. And have to use a native development environment and compile their stuff. While I still prefer to just edit JavaScript in a plain text file and hit reload.
wiseowise 2 days ago [-]
Given that Swift has one of the slowest compilation times, this is a valid criticism.
around 2015-17 - Swift could have easily dethroned Python.
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.
the server ecosystem was starting to come to life, even supported by IBM.
I think the letdown was on the Apple side - they didn't bring in the community fast enough whether on marketing, or messaging - unfortunately Swift has remained largely an Apple ecosystem thing - with complexity now chasing C++.
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.
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.
Even Apple does not use Swift on the server (AFAIK) so why would you?
https://www.swift.org/blog/swift-at-apple-migrating-the-pass...
You could have easily fact-checked before forming an opinion, but at least the buffoon down there agreeing with you is worse
Exactly true - they've created all these "working groups" of open source / volunteers to care for Android / Server / Wasm / ... all while being constraint "as an Apple product". Of course the end result is crappy
https://github.com/tensorflow/swift
I wrote an eBook on Swift several ago but rarely update that book anymore. Count me as one of the many developers who for a while thought Swift would take over the world. At least Swift is a fun language to use, and now with LLM coding tools writing macOS/iOS/iPadOS apps is fairly easy.
In comparison, e.g. Scala 2 -> Scala 3 was an absolute nightmare—it just didn't have the same vocal wailing from maintainers in the community (or, I suppose, a fraction of Python's popularity to begin with).
I can't speak for node.js specifically but who gives a shit
> Long-term source code compatibility is a very useful feature for open source
Sure, until you need affordable maintainers. Maintainability must be balanced with patience for bad software. Cf the insane maintenance cost of perl scripts
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.
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.
But I don't know why I'd pick Swift on the server when Rust is better in almost every dimension, with a thriving and more community-driven ecosystem.
Thats the problem.
I assume the server side usage is not zero, but not enough to reach a critical mass, you're probably right there.
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.
Swift for TensorFlow was a cool idea in that time …
https://youtu.be/ovYbgbrQ-v8?si=tAko6n88PmpWrzvO&t=1400
--- start quote ---
Swift has turned into a gigantic super complicated bag of special cases, special syntax, special stuff...
We had a ton of users, it had a ton of iternal technical debt... the whole team was behind, and instead of fixing the core, what the team did is they started adding all these special cases.
--- end quote ---
And then if that's the case, how were they not ready to solve the many problems that a big organization would run into? And all the schedule constraints that come with it?
That's true, but only partly true. It already was a gigantic super complicated bag of special cases right from the start.
Rob Rix noted the following 10 years ago:
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...
Me, 2014:
Apple's new Swift language has taken a page from the C++ and Java playbooks and made initialization a special case. Well, lots of special cases actually. The Swift book has 30 pages on initialization, and they aren't just illustration and explanation, they are dense with rules and special cases
https://blog.metaobject.com/2014/06/remove-features-for-grea...
Of course, that doesn't mean that it didn't get worse. It got lot worse. For example (me again, 2020):
I was really surprised to learn that Swift recently adopted Smalltalk keyword syntax ... Of course, Swift wouldn't be Swift if this weren't a special case of a special case, specifically the case of multiple trailing closures, which is a special case of trailing closures, which are weird and special-casey enough by themselves.
https://blog.metaobject.com/2020/06/the-curious-case-of-swif...
Oh, and Function Builders (2020, also me):
A prediction I made was that these rules, despite or more likely because of their complexity, would not be sufficient. And that turned out to be correct, as predicted, people turned to workarounds, just like they did with C++ and Java constructors.
https://blog.metaobject.com/2020/04/swift-initialization-swi...
So it is true that it is now bad and that it has gotten worse. It's just not the case that it was ever simple to start with. And the further explosion of complexity was not some accidental thing that happened to what was otherwise a good beginning. That very explosion was already pretty much predetermined in the language as it existed from inception and in the values that were visible.
From my exchange with Chris regarding initializers:
"Chris Lattner said...
Marcel, I totally agree with your simplicity goal, but this isn't practical unless you are willing to sacrifice non-default initializable types (e.g. non-nullable pointers) or memory safety."
Part of my response:
"Let me turn it around: Chris, I totally agree with your goal of initializable types, but it is just not practical unless you are willing to sacrifice simplicity, parsimony and power (and ignore the fact that it doesn't actually work)."
Simplicity is not the easy option. Simplicity is hard. Swift took the easy route.
[...] when you first attack a problem it seems really simple because you don't understand it. Then when you start to really understand it, you come up with these very complicated solutions because it's really hairy. Most people stop there. But a few people keep burning the midnight oil and finally understand the underlying principles of the problem and come up with an elegantly simple solution for it. But very few people go the distance to get there.
-- Steve Jobs (borrowed and adapted from Heinelein)
https://blog.metaobject.com/2014/04/sophisticated-simplicity...
Also a reason why Craig needs to go.
NVidia, AMD and Intel now have doubled now into giving Python GPU JITs, and Julia, the same capabilities as their CUDA, ROCm, and SYSCL offerings with C++.
With Julia and Python having their 1.0 long behind them.
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.
I've been using C# since the first release in 2003/4 timeline?
Aside from a few high profile language features like LINQ, generics, `async/await`, the syntax has grown, but the key additions have made the language simpler to use and more terse. Tuples and destructuring for example. Spread operators for collections. Switch expressions and pattern matching. These are mostly syntactic affordances.
You don't have to use any of them; you can write C# exactly as you wrote it in 2003...if you want to. But I'm not sure why one would forgo the improved terseness of modern C#.
Next big language addition will be discriminated unions and even that is really "opt-in" if you want to use it.
I was excited for DU until I saw the most recent implementation reveal.
https://github.com/dotnet/csharplang/blob/main/proposals/uni...
Compared to the beauty of Swift:
https://docs.swift.org/swift-book/documentation/the-swift-pr...
Very useful for reducing boilerplate and we can do some interesting things with it. One use case: we generate strongly typed "LLM command" classes from prompt strings.
Now having someone diving today into incremental code generators, with the best practices not to slow down Visual Studio during editing, that is a different matter.
They are naturally useful, as a user, as a provider, Microsoft could certainly improve the experience.
I would remove the distinction between value types and reference types at the type level. This has caused so many bugs in my code. This distinction should be made where the types are used not where they are defined.
I would remove everything related to concurrency from the language itself. The idea to let code execute on random threads without any explicit hint at the call site is ridiculous. It's far too complicated and error prone, which is why Swift designers had to radically change the defaults between Swift 6.0 and 6.2 and it's still a mess.
I would remove properties that are really functions (and of course property wrappers). I want to see at the call site whether I'm calling a function or accessing a variable.
I would probably remove async/await as well, but this is a broader debate beyond Swift.
And yes you absolutely do have to know and use all features that a language has, especially if it's a corporate language where features are introduced in order to support platform APIs.
But a lot of what you said, except for the concurrency and property wrapper stuff, largely exists for Obj-C interop. The generated interface is more readable, and swift structs act like const C structs. It’s nice.
* If you're in a team (or reading code in a third-party repo) then you need to know whatever features are used in that code, even if they're not in "your" subset of the language.
* Different codebases using different subsets of the language can feel quite different, which is annoying even if you know all the features used in them.
* Even if you're writing code entirely on your own, you still end up needing to learn about more language features than you need to for your code in order that you can make an informed decision about what goes in "your" subset.
To answer your question: I would immediately get rid of guard.
Also, I think the complexity and interplay of structs, classes, enums, protocols and now actors is staggering.
internal should definitely go though.
2. On top of that many of the features in the language exist not because they were carefully designed, but because they were rushed: https://news.ycombinator.com/item?id=47529006
I'm not 100% sure but I think the swift doc you linked is missing at least a dozen keywords so the truth probably lies in the middle
You sure pay for the language complexity in high compile times though. Swift is slow, like really slow. I’ve been with it since like v1.2, and its been getting progressively worse for a while IMO. Complex language features (Lets do a borrow checker! Lets do embedded!) and half of the shit isn’t being used internally as far as I can tell
Focusing on the keywords rather than the macros, I think the rest of them have legitimate use cases, though they're often misused, especially fileprivate.
i think most of them are pointless. not every feature needs to be a new keyword. stuff could be expressed within the language. if the language is so inflexible in that regard that it's impossible to express stuff without a keyword, use macros for gods sake.
why is there a need to have a "convenience func" declaration?
why is "didSet" a keyword?
what about "actor"? most other languages don't have nearly as many keywords and manage to express the idea of actors just fine!
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.
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.
This must have pushed Chris Lattner towards making Mojo both interpreted and compiled at the same time.
The Zen of Python is how we got crap like argparse where arguments are placed in the namespace instead of a dict.
If you had some feature flag args, you'd keep accessing them via the dict? Highly unlikely...
That's funny. To me magic is implicit by definition and Python strikes me as a very magical language compared to something like Java that is way more explicit.
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.
And then of course the case that proves the opposite, Clojure. Sure, new ideas appear, but core language is more or less unchanged since introduced, rock solid and decades old projects still run just fine, although usually a bit faster.
Also its market share adoption kind of shows it.
The latter is a bit tautological, since the size of the language grammar is itself a measure of complexity.
The complexity would be to grow like Common Lisp, instead it is up to Clojure folks to write Java, C#, JavaScript code, therein lies the complexity.
You don't know what you're talking about. Not only Clojure steadily adopting newer JVM features (for when that makes sense) - java streams, functional interfaces, qualified method values, interactive lib loading, JDK21 virtual threads, etc., Clojure constantly explores beyond the JVM - e.g., Jank targets LLVM and has C++ interop.
Pick some hardcore JVM topics and try searching what Clojurists think about them - GC, profiling, concurrency, etc. There's tons of interesting, deeply involved things constantly being hacked together by incredibly knowledgeable folks. You're casually name-dropping "complexity" maybe without even realizing that it's a community that includes people who have written production experience reports on Shenandoah GC, built profiling tools that work around safepoint bias, and given conference talks on tri-color marking algorithms. Dealing with complexity is their bread-n-butter. Challenging Clojurists to debate about "complexity" is like dropping "the brain has neurons" around a group of neurosurgeons. They'd quietly say nothing, so you can "win your argumentation", but they'll just... know.
Also I remember watching a recent talk, where virtual threads was still "being considered".
Having to write portable code that has to take into account the host differences, and difference in execution semantics, and still delivery the same outcome, is also complexity that keeps neurons busy.
> JVM bytecodes for dynamic languages
You're talkiing about invokedynamic - bytecode instruction added in Java 7, specifically to make dynamic language dispatch efficient, right? Explained simply: JVM was designed for static types - method calls resolved at compile time. In dynamic langs you don't know the type of something until runtime had to hack around, typically by boxing everything and doing manual type checks. This was slow and awkward. JRuby/Groovy adopted it eagerly. Clojure's dispatch model though is different. Most calls are either: direct interop (already statically typed), or calls through a Var (is a reference to a function value, not a dynamic method lookup). The Var indirection is a different shape of problem that invokedynamic doesn't solve as cleanly. It's not that it's useless, just that the fit isn't as natural.
> virtual threads was still "being considered"
That is an outdated info. Clojure 1.12.0 shipped two years ago with virtual thread support, but the integration with core.async's thread pool model was not there (so you were not completely incorrect). However, core.async later reimplemented go blocks using virtual threads when available. The improvements are still underway https://clojure.org/news/2025/10/01/async_virtual_threads
> take into account the host differences
Okay, this one is genuinely not that straightforward. The #? reader conditional in .cljc files is a clean, minimal mechanism. I don't really know any other language that can target completely different platforms from a single namespace as cleanly - even in Nodejs you can't in practice do it as nicely. Kotlin Multiplatform is probably the closest competitor - but its `expect/actual` mechanism requires separate source sets, separate files, and considerably more boilerplate. You're not writing in the same namespace; you're wiring together parallel declarations. Scala.js and GHCJS are essentially separate compilation targets with thinner sharing stories. But yes, it still can get complicated - different hosts have meaningfully different concurrency and I/O models, so it's rather "shared logic, host-specific edges" rather than "write once run anywhere". I still think Clojure handles this all far more elegantly than alternatives.
So pragmatically speaking, you're pointing at complexity at the implementation/runtime layer, while Clojure's complexity reduction happens at a different layer entirely - data model, immutability by default, simpler concurrency reasoning, REPL workflow. Those layers mostly don't interfere with each other. You mentioned real concerns at the platform engineering level, but they in practice don't touch what Clojure is actually trying to simplify. Someone writing Clojure code never experiences invokedynamic problems one way or the other.
If (or when? I haven't checked recently) a decent and well-thought-out LLVM backend emerges for it, ideally with some new underlying complexity seeping through, the market share might expand overnight.
And as for C++, while some complexity is certainly unavoidable, a rigorous complexity control is desperately needed. Ideally, the same way Bell Labs folks did when they initially conceived Go from Algol68 and C and similar (before or after joining Google; I couldn't tell), and Rich Hickey did when he initially designed Clojure. Some people are managing the complexity using style guides and clang-tidy checks. Which is great in that doing so doesn't need lengthy language committee decisions. But that approach hasn't been enough to make code _sufficiently_ safe; every now and then an enterprising engineer or team finds a way to abuse a feature in a way that produces unsafe or unpredictable results. Rust is a bit better and solves a few of the common problems, but sadly the list of potential issues (of using Rust in a codebase at scale; Engineers' faults, not Rust's) is long and growing. My verdict is we need both complex and simple LLVM languages, ideally co-designed to have no interop problems by design, while allowing expressing some logic in the simple parts and some logic in the complex parts. Or better, a 3 tier design would be nearly perfect: expressive config language, glue and research language, and core building blocks language. I think a clojure-style language can be designed to achieve all three.
I think the way of classical programming languages is behind us, unless AI implodes and we are back to programming without it.
Yes, that's one approach to avoiding ever growing complexity, maybe the other languages should try it sometime ;)
With that said, everything around Clojure keeps improving and getting better. While the language doesn't have static types, clojure.spec offers something that is even better than static typing (imo), and doesn't even require any changes to the core language. Something else other mainstream languages could learn too.
In theory we only need parentheses, prefix operators and a REPL, but mainstream never went down that route.
Anyway the complexity then ends up being custom DSLs and macros.
It feels like as if you're operating with a few keywords you picked up without fully understanding the meaning of them. Typed Clojure was a PhD research project. Experimental. CircleCI experimented with it at one point but the friction was high enough that it never became a standard practice - the annotation burden was significant. You'd be writing a lot of type scaffolding for a language whose entire value proposition includes getting things done with less ceremony. Clojure's power comes heavily from its data orientation. Maps, sequences, heterogeneous data flowing through pipelines. Traditional type systems are deeply uncomfortable with that style. You end up either constraining how you write Clojure, or writing very complicated types to describe simple data flows. Types are there, Clojure does have types, and OMG, non-clojure coders have no idea how expressive they can be. There's just no static checking and that's for good reasons.
Does Typed Clojure solve complexity? - No, not really. Complexity is about incidental complexity from complecting things - and a type system doesn't untangle that (according to Rich Hickey). You can have beautifully typed spaghetti.
I'm not against static typing, and I have used languages with really nice type systems. But honestly, whenever this point pops on forums and people be like "meh, Clojure is not typed" - I immediately know - they probably have only shallow experience working with Clojure code.
Just as you confirmed with your lengthy reply, by following up to my question.
First of all: Clojure is not "done". Latest commits were 3 months ago - https://github.com/clojure/clojure. Secondly, the language intentionally not 'all batteries-included' PL. The core is meant to be a stable, minimal substrate. Most action happens in libraries and tools - core.async, spec & malli, babashka, nbb, etc. Check the activity in Clojurians Slack. It's a small but unusually vibrant community, every single day there are news and announcements - updates, etc. It is done-ness in the good sense - like a well-designed tool that doesn't need to keep changing its handle.
> market share adoption kind of shows it
NuBank being the world's largest digital bank and running Clojure at scale is not "adoption"? Besides, there's Apple, Cisco, and tons of smaller companies running on it.
> there is hardly anything being done
They are making a documentary https://www.youtube.com/watch?v=JJEyffSdBsk Please don't say: "well, there are documentaries about dinosaurs" or something. I've been using Clojure for over ten years - in different teams, companies, industries. For my own projects and professionally. I've heard about it "dying" back then. I keep hearing about it dying every year and I promise you - nothing like that (even remotely) happening. Yes, the hype is gone (was it ever real?), but the language, community, library ecosystem, tooling - all of that only getting better.
There's no "killing" of Lisp. As long as programming languages remain relevant, there will always be some Lisp-dialect around. It probably never will become mainstream, yet it never completely disappears. There's no killing of Lisp, because it would be like killing "graph theory" or something. Graph theory doesn't need a Fortune 500 company funding it to remain true. Similarly, a small community keeping a Lisp dialect alive is all it takes - and there will always be people drawn to the clarity you get when you strip a language down to its lambda-calculus bones and see the whole thing fit in your head at once.
Rich Hickey has made this point himself - Clojure isn't trying to be the most popular language, it's trying to be correct about certain things. And correctness doesn't go out of fashion.
They aren’t able to bring concepts like “a file” into the standard because one standards body member maintains a compiler in some baroque ancient environment without the concept of a fs. Too much is forced to implement at the library level instead of in the compiler, and end up feeling half baked for real users (modules, coroutines etc).
Python powered by C++ libraries comes from HPC folks, places like CERN and Fermilab, they would hardly touched Swift instead.
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.
Since 5.10 it's been worth picking back up if you're on MacOS.
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.
I think Go has already taken that part of the cake.
It's a nice lang for sure, but this will never be true with the way things are. Such wasted opportunity by Apple.
E.g. ClearSurgery[0] is written fully in Swift, including the real-time components running on the Linux boxes.
[0] https://clearsurgery.vision
Same with Swift, but I'd call that more of a wasted opportunity because Apple, unlike Rust Foundation, has a mountain of money to make it happen, and yet they don't seem to care.
I don’t believe that’s true. Things are moving constantly, and in the right direction. Then again it would help if you cited particular grievances, because being a regular (cross-platform/cross-target) Swift user I am not sure what you are talking about…
I did not choose ClearSurgery’s example randomly. I was at a conference recently where the CTO was here, and he explicitly told us they were moving fast thanks to the Swift ecosystem. (I am not working there personally, nor am I affiliated.)
if they really want me to use this lang for everything, they'd have to 1. massively improve compilation speed, 2. get the ecosystem going (what's the correct way to spin up an http server like with express?) and 3. get rid of roughly 150 of the 200 keywords there are
especially w.r.t. the last one, of course everyone frets at huge breaking changes like this, so it won't happen, so people won't use it
I don't understand this point. Could you explain?
The new keywords enable new language features (ex: async/await, any, actor), and these features are opt-in. If you don't want to use them, you don't have to.
What are they keywords you think should be removed?
Using a language is more than just writing it with a pre-established knowledge of what subset of features you think is worth the tradeoffs. More keywords/features means when you try to figure out how to do something new, there may be 15 different ways and you need to analyze and figure out which is the best one for this scenario, which ones are nonstarters, etc.
That's was more or less the whole design goal of Go. It was made by C++ programmers who were fed up with how many features were in the language, so they kept the feature set limited. Even the formatting is decided by the language. You may not agree with every decision, but what matters is decisions were made and they're standardized, so everyone is on the same page. You can read anyone else's code, and you know exactly what's going on.
reading someone else's code is part of working with the language (as is understanding LLM output nowadays). i can't just make others not use the keywords i don't know/beed/like. especially if working within teams, or using OSS.
Especially in a corporate setting, not understanding a keyword you see in a PR could lead to bad code being checked in.
Hah! I'll use that argument if I ever get PIP'd.
No but seriously, constantly moving doesn't mean fast enough. Swift took took long to have cross-platform support.
And it is still uberslow to compile. To the point of language servers giving up on analyzing it and timeout.
Because they got much better at that, and it’s been a long while since that happened to me. Like “I don’t even remember when was the last time it happened” long.
You're commenting on a post about an update... that they apparently don't do? What?
Plus Swift is arguably too unnecessarily complex now.
And there's Rust/Zig so why use Swift for low level?
At least 6 years old.
I would argue the allegations of complexity against Swift are greatly exaggerated. I find the language to be very elegant and expressive in syntax, high in readability, and fairly terse. Other than that, Swift feels near identical to every other OoP language I have used.
With a simple tooling. No ugly script. Everything is naturally integrated.
What’s that supposed to mean?
Coming from C++ and JavaScript, there aren't many languages that can claim to have "simpler" tooling than Go.
The improvements in embedded Swift have definitely made it one of the most enjoyable/productive languages to work on the OS. I feel like I can build useful abstractions that wrap raw memory access and make the userland code feel very neat.
On the other hand, the compilation times are SO bad, that I'm really focusing on the Nim port anyway.
Nim really is clean and simple.
I lost immediately any interest on it
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).
https://www.swift.org/install/windows/
Which GUI toolkit(s) does that install support?
I'd pick it over Swift if targeting Android since it can build and run in the JVM as well as natively -- and has Swift/ObjC interop. Its also very usable on the server if you wanted to, since you can use it in place of Java and tap into the very mature JVM ecosystem. If that's what you're into.
And I have a lot more faith in JetBrains being good stewards of the language rather than Apple, who have a weird collection of priorities.
I tried to use Vapor with Swift recently and struggled to get something working because the documentation looked comprehensive, but had a lot of gaps. I ended up throwing it out because I didn't have the time to dig through the source to understand how to do something, when I could use a mature framework in any other language instead.
The promise is there but I'm just not ready to invest. My youthful days of unbounded curiosity are coming to an end and these days I just want to get something done without much faff.
However, the Kotlin community is fundamentally all about open source, whereas Apple & iOS Devs have an allergy to it. The quality and quantity is already miles above the vast majority of what's in the Swift ecosystem. https://klibs.io has all the native compatible libs. And if you're targeting a platform where the JVM is available then yeah, it's massive. Compose makes UI tolerable compared to JWT too. Even large projects like Spring are Kotlin first nowadays.
Is it gonna be what you primarily use if you wanna write an Android app? Probably not.
Is it gonna displace react Native? Probably not. Is it gonna reach the levels of flutter? Maybe.
However, I suspect that we may not be too far off, from LLMs being the true cross-platform system. You feed the same requirements, with different targets, and it generates full native apps.
Fully agree. I have zero Swift knowledge and currently use LLM to write a native app. I'm well aware of the SDKs and concepts in iOS development, so even if something's wrong I got intuition where to look and how to make the LLM fix it.
It would certainly be quite profitable. Money tends to drive progress.
Never. It won’t even reach Compose level, Flutter level DX is unattainable for any framework outside Flutter.
Why did this take so long to be added? Such strange priorities. Adding an entire C++ compiler for C++ interoperability before adding... C exports. Bizarre.
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.
SPM (swift package manager) is slowly reaching out to take over xcode build features (e.g., resources most recently), and they have been inching and hacking their way to a new swift-build engine (now experimental) and "prebuilt" modules for the compiler/IDE macro support. Things Go Wrong all the time when trying to replace parts while driving, and there's very little visibility or control over the interactions between SPM and Xcode.
Conversely to integrations, endogenous language progress seems relatively quiet because there's a lot of behind-the-scenes work extending the initial blush of lifetime controls to iterators, stdlib types, etc. (never mind parameter packs). They're in year 4+ of building out the function-coloring of concurrency and isolation domains (6.2 had an "easy" mode that caused lots of problems), so adding year 2+ dataflow coloring of lifetimes is doubly complicating.
Naturally, diverse support for exciting new features results in quite a spread in the third-party library ecosystem of support for various language features. And now with AI entrepreneurs rewriting and porting any project that can score hits and kudos, the usual open-source authorities are losing their steam.
Finally, there's the baseline platform complexity of multiple OS and devices, physical and simulator debugging support, cloud CI...
So: that makes four dimensions of complexity. As a Swift developer you'd have to be very careful to stay on a working path as things shift underneath you.
All for the love of it?
Unfortunately, swift-build is what Xcode has been using for years now, and has major performance issues: https://forums.swift.org/t/target-dependency-graph-computati...
Perhaps using it in both SPM and Xcode will lead to improvements, but I'm not especially optimistic.
I'm doubting this is a comparable setup for the vast majority of swift users. Is it unfortunate for people who land on this edge case - yes.
My experience shows it's fast and our iOS apps build faster than a feature parity Android app.
Swift Caching Compiler - https://github.com/jrz/tools
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.
FWIW, there is an active discussion on this very topic: https://forums.swift.org/t/proposal-compression-library/8541...
[0] https://swiftpackageindex.com/search?query=platform%3Alinux
[1] https://swiftpackageindex.com/search?query=platform%3Aandroi...
Im curious how is this used?
https://docs.instruqt.com/tracks/challenges/using-markdown-e...
but i think it's too coupled to Apple still. when i tried getting anything running on non-Apple, i had so much trouble i decided then to not even bother.
Reminds me of "In case you forgot, Swift has 217 keywords now" https://x.com/jacobtechtavern/status/1841251621004538183
But you can bridge build setting variables using some clever xcconfig macros that combine both preprocessor systems.
It's also strange because before I learned Swift, I heard about how beautiful it is but I find it much noisier than Rust.
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.
Yeah I fully accept it's just a me problem. But I hate it haha.
It's a shame but it for sure needs BigTech for it to be used anywhere else.
I'm not a native English speaker, just interested in the vernacular.
While the Flash guys had to use a native development environment and compile their stuff, I could just edit JavaScript in a plain text file and hit reload.
20 years later, and some of the same friends now swear by Swift. And have to use a native development environment and compile their stuff. While I still prefer to just edit JavaScript in a plain text file and hit reload.