3 ms·

Why do you say it is the worst of all worlds? To me it is a very good compromise and about as good a situation as you can get while maintaining C/Objective-C co

Why do you say it is the worst of all worlds? To me it is a very good compromise and about as good a situation as you can get while maintaining C/Objective-C compatibility. Don't forget there are performance benefits to being less dynamic (not using runtime message passing) and you can opt in to that runtime mode if you want by making classes @objc.

lerno 12y ago
Well, in practice the broken generics stop large amounts of reasonable uses of generics, the lack of co/contravariance force you into hideous workarounds everywhere. As for the promised runtime performance improvements they have yet to surface and worse: the language is still plagued by extremely uneven performance, even for optimized builds. I could go on at great length citing issues that will be hard to fix within the next year or so. Unfortunately. This is what my fairly hard won (15k loc of Swift code) experience with the language has revealed so far. I can honestly say I really wish you were right.
- josephlord 12y ago
  I haven't done that volume but I have written a few thousand lines including this branch of a GCD wrapper library which uses generics to allow return values to be passed between the closures running on the different threads in a typesafe way: https://github.com/josephlord/Async.legacy/blob/argumentsAndReturnsTake2/AsyncLegacy.swift https://github.com/josephlord/Async.legacy/blob/argumentsAnd... It was a nightmare getting it all building right (generic methods on generic classes took me a bit of time to sort out) but I think it works well now. As for performance noting the amount of Swift you've done (and your activity on the DevForums) I expect you know all this but I've done quite a bit on speeding someone else's code up. There are certainly plenty of ways to accidentally slow down code: Summary of the optimisations taking someone's project from 10fps to about 1500. http://blog.human-friendly.com/swift-optimisation-number-iosdevuk-swift-300 http://blog.human-friendly.com/swift-optimisation-number-ios... Presentation on how to make Swift go fast: http://blog.human-friendly.com/london-swift-presentation-swifter-swift http://blog.human-friendly.com/london-swift-presentation-swi...
  - lerno 12y ago
    I regard Swift's inconsistent runtime performance and over-reliance on compiler optimizations as a major problem with the current state of the language. It does not help that some slowdowns are due to bugs, and some due to questionable implementation details that require knowledge of how the runtime operates. Of course, knowing about the runtime is necessary for all micro-optimization regardless of language, but Swift currently requires it almost all of the time. The difference between Swift and ObjC/C is glaringly obvious. Your GCD wrapper examples use only the simplest form of generics, with no constraints at all. Magnify the problems you had to get this to work by x10.000 and you get how easy it is to do anything complex with Swift's generics. It's a maze of missing features and bugs. I think it's very understandable that Owens got fed up with it.

lerno 12y ago

Well, in practice the broken generics stop large amounts of reasonable uses of generics, the lack of co/contravariance force you into hideous workarounds everywhere. As for the promised runtime performance improvements they have yet to surface and worse: the language is still plagued by extremely uneven performance, even for optimized builds. I could go on at great length citing issues that will be hard to fix within the next year or so. Unfortunately. This is what my fairly hard won (15k loc of Swift code) experience with the language has revealed so far. I can honestly say I really wish you were right.

josephlord 12y ago
I haven't done that volume but I have written a few thousand lines including this branch of a GCD wrapper library which uses generics to allow return values to be passed between the closures running on the different threads in a typesafe way: https://github.com/josephlord/Async.legacy/blob/argumentsAndReturnsTake2/AsyncLegacy.swift https://github.com/josephlord/Async.legacy/blob/argumentsAnd... It was a nightmare getting it all building right (generic methods on generic classes took me a bit of time to sort out) but I think it works well now. As for performance noting the amount of Swift you've done (and your activity on the DevForums) I expect you know all this but I've done quite a bit on speeding someone else's code up. There are certainly plenty of ways to accidentally slow down code: Summary of the optimisations taking someone's project from 10fps to about 1500. http://blog.human-friendly.com/swift-optimisation-number-iosdevuk-swift-300 http://blog.human-friendly.com/swift-optimisation-number-ios... Presentation on how to make Swift go fast: http://blog.human-friendly.com/london-swift-presentation-swifter-swift http://blog.human-friendly.com/london-swift-presentation-swi...
- lerno 12y ago
  I regard Swift's inconsistent runtime performance and over-reliance on compiler optimizations as a major problem with the current state of the language. It does not help that some slowdowns are due to bugs, and some due to questionable implementation details that require knowledge of how the runtime operates. Of course, knowing about the runtime is necessary for all micro-optimization regardless of language, but Swift currently requires it almost all of the time. The difference between Swift and ObjC/C is glaringly obvious. Your GCD wrapper examples use only the simplest form of generics, with no constraints at all. Magnify the problems you had to get this to work by x10.000 and you get how easy it is to do anything complex with Swift's generics. It's a maze of missing features and bugs. I think it's very understandable that Owens got fed up with it.