it would be surprising if people who do not use swift frequently were complaining about the developer experience, you have to use a technology a lot to be able to identify issues with that technology.
but i agree with the sentiments of this thread. i would add that life is not particularly great in the linux/vscode world either, because i imagine many of these issues are not XCode issues, but upstream sourcekit-lsp issues, or even compiler issues.
my personal wishlist:
symbolicated crash dumps on linux. for many years, we have not even been able to symbolicate crash dumps on linux without adding 3rd party dependencies or having the python script on hand.
debugging SPM targets that use custom build flags. this is really difficult right now, because it requires fiddling with global settings; it is not associated with a particular package manifest.
"find all references" that reports an error when the SKLSP index has not been built yet, instead of falsely returning "no references".
SKLSP indexing that can invalidate its cache when files are deleted or renamed, instead of forwarding you to filepaths that do not exist.
code completion that doesn’t unconditionally prepend the module namespace to every symbol. aside from being annoying, this generates invalid code when you have a module that contains a type of the same name.
I actually feel like the general tone of these forums is fairly negative. I've certainly noticed that my posts here tend to be harsher than my actual feelings on the language because outside of pitches and proposals that need a +1 there's rarely a reason to post about the good things, and instead I find myself only posting about the things I don't like. I assume that's true as well for the other people who seem to only ever post complaints.
yes, that is my assessment as well. on the other hand, i was only drawn to comment on this thread because i myself am also currently resorting to debugging with print statements, on VSCode, because something is wrong with reflection on the 5.8 toolchain branch.
To be sure: I absolutely love Swift. I'm just aggravated at Apple’s (and yes, it's really Apple who's responsible for all of this) apparent inability or disdain for the tools and developers that have helped make it so obscenely wealthy. I pay $99/yr (for many years) and sell paid apps in the app store. I write Feedback on a weekly basis. From my perspective, Apple has no excuse for the state of these tools.
Metrowerks CodeWarrior worked so much better than Xcode. I've seen tools on Windows work even better than that. I've seen code editors that were far superior at code completion, able to work in spite of syntax errors and incomplete expressions (even perfectly compiled Swift code rarely has perfect code completion). It just boggles my mind how bad it is.
And yes, Apple needs to have more engineers just fixing issues, rather than working on new features. I do appreciate the improvements in Swift (and SwiftUI), but I don't think Apple has made good decisions with the constant re-skinning of the macOS and iOS UIs.
I don't think it's that remarkable. I think many people agree with your sentiment and it's the undercurrent felt in the community outside of some of the hyper positive influencers—they spent years shoveling feature after feature on top of the core language, before spending the time to ensure the tools for the core language were widely stable and performant. What we have now is a kitchen-sink language with every imaginable feature (and more coming!) that still suffers from major tooling and stability issues.
It feels very much like a move fast (at adding features) and break things (like performant and stable code editing, compiling, and debugging) kind of mentality. If you were around for Swift 1-3 it felt even more-so that way back then. And personally, that's not how I want a programming language to evolve and has been a major turn off for me.
It's almost as if there's a broken underlying socioeconomic system, that we should be collaborating on fixing, which otherwise will be surreptitiously built into "Swift evolution", any mention of which is missing from the mission statement of the language.
Yes, It‘s really a pity. I grew accustomed to the fact that the cross platform story woes and that swift-corelibs-foundation violates its mission statement without much resistance, but that the stability of the tools on the PRIMARY platform is so bad is astounding to me. Especially given where we come from. The state of the union 10 years ago was in many aspects much better. And that‘s not just sad for Swift, the language, and its developers, it will inevitably have an impact on the whole ecosystem, if the ones in power can not be convinced to change directions.
Yeah, these are always fun. You can see some bit of tooling working properly (memory gauge, local variable list, etc) but when you try to interact with a slightly different bit of tooling it doesn't work at all. I assume you didn't have any other documents open in Instruments?
Yes, nothing else open in Instruments. And this time the usual dance of restarting all things, erasing DerivedData, etc. didn't fix the memory graph debugger either.
Working on a SwiftUI/SwiftData project in Xcode 15b1 on Ventura, targeting the simulator, Xcode still can't reliably display variable values. In this case, it can only see one of four properties of my view when stopped in init() or one of the methods. I filed FB12370603 with Apple.
Just want to say that the debugger is broken and my experience is the worst.
In order to turn this into something actionable, would you mind clarifying what "is broken" means in the context of your project? For example, what exactly doesn't work, what's the output of swift-healthcheck in LLDB, ... — the more details you can include, the better. If you can share a project that reproduces the problem, that would be ideal.
If you aren't comfortable with sharing details about your project on the forum you could also submit a feedback.apple.com since it sounds like you are using Swift on an Apple platform.
What's the status here? LLDB has been broken for for well over a year. Does Apple not know about this?
For example:
(lldb) p daysRemaining
error: expression failed to parse:
error: <EXPR>:3:1: error: cannot find 'daysRemaining' in scope
daysRemaining
^~~~~~~~~~~~~
frame v indicates the implicit self variable doesn't exist which obviously breaks printing of all variables. The function parameters do print however so indeed self is to be blame.
(App.Subscription) self = <no location, value may have been optimized out>
Did you build in release mode? lldb prints a disclaimer whenever it detects an optimized build that such builds are usually incompatible with commands like frame var, regardless of original source language.
Wait, doesn’t that mean this is behaving correctly? If the ABI doesn’t pass self to a function, the debugger has no means of accessing self’s properties while stopped within that function.
If the ABI does pass self, then the compiler should emit code to stash self and the appropriate debug info to retrieve it. If you have a case where that doesn’t happen, that’s worth a GitHub issue.
