[HN Gopher] Swift 6.3
___________________________________________________________________
Swift 6.3
Author : ingve
Score : 289 points
Date : 2026-03-26 07:27 UTC (15 hours ago)
(HTM) web link (www.swift.org)
(TXT) w3m dump (www.swift.org)
| ttflee wrote:
| > Swift 6.3 includes the first official release of the Swift SDK
| for Android.
| gregoriol wrote:
| That is going to be used... less than Swift for the servers
| victorbjorklund wrote:
| 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 wrote:
| 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 wrote:
| > 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 wrote:
| I'm not sure about that but porting libraries from one
| language to another seems well within their capabilities.
| ChrisMarshallNY wrote:
| 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 wrote:
| > 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.
| iamcalledrob wrote:
| 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 wrote:
| 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 wrote:
| 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 wrote:
| 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.
| wiseowise wrote:
| 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 wrote:
| Just like .NET for linux... right? RIGHT?
| jkman wrote:
| At least a very common .NET web app framework is often
| deployed on linux. Powershell for linux might be more apt
| lol
| WillAdams wrote:
| Anything similar for Windows and Linux?
|
| For Windows there's a 5 year old blog post:
| https://www.swift.org/blog/swift-on-windows/
|
| For Linux there's a guide for GNOME:
| https://www.swift.org/blog/adwaita-swift/
|
| It would be really nice if instead we could just do one style
| of development and then ship a set of libraries as used to work
| for OpenSTEP (which was why it had "OPEN" in the name).
| myko wrote:
| 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
| migueldeicaza wrote:
| Swift on Windows has been part of the official distribution
| for a long time:
|
| https://www.swift.org/install/windows/
| WillAdams wrote:
| 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 wrote:
| 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.
| 0x3f wrote:
| > 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 wrote:
| How so? I can indeed target every layer of the software stack
| using Swift, _today_.
|
| E.g. ClearSurgery[0] is written _fully_ in Swift, including the
| real-time components running on the Linux boxes.
|
| [0] https://clearsurgery.vision
| zarzavat wrote:
| 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.
| frizlab wrote:
| That was true for Swift 2, maybe a little for Swift 3, but
| it has not been true since a long time now...
| hu3 wrote:
| 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?
| myHNAccount123 wrote:
| https://github.com/finagolfin/swift-android-sdk
|
| At least 6 years old.
| ethin wrote:
| 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.
| myHNAccount123 wrote:
| > 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 wrote:
| 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 wrote:
| 2/10
| 0x3f wrote:
| 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 wrote:
| > 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.)
| hu3 wrote:
| > 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 wrote:
| 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.
| merlindru wrote:
| 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 wrote:
| > 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 wrote:
| > 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.
| florentmorin wrote:
| It just works. One language. Many platforms. Incredible
| performance.
|
| With a simple tooling. No ugly script. Everything is
| naturally integrated.
| skydhash wrote:
| Isn't that Go?
| yunwal wrote:
| Go and "simple tooling" don't really belong in the same
| sentence. Powerful tooling, sure, but simple?
| g947o wrote:
| 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 wrote:
| 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
| wiseowise wrote:
| > No ugly script
|
| What's that supposed to mean?
| foltik wrote:
| The typical Apple sales pitch. Forgive me for assuming it's
| only surface level.
| michaelcampbell wrote:
| That it's designed for a thing and becoming the go-to choice
| for that thing can be far apart indeed.
| jkman wrote:
| Out of curiosity, could you point to a tech blog or something
| else going over clearsurgery's stack? That's really
| interesting
| sirwhinesalot wrote:
| > 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.
| saagarjha wrote:
| They had it earlier, as an underscored attribute.
| hrmtst93837 wrote:
| 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.
| asimovDev wrote:
| it's been there for a while as an experimental feature. I used
| it in a project
| dagmx wrote:
| You already had ObjC export so it was arguably low priority
| given the crossover
| rzerowan wrote:
| 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.
| frizlab wrote:
| A good source of available packages is the Swift Package Index.
| You can search here packages compatible with Linux[0].
|
| [0] https://swiftpackageindex.com/search?query=platform%3Alinux
| marcprux wrote:
| And also Android[1]!
|
| [1] https://swiftpackageindex.com/search?query=platform%3Aand
| roi...
| willtemperley wrote:
| 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 wrote:
| > There are still challenges with basics like compression
|
| FWIW, there is an active discussion on this very topic:
| https://forums.swift.org/t/proposal-compression-
| library/8541...
| cdcarter wrote:
| 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.
| dzonga wrote:
| 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++.
| rasmus1610 wrote:
| 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 wrote:
| 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, 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 wrote:
| 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?
| hirvi74 wrote:
| To be fair, I think such a fate in inevitable for most
| languages after many years of changes and development.
| mpweiher wrote:
| > 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)._
|
| 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...
| pjmlp wrote:
| 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 wrote:
| 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_.
| willtemperley wrote:
| Which keywords would you get rid of and why? You don't have
| to use all of them!
| eptcyka wrote:
| 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 wrote:
| Yes exactly, it's easy to blame a language when really
| it's a team problem.
| quietbritishjim wrote:
| 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.
| troupo wrote:
| 1. You don't have to use it all, but someone will. And
| there are _over 200_ keywords in the language:
| https://x.com/jacobtechtavern/status/1841251621004538183
|
| 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
| dematz wrote:
| are there actually 217 keywords? Just wondering what the
| difference between that file and
| https://docs.swift.org/swift-book/documentation/the-
| swift-pr... (a mere 102 keywords)
| merlindru wrote:
| 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 wrote:
| 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...
| uasi wrote:
| 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`).
| cloogshicer wrote:
| 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 wrote:
| 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 wrote:
| 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 wrote:
| 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
| fauigerzigerk wrote:
| 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 wrote:
| 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.
| merlindru wrote:
| i would get rid of associatedtype, borrowing, consuming,
| deinit, extension, fileprivate, init, inout, internal,
| nonisolated, open, operator, precedencegroup, protocol,
| rethrows, subscript, typealias, #available, #colorLiteral,
| #else, #elseif, #endif, #fileLiteral, #if, #imageLiteral,
| #keyPath, #selector, #sourceLocation, #unavailable,
| associativity, convenience, didSet, dynamic, indirect,
| infix, lazy, left, mutating, nonmutating, postfix,
| precedence, prefix, right, unowned, weak, and willSet
| willtemperley wrote:
| It's true that internal is pointless.
|
| 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.
| 72deluxe wrote:
| 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 wrote:
| 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 wrote:
| > 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...
| CharlieDigital wrote:
| 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 wrote:
| 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 wrote:
| :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 wrote:
| 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.
| msie wrote:
| 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.
| oefrha wrote:
| > 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.
| bossyTeacher wrote:
| > 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 wrote:
| Until you start using frameworks like Spring and then
| everything is so painfully magic that no one knows how the
| program actually runs.
| wiseowise wrote:
| Magical language how? And you should see what reflection
| based Java monstrosities do in the background.
| vovavili wrote:
| >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.
| commandersaki wrote:
| _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 wrote:
| 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 wrote:
| 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 wrote:
| 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 wrote:
| 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 wrote:
| > _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...
| vmsp wrote:
| True. Google was even thinking of switching TensorFlow from
| Python to Swift.
|
| https://github.com/tensorflow/swift
| mi_lk wrote:
| 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 wrote:
| 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 wrote:
| 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
| michaelcampbell wrote:
| > 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.
| wiseowise wrote:
| > 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 wrote:
| 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 wrote:
| 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 wrote:
| 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.
| mdemare wrote:
| Python 3 barely managed to dethrone Python.
| throwaway27448 wrote:
| 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 wrote:
| 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.
| jwlake wrote:
| 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.
| throwaway27448 wrote:
| 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
| tarentel wrote:
| > 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.
| WD-42 wrote:
| Dethroned Python? The Apple language, seriously. Where is numpy
| for swift?
| afavour wrote:
| 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 wrote:
| > just need something that can compile cross-platform and
| maintain great performance.
|
| I think Go has already taken that part of the cake.
| afavour wrote:
| Go is garbage collected, though. Rust and Swift still
| occupy a niche Go doesn't.
| mathverse wrote:
| ARC is a form of garbage collection. Swift does not fare
| better than Go usually.
| ramesh31 wrote:
| >"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.
| isodev wrote:
| > 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 wrote:
| 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?
| isodev wrote:
| > 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 wrote:
| 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.
| jshier wrote:
| 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.
| rTX5CMRXIfFG wrote:
| That's outright false:
|
| 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
| vips7L wrote:
| Man you gotta touch some grass instead of just insulting
| people.
| unconscionable wrote:
| Smoking grass can also help with this
| willio58 wrote:
| > 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.
| Terretta wrote:
| > _Haven 't used it since v3 though._
|
| Since 5.10 it's been worth picking back up if you're on MacOS.
| pjmlp wrote:
| 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 wrote:
| > 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 wrote:
| 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.
| embedding-shape wrote:
| > 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 wrote:
| 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 wrote:
| > Is Typed.Clojure finally stable and sound?
|
| It feels like you 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.
| zdragnar wrote:
| 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 wrote:
| 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 wrote:
| > 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.
| honr wrote:
| 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 wrote:
| 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.
| iLemming wrote:
| > 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.
| lynndotpy wrote:
| 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.
| zem wrote:
| 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 wrote:
| Same and not to mention reames of weird .Net errors that were
| never fixed and hard to understand or speculate about
| wwalexander wrote:
| 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 wrote:
| 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.
| troupo wrote:
| > @c @specialized @inline(always) @export(implementation)
|
| Reminds me of "In case you forgot, Swift has 217 keywords now"
| https://x.com/jacobtechtavern/status/1841251621004538183
| Batbird wrote:
| 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.
| TekMol wrote:
| 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 wrote:
| Given that Swift has one of the slowest compilation times, this
| is a valid criticism.
| drzaiusx11 wrote:
| No mention of compilation speed improvements? Very unfortunate.
| Compilation times slower than rust really hampers the devx of
| this otherwise decent language.
| roflcopter69 wrote:
| 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 wrote:
| Tuist is necessary for substantial projects
| asimovDev wrote:
| 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
| rubymamis wrote:
| I'm glad Chris Lattner moved on and founded Mojo. It's such a
| cool language with ton of potential.
| wycy wrote:
| I was excited about it when it first came out, but haven't
| heard anything about it since.
| dbvn wrote:
| I want to like swift so bad
| fithisux wrote:
| Lack of Mingw support keeps me away from it, and Odin.
| gloosx wrote:
| >nocopy for disabling copy-to-clipboard
|
| Im curious how is this used?
| OnionBlender wrote:
| It is a markdown thing. It removes the "copy" button from the
| code block when the markdown is rendered. Search for "nocopy"
| on this page.
|
| https://docs.instruqt.com/tracks/challenges/using-markdown-e...
| jbverschoor wrote:
| In an effort to use swift for scripting, without the startup
| cost:
|
| Swift Caching Compiler - https://github.com/jrz/tools
| mathverse wrote:
| 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.
| hirvi74 wrote:
| I still have hope Swift will break free like C# has. I hope one
| day something like Vapor or Kitura takes off.
| mathverse wrote:
| If Swift was paired with smh like QT/GTK (could have replaced
| Vala) it would've been interesting.
| classified wrote:
| smh?
| presbyterian wrote:
| It has been: https://www.swift.org/blog/adwaita-swift/
| hirvi74 wrote:
| The Lord's language keeps getting better and better. The easier C
| interop could not have come at a more serendipitous time in my
| life.
| lijunle wrote:
| 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 wrote:
| Both are apart of the toolchain now, no external dependencies
| required: `swift format` and `swift format lint` to access them
| pkpowell wrote:
| 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 -1deg. AI slop?
| sheept wrote:
| 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.
| slopinthebag wrote:
| 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.
| ChadNauseam wrote:
| What are you using for rust-swift interop?
| slopinthebag wrote:
| uniffi
| qn9n wrote:
| I find rust much noisier, especially at its basics where you
| write "for item in items" instead of using iter()
| slopinthebag wrote:
| 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.
| func sorted(by keyPath: KeyPath<User, String>) -> [User] {
| users.sorted { $0[keyPath: keyPath] < $1[keyPath: keyPath] }
| }
|
| ???
|
| Yeah I fully accept it's just a me problem. But I hate it
| haha.
| trevor-e wrote:
| >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.
| mikusnuz wrote:
| 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.
| gigatexal wrote:
| My chances of landing at Apple increased when they launched
| Swift. I am too dumb to learn objective C but swift I can do.
| cdcarter wrote:
| 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 wrote:
| 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 wrote:
| 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.
| PKop wrote:
| How about Odin?
| functional_dev wrote:
| yeah, Nim is great for that... much easier to explain to
| others than C or Zig especially for math code
| flykespice wrote:
| 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
| nesarkvechnep wrote:
| LISP like McCarthy LISP?
| jwlake wrote:
| did they ever add #define? bridging constants from the build
| system to swift with static NSString * const kConstValue =
| @XSTR(CONST_VALUE); is soooo annoying.
| vladde wrote:
| 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 wrote:
| skip.dev helps
| MrTomatoes wrote:
| Nice update, but it's a shame I can't write on it, not because I
| don't want to, but because it doesn't support it.
| MrTomatoes wrote:
| but still a good update
| w10-1 wrote:
| Beyond the marketing view... here are the (incomplete) changes:
| https://github.com/swiftlang/swift/blob/main/CHANGELOG.md
|
| Here are the evolution proposals that landed in 6.3:
| https://www.swift.org/swift-evolution/#?search=6.3
|
| 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.
|
| All for the love of it?
| jshier wrote:
| Looks like swift-build will be the default in Swift 6.4:
| https://forums.swift.org/t/swiftpm-development-update-defaul...
|
| 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.
___________________________________________________________________
(page generated 2026-03-26 23:01 UTC)