41–50 of 71 posts
Interesting to hear that IBM helped improve the release on Linux, thanks. I may consider it for a project in the future.
https://developer.ibm.com/swift/
I like Swift but I hate the Xcode and the Apple tools. Is so painful to code with it. Apple needs to change its entire development flow. Even working with the react-native I need to use Xcode. =l
Why do you feel it's painful? I've only written a tiny desktop menu bar app with it, but I liked the clean look of it and it didn't feel so cramped like Visual Studio. Maybe I just don't have written with it enough.
SourceKit should help XCode to reason about Swift code but somehow XCode gets lost at least once or twice a day on my machine (MBP 15" i7, 16GB RAM).
Android development tools used to suck but since Android Studio 2.0 and the rise of Swift, it is now iOS dev tools that are lagging behind.
I like Swift but I hate the Xcode and the Apple tools. Is so painful to code with it. Apple needs to change its entire development flow. Even working with the react-native I need to use Xcode. =l
Why do you feel it's painful? I've only written a tiny desktop menu bar app with it, but I liked the clean look of it and it didn't feel so cramped like Visual Studio. Maybe I just don't have written with it enough.
It's incredibly slow, it has always been riddled with bugs, it has crashed on me more often than any other software, and it is lacking so much functionality that it doesn't deserve to be called an IDE at all.
For instance, it can't even rename a Swift function years after Swift's introduction.
Used objc a bit; never used swift. Question about this signature: func drop(while predicate: (Self.Iterator.Element) throws -> Bool) rethrows -> Self.SubSequence I take it the "throws" on the type of predicate means it can 'throw/return' an error. Why would you do this? Why not just require your predicate function to be able to process any element? Or I am confused? It seems like the equivalent in Go, for example, wo…
Because the predicate would then have to swallow any exceptions thrown downstream. What would it return in that case? True or false?
Earlier quoted context omitted.
Imho, Swift Compiler crashes are the single most worrying things for the swift language future, because it casts shadows over the unit tests, and thus make people doubt the reliability of the whole project.
Unit testing a compiler for a language like Swift is hard because there are so many features that interact in complex ways. There are unit tests but it's easy to miss things that look "obvious" in hindsight. Until recently the focus was on finishing the design of the language itself and not fixing bugs or improving compile time. Now that the language is source stable the focus is shifting to the latter two tasks. Als…
Earlier quoted context omitted.
There are neither source releases, nor tags in git repository yet (except the 'swift' repository).
You can download a 3.1 development snapshot. I'm not involved in preparing the official releases but I'm assuming the Linux 3.1 release will be very close to what is in swift-3.1-branch now. And all the action these days is on the master branch so if you're on Linux and want to help us squash regressions you should periodically test your codebase with master snapshots.
It would be great, if there was a tag+source tarball for each release. I'm sure internally there must be something, your colleagues certainly must know, to which commit 'Apple Swift version 3.1 (swiftlang-802.0.48 clang-802.0.38)' maps to.
Earlier quoted context omitted.
Why do you feel it's painful? I've only written a tiny desktop menu bar app with it, but I liked the clean look of it and it didn't feel so cramped like Visual Studio. Maybe I just don't have written with it enough.
If you work with a large-ish ObjC+Swift project, XCode is quite painful. I regularly lose syntax coloring. Compile errors get stuck and don't disappear when the code is fixed. Refactoring Swift code is non existent. Importing images in the project locks the entire UI thread. Storyboards that are more then a couple of screens take ages to open and edit. SourceKit should help XCode to reason about Swift code but someho…
Yep. Happens to me all the time too. Make some changes to code, then wait half a second of the syntax coloring to take effect.
How this is not instant boggles the mind. Maybe it's related to SourceKitService which randomly decides start taking up 100% CPU for no discernible reason.
I am waiting for a swift->js compiler and a new explosion of hipster wave of how it is the greatest thing ever, even better than the last weeks hot tech.
Earlier quoted context omitted.
If you work with a large-ish ObjC+Swift project, XCode is quite painful. I regularly lose syntax coloring. Compile errors get stuck and don't disappear when the code is fixed. Refactoring Swift code is non existent. Importing images in the project locks the entire UI thread. Storyboards that are more then a couple of screens take ages to open and edit. SourceKit should help XCode to reason about Swift code but someho…
> I regularly lose syntax coloring. Yep. Happens to me all the time too. Make some changes to code, then wait half a second of the syntax coloring to take effect. How this is not instant boggles the mind. Maybe it's related to SourceKitService which randomly decides start taking up 100% CPU for no discernible reason.