Live data from Hacker News

Swift 6.3

swift.org

211–220 of 239 posts

Re: Swift 6.3

#211

Swift lives only for macOS,iOS and besides those ecosystems does not have a solid and robust ecosystem to be used for anything else. It's a shame but it for sure needs BigTech for it to be used anywhere else.

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

I guess what Swift misses compared to C# is enterprise usage.

Re: Swift 6.3

#212
post #113

Earlier quoted context omitted.

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…

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

Yeah, it seems something is still happening, they keep posting updates every now and then: https://forums.swift.org/t/differentiable-swift-feb-2026-upd...

Re: Swift 6.3

#214
post #131
post #13

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 letdo…

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 ecosyst…

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

Re: Swift 6.3

#215
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

Re: Swift 6.3

#216
post #29

Earlier quoted context omitted.

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": 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, speci…

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

This is brilliant. Thank you!

Re: Swift 6.3

#217
post #165

did they ever add #define? bridging constants from the build system to swift with static NSString * const kConstValue = @XSTR(CONST_VALUE); is soooo annoying.

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.

Re: Swift 6.3

#218
post #13

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 letdo…

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.

Re: Swift 6.3

#219
post #54

Earlier quoted context omitted.

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

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.

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.

Re: Swift 6.3

#220
post #137

Earlier quoted context omitted.

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 h…

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

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.

Post reply on HN