3 ms·
Better Mac support would be nice too. Using Swift in a larger code base in Xcode often results in long compile times, auto completion and code syntax highlighti
by monocularvision 10y ago
Better Mac support would be nice too. Using Swift in a larger code base in Xcode often results in long compile times, auto completion and code syntax highlighting failures and other terribleness.
- AsyncAwait 10y agoAgreed! I think part of the problem is that they rely too much on SourceKit, which is a rather indirect and slow way to provide basic features like syntax highlighting and auto completion. These should be built into Xcode itself. As it is now, SourceKit has to do substantial work in a short amount of time which results in frequent crashes. The compeller's error messages could use some improvement too, I don't consider 'BAD_EXEC' to be a descriptive error at all.
- slavapestov 10y ago> I don't consider 'BAD_EXEC' to be a descriptive error at all. Those are bugs, please report them: https://bugs.swift.org https://bugs.swift.org
- umurgdk 10y agoAre you the Slava who wrote Factor programming language? Apple hiring all the good language designers around the world dammit!
- melling 10y agoIsn't it a given that it's on the way? You're complaining about known issues. Apple will obviously improve its Mac tools. What Swift needs is great, and even better, tools for other platforms. Will Apple keep Swift wide open if it Google gives it first class support on Android, for example?
- tarentel 10y agoKnown issues since day one. I agree it's a given these things are on the way but when?
- agmcleod 10y agoMhmm. Really with all those things, i'd give it a serious try for my game development side projects. Currently using html5 for some, libgdx (java) for others.
- jayrhynas 10y agoHopefully the recently announced precompiled bridging headers will help with compile time (for mixed-language products at least): https://swift.org/blog/bridging-pch/ https://swift.org/blog/bridging-pch/