6 ms·

Swift – A great language strangled by governance?

100 points by Hashex129542 2y ago

jeswin 2y ago
I've used Python for nearly two decades. It's not a great programming language to write or maintain, and its package management makes npm (which is not great itself) look like a walk in the park. It's a bit unfortunate that it became AI's go-to programming language. I know it's subjective, but if we're arguing about Swift's quality by comparing with Python, I'm not buying it.
- rsyring 2y ago
  To each his own. I thoroughly enjoy Python, having used it for ~15 years now, have absolutely no issues with package management and haven't for the better part of a decade, and believe there are good reasons why Python "won" the data science, machine learning, etc. "battle." Namely, it's easy to use. It allows you to focus more on what you are trying to build than managing the language itself. It has strengths and weaknesses depending on domain just like any other language. Given it is one of the most, and sometimes _the_ most, popular programming language, I support the article using it as a comparison point.
  - danpalmer 2y ago
    I don't necessarily disagree with you, but regarding Python winning data science, I think that's in large part to a) Anaconda creating a single cohesive alternative ecosystem, shunned by engineers but loved by data scientists who just want to get things done, and b) the fact that with a couple of major libraries/frameworks you can get most things done, Pandas, Numpy, Sklearn, maybe a few others, meaning there's less dependency management to do overall.
    - rsyring 2y ago
      As a thought experiment, imagine someone had built Anaconda for C and then, instead of making Python APIs out of those mostly C libraries, just left the interface as C. Same packaging solution, same libraries, but the user has to learn C. Or swap C for Go even. No memory management but still more esoteric syntax and typing, interfaces, etc. required. How far does that get? The tools you mention were built on/around Python because it was realistic to ask technical but non-programmer users to learn to use Python. The lack of explicit typing and more "conversation" nature of Python syntax is, IMO, what makes that possible. So Python "wins" and other tooling is built on/around it to make it even easier for non-programmers to operate in the ecosystem, which solidifies it's position even more.
  - pama 2y ago
    I would love to hear positive python packaging stories because my other language packaging experiences (lisps, R, rust) felt so much better. Did you try to maintain python packages on a system with old gcc that cannot be upgraded and walk through the dependency hell explicitly while having SAT solvers fail to find compatible solutions after minutes at a time? Have you managed to keep bit-level reproducibility on future reproduction runs for more than five years in any other way than keeping the old OS and hardware around? What are your packaging tools of choice (setup.py is obsolete soon, poetry did not stick, pyproject.toml for the win I guess, conda at glacial speeds, pip too slow and prone to security risks, uv faster but incomplete, …)? Did you not encounter packages with dependency specs that no longer worked on future dates?
  - theshrike79 2y ago
    Python is excellent as long as you run it on your own computer. Having to distribute a Python application with all of its dependencies and libraries is a pain I don't want to experience.
- deleted 2y ago
  [deleted]
- fumeux_fume 2y ago
  They're comparing governance of the language so your bellyaching about package management seems neither here nor there.
- odyssey7 2y ago
  Python got adopted by academics around ‘10, because it had lower barriers for new programmers than Java (now legacy) and C (now a specialization). The language and tooling options of today mean that the initial reasons for academia embracing Python are long gone. Python now presents more barriers to new programmers than alternatives. I agree. It’s a shame that the machine learning community has married itself to Python, since it gives Python a staying force that it doesn’t really merit.
  - deleted 2y ago
    [deleted]
danpalmer 2y ago
This just doesn't match with my experience of Swift. My experience is a language that is well designed, at times feeling too complex, but always justifying that complexity with correctness when I dig into the reasons. Most of the language is driven by an open process, to the point that language announcements at WWDC are only a recap of the last year of accepted enhancement proposals. "A great language strangled by governance" – it's not clear to me that Swift is in a materially worse place than any of the 3 alternatives this post points to. Rust has had a lot of drama and botched their async/await, Python had 3, took a decade to recover, and has failed to address its terrible packaging over the last 2 decades, and the Kotlin process described sounds almost identical to the Swift process. Was Swift entirely top-down controlled at the beginning, with a bunch of breaking changes? Yes, but it has very clearly graduated from its early development now with no forced breaking changes and an open proposal process that is clearly working. Has Swift hard-coded Apple framework exceptions? Maybe, but that has never gotten in the way of me using or understanding Swift code, so I'm not sure it affects me as a developer. Has Swift become a hugely complex compiler? Sure, but I'd rather have a complex compiler and a better developer experience, especially if Apple is paying for it. I don't disagree with the facts here, this just doesn't resonate with me at all. I'm a very happy Swift user, would like to be using it a lot more, and enjoy the forward momentum in the ecosystem as Swift becomes in my mind one of the most advanced languages available.
- skavi 2y ago
  Not to your main point, but I don’t think it’s fair to say Rust “botched” its async impl. There are certain features it’s missing, but nothing about the design really prevents them from being added. And many have been in the past few years. I’d point to the “leakpocalypse” as a more fundamental Rust flaw.
  - adastra22 2y ago
    Having perpetually colored functions is a huge, fundamental annoyance with the Rust concurrency design.
    - 2y ago
shmerl 2y ago
> Apple has the purest incentive of all: maximise profit for shareholders. I'd call it the impurest incentive of all.
- MathMonkeyMan 2y ago
  pure adjective unmixed with any other matter
  - shmerl 2y ago
    Sure, it's still completely impure in another sense, as in for the benefit of the language and its users.
DavidiEu16 2y ago
[flagged]
dadoum 2y ago
I also think Swift is getting bloated (and this can be seen in the compile times which are getting out of hand). Sometimes I feel like some features of Swift have been implemented without being well thought about, just because they are popular in the programming crowd. I am thinking more specifically about metaprogramming, which was originally a non goal, but I guess with time they saw it has a point and they replicated Rust's approach with syntactic macros which is to me a very poor approach. You need to much boilerplate to write a macro since it's a compiler plugin basically, and you can't interpret the semantic of the underlying code without reimplementing part of compiler's logic. I can find other examples, and that's not always bad, but I am not sure that's the right way of designing a language.
- jarjoura 2y ago
  I still have no idea where macros fit into a project, or why I would want to use them. They seemingly built this functionality for SwiftUI previews maybe?! and didn't really consider how this could be a core part of the language. At least with rust, you can just lightly add them in the same module and at a minimum use them to avoid boilerplate code duplication. Macros in rust work as a core language feature because of the way the borrow checker works. You can't really break apart some methods since you need to establish ownership. So, you can easily end up with duplicated code that gets noisy. Macros are the escape hatch to do that, and yes, they are also complex to write, but at least I know when I'd want to use them. Swift doesn't really document how to create macros, and they didn't really spend energy explaining how they would be valuable to a project and worth the engineering cost of implementing them.
  - pjmlp 2y ago
    They fit into the same way as C, C++, Lisp, Scheme, Rust, Scala... macros, Java and Kotlin compiler plugins, .NET code generators, do fit into a project. There are several WWDC sessions about how and why.
  - jen20 2y ago
    https://docs.swift.org/swift-book/documentation/the-swift-programming-language/macros/ https://docs.swift.org/swift-book/documentation/the-swift-pr... seems to do both to me?
deleted 2y ago
[deleted]
aaronbrethorst 2y ago
I think Swift has been strangled, but I'm not convinced it's because of its governance structure (with Apple at the top). I get the impression that Swift is the world's best sandbox for programming language nerds to play in—and that Apple is woefully understaffing the team writing technical copy for the compiler (e.g. error messages), and the documentation. The rate at which the Swift language has changed just in the past 3 years feels as significant as the rate at which it changed between 2016, with the release of Swift 3, and 2022. I'm sure that people who are 100% all in on iOS development feel like the rate of change is delightful, but for the rest of us who have other responsibilities, it's exhausting and bewildering.
- Terretta 2y ago
  On the other hand, this burst of change brought it over a line into functional and declarative usability. Somewhere from 5.7 through 5.10 it indeed became meaningfully more “delightful” to use. Delightful not because of the rate of change, but because of the programming approach it's now enabled.
jamil7 2y ago
I don’t necessarily disagree with the article but I think the language is in a much but better place than it was a few years ago, with a few exceptions. As the author points out, Foundation and a bunch of frameworks and libraries are being open sourced and maintained by Apple and the Swift foundation which are all cross platform (including Windows and Linux). The static concurrency checking stuff is cool on paper but has so far just introduced noise to our codebase so we’re not touching it until it cooks a little more. I’m basically asking for the same thing I was 5 years ago though and the author touches on, fix the compiler issues. Official Android support would be nice too but the community is filling the gap there. I use Rust a little on the side and tooling, compiler messages and ecosystem are far ahead of Swift. Language wise I still prefer Swift for the work I do.
easeout 2y ago
Swift has a lot of features, but you can leave many of them alone to begin with and learn them when you need them. Low-syntax defaults work in a reasonable, streamlined way. SwiftUI will confront you with more syntactic variations than other Swift code, but that's not unusual in a DSL. Overall it's a smooth learning curve due to progressive disclosure in language features. If Swift compiled five times faster, I would want for very little. But I don't know how they'd walk back the combination of type-based overloading and implicit conversions. See: https://belkadan.com/blog/2021/08/Swift-Regret-Type-based-Overloading/?tag=swift-regrets https://belkadan.com/blog/2021/08/Swift-Regret-Type-based-Ov...
quotemstr 2y ago
Who cares about keyword count? Reserved words preserve flexibility while not realistically impairing programmer expression. What do you do with a keyword-impoverished language? 1) overload the keywords you do have to mean random unrelated things depending on context (which is why "static" in C++ means a bunch of random things), or ' 2) create context-dependent keywords (e.g. "final" in C++ and "match" in Python), which work, but complicate every parser everywhere. As much as it pains me to type the following: JavaScript got it right. The initial version of the language reserved a number of keywords (e.g. "class") that would only become useful two decades later.
mythz 2y ago
Every few years I revisit Swift to see if things have improved but the language is now even more complex with cryptic compiler errors and poor runtime error messages, long build times and slow iteration times. Xcode is still a horrible IDE and unfortunately JetBrains AppCode has since been discontinued, basically forcing using VS Code for development and Xcode to run/debug tests. It can finally do async/await but its async http requests were unstable/unusable on Linux and cross platform is a chore with littering macros like `#if canImport(FoundationNetworking)` everywhere. Used to think Swift was the future given the resources Apple could throw behind it, but at its current state after 10 years I no longer do. It will remain a mainstay thanks to the Apple ecosystem, but don't see its popularity extending far beyond that.
Heliosmaster 2y ago
A honest question here from outside of the Swift world: why does it matter? I'm a Clojure developer, have been exclusively one for the last 10 years and have no intention of changing anytime soon (in other words, I don't care/follow closely what the majority of development world is and what the trends are). A few years ago we had "Open Source is Not About You" [1] by Rich Hickey, basically pushing back that the creator(s) of Open Source don't owe anything back to the community. That piece has aged well for me: now I understand that something is what it is, not what I wish it was. And more importantly, the goal of open source isn't to be liked or used by everybody. It's a thing put out by its creator for others to use, and that includes Apple. So really, why does the governance matter so much? If you don't agree with something, why not fork it and make it like you want it? [1]: https://gist.github.com/richhickey/1563cddea1002958f96e7ba9519972d9 https://gist.github.com/richhickey/1563cddea1002958f96e7ba95...
- saagarjha 2y ago
  Forking a programming language is no small feat.
alexashka 2y ago
Swift will be fine as long as they invest in Mini-Swift that improves compile times by 10x and make it seamlessly interop with Papa-Swift the current behemoth. I'm sure they're aware of the compile times. If they can make C++ interop work (not easy), they can make Mini-Swift :) As for this governance talk - I can only shake my head at these attempts to start drama. I don't understand it.
KingOfCoders 2y ago
Ladybird switching to Swift made me think. Then there was this article recently on HN on Swift vs. Rust. I would give Swift a chance, I do think currently it lacks open source projects for server side development (all the batteries).
napierzaza 2y ago
[dead]
lukeh 2y ago
Look, I wish the compiler was faster and the diagnostics more helpful but I find Swift pretty great! And I'm using it on Linux.
w10-1 2y ago
I disagree. [edit: sorry: not completely?] Decisions are made openly with excellent (if exhaustive) discussion, clear reasoning, and mostly on the merits. Features are building on prior features over the years, and when things have needed to be changed or deprecated, they get changed. So the language is alive but not encrusted. Decisions are made much more independently and quickly than Java, which has a similar installed code base and motivated corporate patron. Both small-scope and sweeping architectural changes work through the evolution process pretty quickly. All languages starts with a clean sweet spot but major gaps, and then migrate to common features as they age. Right now, Swift has probably the most mature concurrency plan of all languages, and is beginning to address the lifetime issues presented by value types. No other language blends low-level efficiency and control with high-level type-safety so well - no less seamless inter-op with C/C++, static macros, etc. What's not maturing as fast: third-party libraries ecosystem because most people just need Apple's, Windows support (because - why?), and alternate IDE's, static analysis, etc. As for 217 keywords, etc.: be glad there's a name for everything, without a plethora of ways to do the same thing. If it weren't easier to do complicated things with a correspondingly complicated language, everyone would be writing functional lisp code. The real problem now is there's no real agreement on how to do the function coloring, effects, traits, etc., but that's what's needed to make use of modern hardware. In particular, the type system being bidirectional has made it both pleasant (when it works) and painful (when it doesn't), and stuffing all this new behavior into a type system constraint solver is a bit of a black art. Venn diagrams and verbiage aside, it's just hard for people to think about, e.g., what ~Copyable means for generic parameters, or how a parameter can place a function in a different memory region. But they'll do it after a boatload of discussion, and then make a dumbed-down happy-path 10-minute video for WWDC with code folks can play with - 10 million folks. If anything, the language is strangled by history, but remains attractive because the team does such a good job.
willtemperley 2y ago
Surely the "some" keyword the author is railing about actually _improves_ composability, and is in fact exactly in line with Lattner's vision "Simple things that compose." The accepted answer here [1] explains this better than I can. I can't share the author's enthusiasm for Swift on server either. WASM support is not production ready so Cloudflare workers or Deno deploy is out. Vapor is the only properly maintained framework I can find (happy to be corrected) which I did not find ergonomic. Google Cloud Functions or AWS Lambda would be options but there's no reason to limit oneself when Rust is production ready on most web platforms. [1] https://stackoverflow.com/questions/56433665/what-is-the-some-keyword-in-swiftui https://stackoverflow.com/questions/56433665/what-is-the-som...
saagarjha 2y ago
This is an insulting piece. It's a poor hitjob by someone who doesn't really know what is going on, which is extra unfortunate because Swift has a bunch of problems. Some of them are actually adjacent to the claims here! But this is just unsubstantiative flamebait. Swift is controlled by Apple, Inc. Nobody worth listening to is denying that. The steering committee is almost all Apple employees, most of the commits going in come from people who commute to Cupertino, and whatever the progress is on Windows or Arduino or whatever, it's clear that "first class" really means iOS. That's all true. Apple makes proposals, they seek some community input, and in the end they pick what they like and it ends up in the language. But even with that said, the rest of this post is of low quality. Tim Cook and his MBA buddies didn't personally come in to ruin the language because the shareholders aren't making money. Chris Lattner is, whatever his contributions to the language previously, just a guy. He would probably try to put Swift on GPUs today if he had his way. It's not the first time he sold it out before. You've got to go beyond "omgz so many keywords so complicated!!1!!" and look deeply at the real sources of complexity. Swift has a powerful generics system that has worst-case behavior that really sucks. The discussion process has a bunch of busybodies that have nothing better to do than talk about names of things. Yes. These are real problems. It's funny when there are random hacks in the source code to support things that Apple is shipping. But that is how a large project works. You are more than welcome to laugh about it on Twitter but substantive criticism it is not. Which is a shame, because there is plenty of it go around.
- pjmlp 2y ago
  These kind of pieces is what ends up with worshiping stuff like Go with its clunky design evolution, it turns out either the language handles the complexity of the world, or the source code makes it visible in needless boilerplate. Agree on the general tone, only up voted by accident.
- kaishin 2y ago
  I like how the conclusion of the article paints a very positive picture for the language. It’s as if the entire negative tone of the article was a poor attempt to sound insightful for clicks.
randomNumber7 2y ago
I think Swift is a really nice language when you look at the design. I really liked protocol extensions for example. The problem I have with it is that some decisions are very ideologic. You can easily link to C libraries for example, but the pointer types in Swift are so fucking unusable (because pointers are evil) that it makes no sense to try it. (unless you cannot chose an other language)
zer0x4d 2y ago
Call me a fanboy, but Swift is one of the best languages I've ever had the privilege of using. I'm truly hopeful with some more work, it's able to become the de-facto cross-platform language. The complexity is very manageable, a decent Java, Objective-C or .NET developer can pick it up in less than a day, is feature-packed and stuff just make sense.
- willtemperley 2y ago
  I also love that we can write high-performance graphics apps without C++ (OK shaders are kind of C++ but that's fine as long as it stays there).
pjmlp 2y ago
It doesn't matter, because Swift is one of those languages that enjoys an overlord, anyone that wants to target its overlord platforms eventually has to deal with Swift. Same with Java and Kotlin on Android, .NET and C++ on Windows, JavaScript on the Web, ISO C on UNIX/POSIX, Go on Docker/Kubernetes,....
kaishin 2y ago
This article is full of statements that are not backed up by any material proof. The author claims that Swift features no longer compose without giving a single example. I write Swift SDKs for a living and I have never thought that any of the recent features felt incompatible, incongruous, or redundant. Sure, each has its strengths and weaknesses, but that results in an expressive language where every problem has several solutions with different tradeoffs. When it comes to governance, it’s not without wrinkles, but it’s not as bad as the author makes it sound. If anything, things got a bit less “dictatorial” since Chris left. Different core team members pull in slightly different directions which made the language more balanced in my view.
jakey_bakey 2y ago
Thanks so much for sharing my work! :) The devs here are a lot more nuanced than the guys on Reddit lol
tayistay 2y ago
If you have a recent machine, the actual developer experience isn't too bad. It's just not a language for language purists (was it ever?). I'm enough of a purist to be annoyed whenever I see the "expression took too long to type check" error. (I think bidirectional type inference isn't worth it with Swift) The gaggle of verbose pointer types makes me want to switch to C++ whenever I have to deal with memory directly. As the article mentions, a bunch of features were added for the sake of SwiftUI. Function builders allow SwiftUI's syntax to be minimal. They allow you to write: VStack { SomeView() AnotherView() } instead of something like VStack( SomeView(), AnotherView() ) Given the rather bad (still!) error messages you get with SwiftUI that seem to be a result of function builders, I'd say it wasn't worth it. At least I get fewer of the "couldn't produce a diagnostic, please file a bug" errors than I used to. Then there are property wrappers, which wrap struct/class fields with get/set code (IIRC Lattner didn't like the property wrappers). They've been partially replaced in SwiftUI by macros. The @Observable macro (probably the most widely used one) decorates your class with code that notifies listeners (almost always SwiftUI) of changes. I'd be curious to see what SwiftUI would look like without property wrappers (or macros). I think they had a missed opportunity to really add robust updating of views in response state changes. Currently it's still relatively easy to not have your SwiftUI views update because your data model uses some object that isn't @Observable. I wrote a UI library inspired by SwiftUI, but in Rust [1], and of course I couldn't add anything to the language, and more experienced Rust programmers discouraged me from using macros. So it can be done without all the extra stuff Swift added. [1] https://github.com/audulus/rui https://github.com/audulus/rui
- willtemperley 2y ago
  Isn't it by design that only observable or state data update views? Otherwise there would be significant overhead watching everything.
p0w3n3d 2y ago
Paywalled?
- Hashex129542 2y ago
  Yes, I didn't knew about it. When I was read, there is full article is there without paywall. Seems, after some traffic they showing to subscribe to read the page.

100 points by Hashex129542 2y ago

I've used Python for nearly two decades. It's not a great programming language to write or maintain, and its package management makes npm (which is not great itself) look like a walk in the park. It's a bit unfortunate that it became AI's go-to programming language. I know it's subjective, but if we're arguing about Swift's quality by comparing with Python, I'm not buying it.

rsyring 2y ago
To each his own. I thoroughly enjoy Python, having used it for ~15 years now, have absolutely no issues with package management and haven't for the better part of a decade, and believe there are good reasons why Python "won" the data science, machine learning, etc. "battle." Namely, it's easy to use. It allows you to focus more on what you are trying to build than managing the language itself. It has strengths and weaknesses depending on domain just like any other language. Given it is one of the most, and sometimes _the_ most, popular programming language, I support the article using it as a comparison point.
- danpalmer 2y ago
  I don't necessarily disagree with you, but regarding Python winning data science, I think that's in large part to a) Anaconda creating a single cohesive alternative ecosystem, shunned by engineers but loved by data scientists who just want to get things done, and b) the fact that with a couple of major libraries/frameworks you can get most things done, Pandas, Numpy, Sklearn, maybe a few others, meaning there's less dependency management to do overall.
  - rsyring 2y ago
    As a thought experiment, imagine someone had built Anaconda for C and then, instead of making Python APIs out of those mostly C libraries, just left the interface as C. Same packaging solution, same libraries, but the user has to learn C. Or swap C for Go even. No memory management but still more esoteric syntax and typing, interfaces, etc. required. How far does that get? The tools you mention were built on/around Python because it was realistic to ask technical but non-programmer users to learn to use Python. The lack of explicit typing and more "conversation" nature of Python syntax is, IMO, what makes that possible. So Python "wins" and other tooling is built on/around it to make it even easier for non-programmers to operate in the ecosystem, which solidifies it's position even more.
- pama 2y ago
  I would love to hear positive python packaging stories because my other language packaging experiences (lisps, R, rust) felt so much better. Did you try to maintain python packages on a system with old gcc that cannot be upgraded and walk through the dependency hell explicitly while having SAT solvers fail to find compatible solutions after minutes at a time? Have you managed to keep bit-level reproducibility on future reproduction runs for more than five years in any other way than keeping the old OS and hardware around? What are your packaging tools of choice (setup.py is obsolete soon, poetry did not stick, pyproject.toml for the win I guess, conda at glacial speeds, pip too slow and prone to security risks, uv faster but incomplete, …)? Did you not encounter packages with dependency specs that no longer worked on future dates?
- theshrike79 2y ago
  Python is excellent as long as you run it on your own computer. Having to distribute a Python application with all of its dependencies and libraries is a pain I don't want to experience.
deleted 2y ago
[deleted]
fumeux_fume 2y ago
They're comparing governance of the language so your bellyaching about package management seems neither here nor there.
odyssey7 2y ago
Python got adopted by academics around ‘10, because it had lower barriers for new programmers than Java (now legacy) and C (now a specialization). The language and tooling options of today mean that the initial reasons for academia embracing Python are long gone. Python now presents more barriers to new programmers than alternatives. I agree. It’s a shame that the machine learning community has married itself to Python, since it gives Python a staying force that it doesn’t really merit.
- deleted 2y ago
  [deleted]

danpalmer 2y ago

This just doesn't match with my experience of Swift. My experience is a language that is well designed, at times feeling too complex, but always justifying that complexity with correctness when I dig into the reasons. Most of the language is driven by an open process, to the point that language announcements at WWDC are only a recap of the last year of accepted enhancement proposals. "A great language strangled by governance" – it's not clear to me that Swift is in a materially worse place than any of the 3 alternatives this post points to. Rust has had a lot of drama and botched their async/await, Python had 3, took a decade to recover, and has failed to address its terrible packaging over the last 2 decades, and the Kotlin process described sounds almost identical to the Swift process. Was Swift entirely top-down controlled at the beginning, with a bunch of breaking changes? Yes, but it has very clearly graduated from its early development now with no forced breaking changes and an open proposal process that is clearly working. Has Swift hard-coded Apple framework exceptions? Maybe, but that has never gotten in the way of me using or understanding Swift code, so I'm not sure it affects me as a developer. Has Swift become a hugely complex compiler? Sure, but I'd rather have a complex compiler and a better developer experience, especially if Apple is paying for it. I don't disagree with the facts here, this just doesn't resonate with me at all. I'm a very happy Swift user, would like to be using it a lot more, and enjoy the forward momentum in the ecosystem as Swift becomes in my mind one of the most advanced languages available.

skavi 2y ago
Not to your main point, but I don’t think it’s fair to say Rust “botched” its async impl. There are certain features it’s missing, but nothing about the design really prevents them from being added. And many have been in the past few years. I’d point to the “leakpocalypse” as a more fundamental Rust flaw.
- adastra22 2y ago
  Having perpetually colored functions is a huge, fundamental annoyance with the Rust concurrency design.
  - 2y ago

shmerl 2y ago

> Apple has the purest incentive of all: maximise profit for shareholders. I'd call it the impurest incentive of all.

MathMonkeyMan 2y ago
pure adjective unmixed with any other matter
- shmerl 2y ago
  Sure, it's still completely impure in another sense, as in for the benefit of the language and its users.

DavidiEu16 2y ago

[flagged]

dadoum 2y ago

I also think Swift is getting bloated (and this can be seen in the compile times which are getting out of hand). Sometimes I feel like some features of Swift have been implemented without being well thought about, just because they are popular in the programming crowd. I am thinking more specifically about metaprogramming, which was originally a non goal, but I guess with time they saw it has a point and they replicated Rust's approach with syntactic macros which is to me a very poor approach. You need to much boilerplate to write a macro since it's a compiler plugin basically, and you can't interpret the semantic of the underlying code without reimplementing part of compiler's logic. I can find other examples, and that's not always bad, but I am not sure that's the right way of designing a language.

jarjoura 2y ago
I still have no idea where macros fit into a project, or why I would want to use them. They seemingly built this functionality for SwiftUI previews maybe?! and didn't really consider how this could be a core part of the language. At least with rust, you can just lightly add them in the same module and at a minimum use them to avoid boilerplate code duplication. Macros in rust work as a core language feature because of the way the borrow checker works. You can't really break apart some methods since you need to establish ownership. So, you can easily end up with duplicated code that gets noisy. Macros are the escape hatch to do that, and yes, they are also complex to write, but at least I know when I'd want to use them. Swift doesn't really document how to create macros, and they didn't really spend energy explaining how they would be valuable to a project and worth the engineering cost of implementing them.
- pjmlp 2y ago
  They fit into the same way as C, C++, Lisp, Scheme, Rust, Scala... macros, Java and Kotlin compiler plugins, .NET code generators, do fit into a project. There are several WWDC sessions about how and why.
- jen20 2y ago
  https://docs.swift.org/swift-book/documentation/the-swift-programming-language/macros/ https://docs.swift.org/swift-book/documentation/the-swift-pr... seems to do both to me?

deleted 2y ago

[deleted]

aaronbrethorst 2y ago

I think Swift has been strangled, but I'm not convinced it's because of its governance structure (with Apple at the top). I get the impression that Swift is the world's best sandbox for programming language nerds to play in—and that Apple is woefully understaffing the team writing technical copy for the compiler (e.g. error messages), and the documentation. The rate at which the Swift language has changed just in the past 3 years feels as significant as the rate at which it changed between 2016, with the release of Swift 3, and 2022. I'm sure that people who are 100% all in on iOS development feel like the rate of change is delightful, but for the rest of us who have other responsibilities, it's exhausting and bewildering.

Terretta 2y ago
On the other hand, this burst of change brought it over a line into functional and declarative usability. Somewhere from 5.7 through 5.10 it indeed became meaningfully more “delightful” to use. Delightful not because of the rate of change, but because of the programming approach it's now enabled.

jamil7 2y ago

I don’t necessarily disagree with the article but I think the language is in a much but better place than it was a few years ago, with a few exceptions. As the author points out, Foundation and a bunch of frameworks and libraries are being open sourced and maintained by Apple and the Swift foundation which are all cross platform (including Windows and Linux). The static concurrency checking stuff is cool on paper but has so far just introduced noise to our codebase so we’re not touching it until it cooks a little more. I’m basically asking for the same thing I was 5 years ago though and the author touches on, fix the compiler issues. Official Android support would be nice too but the community is filling the gap there. I use Rust a little on the side and tooling, compiler messages and ecosystem are far ahead of Swift. Language wise I still prefer Swift for the work I do.

easeout 2y ago

Swift has a lot of features, but you can leave many of them alone to begin with and learn them when you need them. Low-syntax defaults work in a reasonable, streamlined way. SwiftUI will confront you with more syntactic variations than other Swift code, but that's not unusual in a DSL. Overall it's a smooth learning curve due to progressive disclosure in language features. If Swift compiled five times faster, I would want for very little. But I don't know how they'd walk back the combination of type-based overloading and implicit conversions. See: https://belkadan.com/blog/2021/08/Swift-Regret-Type-based-Overloading/?tag=swift-regrets https://belkadan.com/blog/2021/08/Swift-Regret-Type-based-Ov...

quotemstr 2y ago

Who cares about keyword count? Reserved words preserve flexibility while not realistically impairing programmer expression. What do you do with a keyword-impoverished language? 1) overload the keywords you do have to mean random unrelated things depending on context (which is why "static" in C++ means a bunch of random things), or ' 2) create context-dependent keywords (e.g. "final" in C++ and "match" in Python), which work, but complicate every parser everywhere. As much as it pains me to type the following: JavaScript got it right. The initial version of the language reserved a number of keywords (e.g. "class") that would only become useful two decades later.

mythz 2y ago

Every few years I revisit Swift to see if things have improved but the language is now even more complex with cryptic compiler errors and poor runtime error messages, long build times and slow iteration times. Xcode is still a horrible IDE and unfortunately JetBrains AppCode has since been discontinued, basically forcing using VS Code for development and Xcode to run/debug tests. It can finally do async/await but its async http requests were unstable/unusable on Linux and cross platform is a chore with littering macros like `#if canImport(FoundationNetworking)` everywhere. Used to think Swift was the future given the resources Apple could throw behind it, but at its current state after 10 years I no longer do. It will remain a mainstay thanks to the Apple ecosystem, but don't see its popularity extending far beyond that.

Heliosmaster 2y ago

A honest question here from outside of the Swift world: why does it matter? I'm a Clojure developer, have been exclusively one for the last 10 years and have no intention of changing anytime soon (in other words, I don't care/follow closely what the majority of development world is and what the trends are). A few years ago we had "Open Source is Not About You" [1] by Rich Hickey, basically pushing back that the creator(s) of Open Source don't owe anything back to the community. That piece has aged well for me: now I understand that something is what it is, not what I wish it was. And more importantly, the goal of open source isn't to be liked or used by everybody. It's a thing put out by its creator for others to use, and that includes Apple. So really, why does the governance matter so much? If you don't agree with something, why not fork it and make it like you want it? [1]: https://gist.github.com/richhickey/1563cddea1002958f96e7ba9519972d9 https://gist.github.com/richhickey/1563cddea1002958f96e7ba95...

saagarjha 2y ago
Forking a programming language is no small feat.

alexashka 2y ago

Swift will be fine as long as they invest in Mini-Swift that improves compile times by 10x and make it seamlessly interop with Papa-Swift the current behemoth. I'm sure they're aware of the compile times. If they can make C++ interop work (not easy), they can make Mini-Swift :) As for this governance talk - I can only shake my head at these attempts to start drama. I don't understand it.

KingOfCoders 2y ago

Ladybird switching to Swift made me think. Then there was this article recently on HN on Swift vs. Rust. I would give Swift a chance, I do think currently it lacks open source projects for server side development (all the batteries).

napierzaza 2y ago

[dead]

lukeh 2y ago

Look, I wish the compiler was faster and the diagnostics more helpful but I find Swift pretty great! And I'm using it on Linux.

w10-1 2y ago

I disagree. [edit: sorry: not completely?] Decisions are made openly with excellent (if exhaustive) discussion, clear reasoning, and mostly on the merits. Features are building on prior features over the years, and when things have needed to be changed or deprecated, they get changed. So the language is alive but not encrusted. Decisions are made much more independently and quickly than Java, which has a similar installed code base and motivated corporate patron. Both small-scope and sweeping architectural changes work through the evolution process pretty quickly. All languages starts with a clean sweet spot but major gaps, and then migrate to common features as they age. Right now, Swift has probably the most mature concurrency plan of all languages, and is beginning to address the lifetime issues presented by value types. No other language blends low-level efficiency and control with high-level type-safety so well - no less seamless inter-op with C/C++, static macros, etc. What's not maturing as fast: third-party libraries ecosystem because most people just need Apple's, Windows support (because - why?), and alternate IDE's, static analysis, etc. As for 217 keywords, etc.: be glad there's a name for everything, without a plethora of ways to do the same thing. If it weren't easier to do complicated things with a correspondingly complicated language, everyone would be writing functional lisp code. The real problem now is there's no real agreement on how to do the function coloring, effects, traits, etc., but that's what's needed to make use of modern hardware. In particular, the type system being bidirectional has made it both pleasant (when it works) and painful (when it doesn't), and stuffing all this new behavior into a type system constraint solver is a bit of a black art. Venn diagrams and verbiage aside, it's just hard for people to think about, e.g., what ~Copyable means for generic parameters, or how a parameter can place a function in a different memory region. But they'll do it after a boatload of discussion, and then make a dumbed-down happy-path 10-minute video for WWDC with code folks can play with - 10 million folks. If anything, the language is strangled by history, but remains attractive because the team does such a good job.

willtemperley 2y ago

Surely the "some" keyword the author is railing about actually _improves_ composability, and is in fact exactly in line with Lattner's vision "Simple things that compose." The accepted answer here [1] explains this better than I can. I can't share the author's enthusiasm for Swift on server either. WASM support is not production ready so Cloudflare workers or Deno deploy is out. Vapor is the only properly maintained framework I can find (happy to be corrected) which I did not find ergonomic. Google Cloud Functions or AWS Lambda would be options but there's no reason to limit oneself when Rust is production ready on most web platforms. [1] https://stackoverflow.com/questions/56433665/what-is-the-some-keyword-in-swiftui https://stackoverflow.com/questions/56433665/what-is-the-som...

saagarjha 2y ago

This is an insulting piece. It's a poor hitjob by someone who doesn't really know what is going on, which is extra unfortunate because Swift has a bunch of problems. Some of them are actually adjacent to the claims here! But this is just unsubstantiative flamebait. Swift is controlled by Apple, Inc. Nobody worth listening to is denying that. The steering committee is almost all Apple employees, most of the commits going in come from people who commute to Cupertino, and whatever the progress is on Windows or Arduino or whatever, it's clear that "first class" really means iOS. That's all true. Apple makes proposals, they seek some community input, and in the end they pick what they like and it ends up in the language. But even with that said, the rest of this post is of low quality. Tim Cook and his MBA buddies didn't personally come in to ruin the language because the shareholders aren't making money. Chris Lattner is, whatever his contributions to the language previously, just a guy. He would probably try to put Swift on GPUs today if he had his way. It's not the first time he sold it out before. You've got to go beyond "omgz so many keywords so complicated!!1!!" and look deeply at the real sources of complexity. Swift has a powerful generics system that has worst-case behavior that really sucks. The discussion process has a bunch of busybodies that have nothing better to do than talk about names of things. Yes. These are real problems. It's funny when there are random hacks in the source code to support things that Apple is shipping. But that is how a large project works. You are more than welcome to laugh about it on Twitter but substantive criticism it is not. Which is a shame, because there is plenty of it go around.

pjmlp 2y ago
These kind of pieces is what ends up with worshiping stuff like Go with its clunky design evolution, it turns out either the language handles the complexity of the world, or the source code makes it visible in needless boilerplate. Agree on the general tone, only up voted by accident.
kaishin 2y ago
I like how the conclusion of the article paints a very positive picture for the language. It’s as if the entire negative tone of the article was a poor attempt to sound insightful for clicks.

randomNumber7 2y ago

I think Swift is a really nice language when you look at the design. I really liked protocol extensions for example. The problem I have with it is that some decisions are very ideologic. You can easily link to C libraries for example, but the pointer types in Swift are so fucking unusable (because pointers are evil) that it makes no sense to try it. (unless you cannot chose an other language)

zer0x4d 2y ago

Call me a fanboy, but Swift is one of the best languages I've ever had the privilege of using. I'm truly hopeful with some more work, it's able to become the de-facto cross-platform language. The complexity is very manageable, a decent Java, Objective-C or .NET developer can pick it up in less than a day, is feature-packed and stuff just make sense.

willtemperley 2y ago
I also love that we can write high-performance graphics apps without C++ (OK shaders are kind of C++ but that's fine as long as it stays there).

pjmlp 2y ago

It doesn't matter, because Swift is one of those languages that enjoys an overlord, anyone that wants to target its overlord platforms eventually has to deal with Swift. Same with Java and Kotlin on Android, .NET and C++ on Windows, JavaScript on the Web, ISO C on UNIX/POSIX, Go on Docker/Kubernetes,....

kaishin 2y ago

This article is full of statements that are not backed up by any material proof. The author claims that Swift features no longer compose without giving a single example. I write Swift SDKs for a living and I have never thought that any of the recent features felt incompatible, incongruous, or redundant. Sure, each has its strengths and weaknesses, but that results in an expressive language where every problem has several solutions with different tradeoffs. When it comes to governance, it’s not without wrinkles, but it’s not as bad as the author makes it sound. If anything, things got a bit less “dictatorial” since Chris left. Different core team members pull in slightly different directions which made the language more balanced in my view.

jakey_bakey 2y ago

Thanks so much for sharing my work! :) The devs here are a lot more nuanced than the guys on Reddit lol

tayistay 2y ago

If you have a recent machine, the actual developer experience isn't too bad. It's just not a language for language purists (was it ever?). I'm enough of a purist to be annoyed whenever I see the "expression took too long to type check" error. (I think bidirectional type inference isn't worth it with Swift) The gaggle of verbose pointer types makes me want to switch to C++ whenever I have to deal with memory directly. As the article mentions, a bunch of features were added for the sake of SwiftUI. Function builders allow SwiftUI's syntax to be minimal. They allow you to write: VStack { SomeView() AnotherView() } instead of something like VStack( SomeView(), AnotherView() ) Given the rather bad (still!) error messages you get with SwiftUI that seem to be a result of function builders, I'd say it wasn't worth it. At least I get fewer of the "couldn't produce a diagnostic, please file a bug" errors than I used to. Then there are property wrappers, which wrap struct/class fields with get/set code (IIRC Lattner didn't like the property wrappers). They've been partially replaced in SwiftUI by macros. The @Observable macro (probably the most widely used one) decorates your class with code that notifies listeners (almost always SwiftUI) of changes. I'd be curious to see what SwiftUI would look like without property wrappers (or macros). I think they had a missed opportunity to really add robust updating of views in response state changes. Currently it's still relatively easy to not have your SwiftUI views update because your data model uses some object that isn't @Observable. I wrote a UI library inspired by SwiftUI, but in Rust [1], and of course I couldn't add anything to the language, and more experienced Rust programmers discouraged me from using macros. So it can be done without all the extra stuff Swift added. [1] https://github.com/audulus/rui https://github.com/audulus/rui

willtemperley 2y ago
Isn't it by design that only observable or state data update views? Otherwise there would be significant overhead watching everything.

p0w3n3d 2y ago

Paywalled?

Hashex129542 2y ago
Yes, I didn't knew about it. When I was read, there is full article is there without paywall. Seems, after some traffic they showing to subscribe to read the page.