3 ms·

Prioritizing expense and risk vs nebulous reward

MBCook 3y ago
It’s not nebulous. There are kinds of bugs that Swift can provably catch that Objective-C can’t. There are bits of safety that Swift can ensure without needing to do additional boundary checks or something else, leading to faster/smaller code. Perhaps biggest of all Swift doesn’t need a runtime like Obj-C. Apple has done an amazing job tuning it, but a direct function call is always going to be faster than message passing.
- bobbylarrybobby 3y ago
  Swift doesn't need a runtime, but if it runs alongside Objective C code, doesn't it? On iOS wouldn't much of what Swift is doing be to calling down into Objective C? In other words, I think that unless you get rid of all of the Objective C in iOS, Swift will still be sitting on top of a runtime.
  - astrange 3y ago
    Swift does need a runtime. The language design is kind of accepting of implementation complexity in a way that interpreted languages often are but compiled languages usually aren't, so there's a lot of implicit heap allocations.
- brailsafe 3y ago
  What is nebulous is the actual return on the investment of time and money, just the same as it would be in any rewrite of any code ever, when the same resources could be allocated differently. The possibility that some hypothetical bugs might be avoided isn't a compelling argument for spending dollars and time on doing the work, if it's measurably doing it's job now.
- Cthulhu_ 3y ago
  While this is true, your arguments are mainly in favor of writing new code in Swift, which I agree with. What you're missing is selling and convincing people of rewriting existing, working code to a different language, which is a nontrivial investment and a decision that shouldn't be taken lightly.
- mpweiher 3y ago
  Nebulous is exactly what it is, because despite what you think: 1. The empirical evidence does not support the notion of fewer bugs, even for static typing, never mind Swift And no, this is not from lack of trying. People have tried to show this time and time again. And time and time again they end up not showing it, with effect sizes tiny and pointing in both directions. And as an anecdotal example: which way has Apple software quality gone since they started adopting Swift and SwiftUI? System Settings anyone? 2. Swift is slow, not fast I did fairly extensive research for on this for chapter 9 of my macOS/iOS Performance book. Even those cases where I fully expected Swift to be faster, which were not numerous, it managed to be slower. And there are really egregiously bad examples, like Swift Coding, which despite the overwhelming evidence to the contrary some people still believe to be fast. Why do they believe it to be fast? Because so much work can be done in the compiler. So it must be fast. But it just is not. In fact, it's ludicrously slow. This is probably lesson #1 from performance optimisation: things are not fast because simply you did something that you believe to be fast. You need to measure to figure out whether they are fast and in order to figure out how to make them fast. (And those mistaken beliefs actually lead to slow code, because you already did the thing that makes it fast, not need to check or optimise. I am pretty confident that a similar effect happens with static typing and safety.) Or check out the computer languages shootout. Swift tends to be somewhat on par with Java. Which is not particularly fast. 3. Swift needs loads of runtime For example, due to the somewhat bizarre idea of having protocols be polymorphic over (pass-by-value) structs and (pass-by-reference) objects, Swift has to dynamically dispatch the copying of individual arguments to a function when protocols are involved. If you're both lucky and not using modular code, the compiler may be able to figure out how to elide that dispatch. But it won't tell you if it managed to figure it out or not. Oh, and speaking from 30+ years of experience: message passing simply is not the bottleneck in 99%+ of the cases, and if it is it is fairly trivial to remove.
  - fingerlocks 3y ago
    Do you have a link to your perf analysis? The only mentions I could find in your profile links were over three years old, and used @objc Codable objects.
- b3morales 3y ago
  > Perhaps biggest of all Swift doesn’t need a runtime like Obj-C Swift most certainly has a runtime: https://github.com/apple/swift/tree/main/stdlib/public/runtime https://github.com/apple/swift/tree/main/stdlib/public/runti... And most or all of it is written in C++, not Swift last I checked. Whenever you see a `_swift_fooBarBaz` symbol in a stack trace, that's the runtime.

It’s not nebulous. There are kinds of bugs that Swift can provably catch that Objective-C can’t. There are bits of safety that Swift can ensure without needing to do additional boundary checks or something else, leading to faster/smaller code. Perhaps biggest of all Swift doesn’t need a runtime like Obj-C. Apple has done an amazing job tuning it, but a direct function call is always going to be faster than message passing.

bobbylarrybobby 3y ago
Swift doesn't need a runtime, but if it runs alongside Objective C code, doesn't it? On iOS wouldn't much of what Swift is doing be to calling down into Objective C? In other words, I think that unless you get rid of all of the Objective C in iOS, Swift will still be sitting on top of a runtime.
- astrange 3y ago
  Swift does need a runtime. The language design is kind of accepting of implementation complexity in a way that interpreted languages often are but compiled languages usually aren't, so there's a lot of implicit heap allocations.
brailsafe 3y ago
What is nebulous is the actual return on the investment of time and money, just the same as it would be in any rewrite of any code ever, when the same resources could be allocated differently. The possibility that some hypothetical bugs might be avoided isn't a compelling argument for spending dollars and time on doing the work, if it's measurably doing it's job now.
Cthulhu_ 3y ago
While this is true, your arguments are mainly in favor of writing new code in Swift, which I agree with. What you're missing is selling and convincing people of rewriting existing, working code to a different language, which is a nontrivial investment and a decision that shouldn't be taken lightly.
mpweiher 3y ago
Nebulous is exactly what it is, because despite what you think: 1. The empirical evidence does not support the notion of fewer bugs, even for static typing, never mind Swift And no, this is not from lack of trying. People have tried to show this time and time again. And time and time again they end up not showing it, with effect sizes tiny and pointing in both directions. And as an anecdotal example: which way has Apple software quality gone since they started adopting Swift and SwiftUI? System Settings anyone? 2. Swift is slow, not fast I did fairly extensive research for on this for chapter 9 of my macOS/iOS Performance book. Even those cases where I fully expected Swift to be faster, which were not numerous, it managed to be slower. And there are really egregiously bad examples, like Swift Coding, which despite the overwhelming evidence to the contrary some people still believe to be fast. Why do they believe it to be fast? Because so much work can be done in the compiler. So it must be fast. But it just is not. In fact, it's ludicrously slow. This is probably lesson #1 from performance optimisation: things are not fast because simply you did something that you believe to be fast. You need to measure to figure out whether they are fast and in order to figure out how to make them fast. (And those mistaken beliefs actually lead to slow code, because you already did the thing that makes it fast, not need to check or optimise. I am pretty confident that a similar effect happens with static typing and safety.) Or check out the computer languages shootout. Swift tends to be somewhat on par with Java. Which is not particularly fast. 3. Swift needs loads of runtime For example, due to the somewhat bizarre idea of having protocols be polymorphic over (pass-by-value) structs and (pass-by-reference) objects, Swift has to dynamically dispatch the copying of individual arguments to a function when protocols are involved. If you're both lucky and not using modular code, the compiler may be able to figure out how to elide that dispatch. But it won't tell you if it managed to figure it out or not. Oh, and speaking from 30+ years of experience: message passing simply is not the bottleneck in 99%+ of the cases, and if it is it is fairly trivial to remove.
- fingerlocks 3y ago
  Do you have a link to your perf analysis? The only mentions I could find in your profile links were over three years old, and used @objc Codable objects.
b3morales 3y ago
> Perhaps biggest of all Swift doesn’t need a runtime like Obj-C Swift most certainly has a runtime: https://github.com/apple/swift/tree/main/stdlib/public/runtime https://github.com/apple/swift/tree/main/stdlib/public/runti... And most or all of it is written in C++, not Swift last I checked. Whenever you see a `_swift_fooBarBaz` symbol in a stack trace, that's the runtime.