[gh123man]

I'd love to hear some specific examples. Ive built several iOS apps and a whole backend (on linux) with Swift and other than lack of OSS library support for some SaaS APIs, it's been quite nice.

Sure Swift itself has some sharp edges, but not any more (or worse) than many other popular languages.

[JackYoustra]

Sure! I love talking about this stuff :) here's a few:

- if you want to manager your Package.swift target, you mostly have to deal with .target enum (can't figure out how to paste the URL)

You can really only do a define or unsafeFlags, which leads to a couple issues...

1) There's only Debug and Release configurations! What if you want more? What if you want a nice flow where you emit and consume pgo data and re-ingest it?

2) What if you want to use a define for another language managed by SPM, such as metal?

3) What if you want to put in a portable path into a linker argument? SPM blocks use of build-time environment variables, so you can't do that either.

All of these things seem contrived, but I ran into all three of them at my current job (shameless NanoFlick plug). All of these can be handled by cmake or xcodebuild (although probably better to use rules_xcodeproj).

- Swift compiler feedback and performance in builders is absolutely atrocious, to the point where binary searching a view to find the actual source of a type error over ~30 second build times isn't very unusual!

- It's very overly conservative with build times, and because there's only module-level import, it's very easy to accidentally have a long dependency chain which makes building one file imply building many files, further tanking your build time. There are some forum posts I can dig up on this if you're curious more on this point.

- POD structs are default-Sendable at module-level visibility, but lose that if they're public, which means if you try modularizing your app into different small packages to restore some notion of compilation units to fight against the above two points, you end up having to go around and mark all of your different classes with default protocols (usually just Sendable) to reimplement!

- Not a huge deal, but no way to have macro_rules! like you can in rust: macros are kinda hard to use and have to be in another package.

This is just my thoughts on tooling, I have many more thoughts about the language itself that I'd be happy to share.

Honestly though it's much better with vscode. I do hope that it makes progress in the right direction, Swift has a lot of things going for it!