Poll: what do you strongly dislike about Swift?

"What's new in Foundation" from 2021, @ 10:30

1 Like

Type system

  • Swift(c) is non-deterministic: Valid code might not compile because the compiler fails to resolve the types within a given time. (let x = 1 + 2 + 3 + 4 + 5 + 7.0 + 8 fails to compile on some of my machines.)
  • (Lack of) implicit type conversion rules: let d = 7.0; let x = 1 + d works but let i = 1; let d = 7.0; let x = i + d does not. (type(of: 1) == type(of: i) is true)
  • Strings not having Integer subscripts. I understand the reasons but in 99.9% of all use cases, I simply do not care. It does not matter, even. Remember: Iā€™m saying that while using a machine that is too slow to compile a simple addition.
  • Substring should be a subclass of String, ArraySlice a subclass of Array, etc. Itā€™s okay to write Array(x[4..7]) if I want/have to release memory but most of the time I do not care. This should be true: Array(x[1...2])[1] == x[1...2][1]

Direction of Swift

  • Domain Specific Languages. Itā€™s my fear that in a few years, you will have to know several different languages to understand Swift code.
  • New features seem to get released before they are (what I consider) production ready:
    • Concurrency that was not available for Linux/older macOS/iOS.
    • Some Foundation types are not sendable. (Who would want to pass an URL to a task?)
    • Releasing ā€œunfinishedā€ sets a bad example, related frameworks tend to do the same. Looking at your, SwiftUI (even the demo code crashed for one or two years).
  • The same is true for proposal reviews: There have been several second, third, and even forth reviews of a proposal. As I understand it, the proposal review should be at the end of the process, not in the middle. Sure, second reviews can occur but the normal should be that questions have been resolved beforehand.

Bug handling

  • Server side support is poor.
  • Bugs in macOS hold back fixes in Foundation. A bug in macOS/iOS should never prevent a fix in the open source implementation of Foundation.
  • Fixing bugs should be top priority: Currently there are 4333 open issues that are labeled as bug, with only 6179 closed. This means more than 40% of all bugs ever reported for Swift are unresolved.

Forum/Community

  • American discussion culture is expected in the Forum: I have seen moderators saying that someoneā€™s tone was ā€œnot appropriateā€. I (as a German) did not see any problem. In fear of being considered rude, Iā€™ve discarded more comments than I posted (this post lives as a draft for quite a while now - weeks) and it takes a lot of time to rephrase what I post to make somewhat sure my comments are not considered rude.
  • The imbalance in power between community and core team: For example, in the first review of regex literals, counted after improvements, 29 people clearly said they are against /ā€¦/ and 13 said they are in favor of /ā€¦/. Even though more than twice as many were against it than in favor of it, it never felt like the core team truly considered giving up on /ā€¦/.
    This also shows in Xcode 14b1, which seems to set a de-facto decision before the formal review has ended.
    This is related to the previous point: An open ā€œWe do not think that the examples of breaking source matter in practice. We tested it on x million lines of code and found only 1 line that had to be changed. In the light of the deadline for Xcode 14b1, we already decided to go with /ā€¦/, so there is no point in further discussion.ā€ would have helped a lot.
  • End dates in reviews are often ignored. If the review period is extended, this should clearly be communicated. (Again, the regex review as an example: It ended on May 23rd. 48 of 118 posts were added after that date, the latest post is from Jun 11th - 18 days after the 7 day period. One month later, it is still open for comments.)
  • To me it feels like open sourcing Swift is (from the Apple side) considered a requirement, not something they want to do. Itā€™s the open source project where I feel least welcome to contribute.

Closing

All of the above is my point of view. I understand there are good reasons for why it is as it is. I understand that some of the things I mentioned above only exist in my head. I understand that most (or all) of the above can not and therefor will not change. I will read answers but I will not defend my points.

10 Likes

This has come up a few times in the past, but it's worth mentioning again: evolution reviews are not votes. What mattered to the core team, and now matters to the language workgroup, are the merits of the arguments and alternatives that are put forward, not the number of people who argue them. Otherwise popular evolution reviews have frequently changed course entirely on the basis of a single comment pointing out a problem that hadn't been noticed before, and lots of people saying that they don't like something doesn't carry a lot of weight if the reasons they give have already been anticipated in the proposal and discussed.

18 Likes

SE-0361 proposals. I think it against the swift way of coding. I wish it should be rejected :sleepy:

As I mentioned in my previous post, "I don't like this" doesn't carry a lot of weight in an evolution review. If you are really opposed to a proposal, you have to explain why:

  • "I don't think we should do this because it makes the following use site ambiguous to the reader."
  • "This would be incompatible with this other thing that is more important."
  • "There's a more natural way to get the same behavior; we should do ..."

No one can make you do this; it's hard work, and it's fine if you simply want to register your displeasure, but understand that saying "a big no no for me" will not change the course of a review; a detailed concrete objection or superior alternative will.

19 Likes

A bit of OSS lore: Linus Torvalds would often put things in his tree and ask people to test it to make sure it was worth including in a release. Pretty often, these requests would acted on by not nearly enough people. He eventually gave up on that idea, and simply released things that at least seemed to work for him or the subsystem lead, with an eye on the mail stream in case a release really bombed. It was the only way to get good community wide testing done.

I suspect that the same thing happens here: people read the proposal discussion casually, and maybe respond, and maybe don't. Things get serious only when the Team announces that the proposal is official. Then it gets the high scrutiny needed, not before. Multiple rounds is the only way to get things to a stable agreement.

10 Likes

I think my biggest gripe about Swift is that the most useful advances in the language are coupled with OS versions (on Apple platforms). I probably won't be using regexes for a long time because of this. Even the new concurrency stuff is out of reach for what I'm working on right now and I suspect I'll have to add a lot of @unchecked Sendable conformances to quiet the warnings with the newest Xcode betas.

I miss the time Swift had no ABI stability and it was possible to stay on the cutting edge. I'm less active in the forums now and feel disincentivized from reviewing proposals when they appear to depend on a new runtime.

14 Likes

I will give praise to the effort put into back-porting the concurrency stuff. The fact that it covers every ABI-stable version of Apple's platforms was quite impressive.

Still, it's absolutely baffling to me that the OSes can't update these crucial components (the runtime and standard library) on their own. Ubuntu having a better Swift upgrade story than Apple's own platforms is bizarre.

And for the Regex interpreter specifically: I just went over the SE proposals, and I didn't see any that covered the execution strategy in any real detail besides a mention of it in this paragraph. Choosing an execution model that relies on an OS shipped component is very odd, especially given how little parsing regex has to do with an OS. It's not a driver, a GUI framework, or some system daemon with deep integration. It's just a byte code interpreter that goes brrrr. Why can't it be just be statically linked on apps that target older platforms?

10 Likes

commas....
one other annoyance, and this may seem "extremely small potatoes" (so apologies for taking your bandwidth) but i am just a little bit annoyed at all the commas i need to type sometimes...

i understand for args, or array items on a single line, but if it can work in result builders why cant it work in the normal language do without commas when newlines work just fine?

let array = [
  1
  2
  3
]

func doSomething(
   with string: String
   commas: Bool = false
   lessAnnoying: Bool? = true
)
2 Likes

The crashiness of the compiler. I swear, one of these days I'm going to rig up some kind of script to auto-report those "SourceKitService has unexpectedly quit" dialogs (with "All work and no crash makes SourceKitService a dull boy." in the Comments field). Going through a file (which often has to be huge due to the lack of typeprivate), looking for the one tiny error somewhere that's setting it off, all while constantly dismissing crash pop-ups every few seconds, is loads of fun.

This was really obnoxious in early versions of Swift, and got a lot better IIRC somewhere in the middle of the 4.x releases. It is back with a vengeance in 5.6 and 5.7 now, though.

At one point I got frustrated enough to make a video: If Apple WWDC Presenters Used the Same Tools as the Rest of Us (SourceKitService Crash) - YouTube

5 Likes

"Command failed with a nonzero exit code"

Wish the compile gives a little clue where the problem is? At least which file?

10 Likes

Indeed. The trick that I usually use is to comment out the entire file, then uncomment line by line until the crash starts happening. Not the most efficient when the file is large...

3 Likes

THIS. it has gotten awful since 5.5

So I think this thread is a thing I dislike as much of it is more venting that anything else.

If you care about e.g. the compiler not crashing (I do/would), it would bear more weight to actually include (multiple if it happens all the time) links to cases filed. If youā€™ve found an easily reproducible way to crash it, report it. If you donā€™t get good feedback for a failed compilation- did you file a request to improve it? Not directed at anyone in particular, but the collective venting just feels a bit too negativeā€¦

I mean, put half of the energy spent in this thread in constructive feedback/pitches/bug reports/PR:s and reference those instead, and weā€™ll all probably be happier - thereā€™s definitely many things to improve but just venting with little structure is hardly the way to get any traction in doing so.

Just 0.02c

10 Likes

Iā€™m sure you are right in that many of the mentioned issues are ā€˜knownā€™, but the question is by whom sometimes - as I mentioned, if you want to get traction to solve issues, you need to ensure that the right persons get to know it and have it on the radar - in case of defects (e.g. compiler crashes) Iā€™m sure that there is a sincere desire to address any issues that are reported and known, donā€™t you think so?

I know from my experience that my previous company have had product defects that were known by customers and support staff, who would have talked to an engineer directly (who was stressed and thus dismissive), which ended up as ā€˜known design problemsā€™ - when they actually were surfaced to the right people weā€™d promptly fix them instead - happened more than one timeā€¦

When it comes to unactionable issues where you want to avoid similar problems in future designs, a good way would arguably be to bring up those concrete issues during the pitch/review phases of evolution for any similar future features? I guess one could always permalink to some comment in this thread, but seems a bit unstructured. Just saying X is bad (but I donā€™t have any better suggestion) is not too useful.

I definitely donā€™t say that many of the concerns brought up here are invalid, far from it - and a few of them seems frustrating indeed (like compiler crashes without much hints what went wrong) - I just think it is much more pragmatic to try to pour the frustration into actionable things when its possible and try to discuss possible ways to improve things (which some people have done too in this thread).

1 Like

Trying to think of sticking points. Strongly is too strong of a word. Maybe its just me and I'm fos but...

ā€¢ Optionals in a protocol require @objc. Any place where @objc is magically added. This might confuse people who are not from the Objective-C background. My library api was exposed as a protocol. But now every time I add a function, the api user has to add code to conform to the protocol in addition to a build. Would be nice if it were optional.
ā€¢ Can't have a #if inside the array declaration. Maybe its a real big array of stuff and I just wanted one line of it different for a debug build. I guess I need to separate files in my project now.
ā€¢ Memory allocation seems to be a pain. Always seem to be heading for the documentation on that first thing. Can it be easy to use like malloc was?
ā€¢ I really wish I could see that variable in the xcode debugger. I did not strip my symbols. Now I have to start over and add a print statement.
ā€¢ The closure definition has no labels. What arguments are those suppose to be again?

Overall, I enjoy using the language.

2 Likes

Barring ABI concerns, you can provide a default implementation. Logically, this should be possible for any protocol requirement which is optional.

2 Likes

It's great when things are easy, but when it comes to memory management, easy and safe are on opposite sides of the scale. There has been continuing progress on making the Unsafe* family of types easier to use correctly. Perhaps one day you'll find yourself in a happy place.

I don't mean at all to hand-wave away your complaint. I'm just letting you know there is progress being made in this area. No one wants memory management to be needlessly difficult.

3 Likes

UnsafeMutableRawBufferPointer.allocate(count:) and UnsafeMutableBufferPointer.allocate(capacity:) are isomorphic to malloc, so writing Swift can always be "easy to use" like malloc--they are drop-in equivalents, after all. I would suggest that malloc was never that easy to use correctly, and that safe alternatives in Swift are quite a bit better, however.

13 Likes

That's just part of the charm of living on the bleeding edge of development. You've fixed or bypassed all your AutoDiff compiler crashers, only to spend hours investigating another crash that's in another aspect of the compiler. The ratio of unique compiler crashers I've reported to the amount that I've seen fixed is pretty dismal (10:1). This is why you have the privilege of learning SIL, C++, LLVM, and spendings days of your own precious time fixing one compiler crasher impacting your project.

This is obviously sarcastic, but it highlights a possibly underemphasized issue. Could we compare the compiler's crashiness to other languages like Rust and Julia?