6 ms·

I'm surprised he doesn't bring up minor features that lead to huge compile time issues, like operator overloading and imports being module sized vs file or fold

by novok 5y ago

I'm surprised he doesn't bring up minor features that lead to huge compile time issues, like operator overloading and imports being module sized vs file or folder wide and type inference in some cases. Not to mention how the language doesn't actually scale that well with core count vs. many, many other programming languages. Throwing 64 cores / 128 threads at a C++ code base speeds up builds in a linear fashion during the compile step, in swift it does not and it tends to effectively max out at around 8 to 16-ish build threads. Even with 3 view toy apps made with SwiftUI on a M1 macbook is slow to build & run relative to it's size! Honestly you would have gotten %80-%90 of the benefits of swift by making Obj-C use a new syntax that looked like swift and continued to improve Obj-C as a language than what you would have gotten with swift. A lot of the ugly of obj-c could have been translated away with very simple 1:1 syntactic sugar macros. And you would actually have fast, responsive compile and indexing times, unlike swift.

jshier 5y ago
The main point of Swift was to create a memory-safe language Apple could use across its OSes. Trying to change Obj-C's syntax doesn't help with that goal.
- zozbot234 5y ago
  Swift does not provide memory safety for concurrent code. It has comparable pitfalls to Go. (You can use Thread Sanitizer to try and diagnose these issues, but that's best-effort and runtime-only; it does not make your code totally safe.)
  - azakai 5y ago
    That is true, but the great majority of memory safety issues are not concurrent ones. In practice Swift and Go are huge improvements over C, C++, and Objective-C in terms of memory safety. I'd also say they are in a reasonable space in the state of the art of safety in general. While they do not make concurrency safe and Rust does, in Rust you need to use unsafe to write things like doubly-linked lists and graphs (or resort to things like indexes-in-an-array), which you can do safely in Swift and Go. So there are interesting tradeoffs all around - our industry has not found a perfect solution here yet.
    - novok 5y ago
      If I had Go's build speed in Swift, I wouldn't have minded a clean break language like Swift.
    - saagarjha 5y ago
      In my experience post-ARC almost all memory safety issues are thread-safety related.
      - pjmlp 5y ago
        Except ARC only works for Cocoa like classes, everything else is traditional C like memory management.
        saagarjha 5y ago
        Yes, but most of the time you’re not using that in your Objective-C code.
  - dddddddan 5y ago
    It does now with actor based concurrency
  - jarpadat 5y ago
    Concurrent memory safety is definitely a goal. Try the new ‘-warn-concurrency’ flag to see what I mean, it is comparable to rust and quite different than thread sanitizer. There’s also a new runtime sanitizer this year with swift intrinsics, not best effort like tsan was. That said. Swift is in the tough position of trying to be a lot of things at once to users with competing needs. Applications, systems, performance, education, prototyping, etc. While there’s broad agreement concurrency safety is important, not everybody thinks it is important enough to bury your working build under a thousand errors (though that view is represented) Ultimately swift’s philosophy is that safety is practice and not theory. Some people do turn on ‘-warn-concurrency’ and fix their errors, others would want to ignore them and find some escape hatch to squash them which doesn’t appreciably improve safety, still others might not upgrade if that was required and maybe the ecosystem as a whole becomes less safe for it. Swift feels responsible for these kinds of outcomes. It’s a tough problem but it does lead to interesting ideas that make safety more practical and productive. Remains to be seen how much of both worlds you can have, but swift/clang/llvm have a long history of doing stuff like that better than you expect.
- novok 5y ago
  What do you mean specifically about memory safety? A clean break new-syntax Objective C could have dropped the C part of ObjC, added strict nullability, dropped header files, add non ABI breaking features like enum ADTs and a bunch of other tweaks and still kept most of the same language compiler code without all the downsides of swift. Swift became a silver bullet homer car as far as languages go.
  - azakai 5y ago
    That would not have helped with use-after-free, though, which Swift does solve.
    - saagarjha 5y ago
      That's solved by ARC, not Swift.
      - azakai 5y ago
        Oh right, good point. Other types of memory safety are more relevant here then.
      - mpweiher 5y ago
        It was really solved by reference counting, way back when Foundation was introduced. The ARC increment was tiny.
        pjmlp 5y ago
        For Cocoa like classes, it did not solve anything else for the rest.
        mpweiher 5y ago
        My stack-allocated integers don't need it.
        5y ago
tialaramex 5y ago
C++ pays an extraordinary price for the fully parallel builds, concealed in the "One Definition Rule". The price is, if you violate the ODR the standard says your program is not valid C++ (and thus has no defined meaning) but there is no requirement for a diagnostic (ie a compile or link error) and the build might complete. This has sometimes been described as "False positives for the question is this a program?" and is a pretty serious penalty to pay for the benefit of improved compile time.
- novok 5y ago
  Could you have ODR and proper warnings / errors handling the issue when it pops up without much penalty?
  - tialaramex 5y ago
    No. ODR allows the compile step to be embarrassingly parallel. Since all the separate definitions of X are, by fiat, identical we needn't detect inconsistency at all and so there's no interaction, it's like merge sorting the files, you can spin up as many threads or processes as you like and process more source files. If we decide "Oh, but I do want to detect inconsistencies, my users would want me to warn them about that" then we can't have the parallelization because we need to rendezvous constantly to verify the definitions are consistent. There are a bunch of tricks that people do today to get some semblance of ODR checking for not too high a cost, and to avoid some ODR pitfalls that might defeat the checks they have. C++ programmers have accepted this danger, if you don't like it then C++ isn't the language for you.
- germandiago 5y ago
  Modules mitigate in a big measure ODR violations. It will be quite more difficult. Compile times will also be better, at least incremental ones.
slavapestov 5y ago
> Honestly you would have gotten %80-%90 of the benefits of swift by making Obj-C use a new syntax that looked like swift and continued to improve Obj-C as a language than what you would have gotten with swift. A lot of the ugly of obj-c could have been translated away with very simple 1:1 syntactic sugar macros. This is a common talking point I hear in the Objective-C community, but nobody has come up with a credible design or implementation of "incrementally evolve Objective-C and drop the C part" beyond stating that it's trivial, etc.
- Apocryphon 5y ago
  Hypothetical designs are bandied about all the time https://medium.com/@mattmass/the-alternative-reality-of-objective-c-5-0-f3e6c8139a39 https://medium.com/@mattmass/the-alternative-reality-of-obje... https://twitter.com/tolmasky/status/1401972686037913601 https://twitter.com/tolmasky/status/1401972686037913601 https://mjtsai.com/blog/2014/10/14/hypothetical-objective-c-3-0/ https://mjtsai.com/blog/2014/10/14/hypothetical-objective-c-... https://web.archive.org/web/20141224114850/https://swiftopinions.wordpress.com/2014/10/12/an-objc-3-0-what-if/ https://web.archive.org/web/20141224114850/https://swiftopin...
  - slavapestov 5y ago
    “Hypothetical” being the key word here, though. These proposals are all thin on details, and if it was so easy someone would’ve made such a language by now.
    - novok 5y ago
      That's a bit bad faith, making a language is never easy and takes a ton of resources. Swift is the bandwagon at Apple due to how Chris Latner started the project and his clout and I think it would be politically untenable to make ObjectiveSwift going against that, especially now at Apple. Nobody else but apple would make ObjectiveSwift too, because for better or worst ObjC & Swift are languages that are for the apple platform and nothing else. If you don't need to make something for apple, and you're going to do it without major tech company sponsorship, then you have freedom and you go make things like Rust, Nim or Elm instead. With all of Swift's problems, I would never recommend it for a server side platform, and it's adoption shows that reality. Because of all of the above, you'll only see hypothetical proposals, no implementations.
johnthuss 5y ago
This is a whole series of articles, and he does address type overloading in one of them, which is maybe what you're looking for. https://belkadan.com/blog/2021/08/Swift-Regret-Type-based-Overloading/?tag=swift-regrets https://belkadan.com/blog/2021/08/Swift-Regret-Type-based-Ov...

by novok 5y ago

jshier 5y ago

The main point of Swift was to create a memory-safe language Apple could use across its OSes. Trying to change Obj-C's syntax doesn't help with that goal.

zozbot234 5y ago
Swift does not provide memory safety for concurrent code. It has comparable pitfalls to Go. (You can use Thread Sanitizer to try and diagnose these issues, but that's best-effort and runtime-only; it does not make your code totally safe.)
- azakai 5y ago
  That is true, but the great majority of memory safety issues are not concurrent ones. In practice Swift and Go are huge improvements over C, C++, and Objective-C in terms of memory safety. I'd also say they are in a reasonable space in the state of the art of safety in general. While they do not make concurrency safe and Rust does, in Rust you need to use unsafe to write things like doubly-linked lists and graphs (or resort to things like indexes-in-an-array), which you can do safely in Swift and Go. So there are interesting tradeoffs all around - our industry has not found a perfect solution here yet.
  - novok 5y ago
    If I had Go's build speed in Swift, I wouldn't have minded a clean break language like Swift.
  - saagarjha 5y ago
    In my experience post-ARC almost all memory safety issues are thread-safety related.
    - pjmlp 5y ago
      Except ARC only works for Cocoa like classes, everything else is traditional C like memory management.
      - saagarjha 5y ago
        Yes, but most of the time you’re not using that in your Objective-C code.
- dddddddan 5y ago
  It does now with actor based concurrency
- jarpadat 5y ago
  Concurrent memory safety is definitely a goal. Try the new ‘-warn-concurrency’ flag to see what I mean, it is comparable to rust and quite different than thread sanitizer. There’s also a new runtime sanitizer this year with swift intrinsics, not best effort like tsan was. That said. Swift is in the tough position of trying to be a lot of things at once to users with competing needs. Applications, systems, performance, education, prototyping, etc. While there’s broad agreement concurrency safety is important, not everybody thinks it is important enough to bury your working build under a thousand errors (though that view is represented) Ultimately swift’s philosophy is that safety is practice and not theory. Some people do turn on ‘-warn-concurrency’ and fix their errors, others would want to ignore them and find some escape hatch to squash them which doesn’t appreciably improve safety, still others might not upgrade if that was required and maybe the ecosystem as a whole becomes less safe for it. Swift feels responsible for these kinds of outcomes. It’s a tough problem but it does lead to interesting ideas that make safety more practical and productive. Remains to be seen how much of both worlds you can have, but swift/clang/llvm have a long history of doing stuff like that better than you expect.
novok 5y ago
What do you mean specifically about memory safety? A clean break new-syntax Objective C could have dropped the C part of ObjC, added strict nullability, dropped header files, add non ABI breaking features like enum ADTs and a bunch of other tweaks and still kept most of the same language compiler code without all the downsides of swift. Swift became a silver bullet homer car as far as languages go.
- azakai 5y ago
  That would not have helped with use-after-free, though, which Swift does solve.
  - saagarjha 5y ago
    That's solved by ARC, not Swift.
    - azakai 5y ago
      Oh right, good point. Other types of memory safety are more relevant here then.
    - mpweiher 5y ago
      It was really solved by reference counting, way back when Foundation was introduced. The ARC increment was tiny.
      - pjmlp 5y ago
        For Cocoa like classes, it did not solve anything else for the rest.
        mpweiher 5y ago
        My stack-allocated integers don't need it.
        5y ago

tialaramex 5y ago

C++ pays an extraordinary price for the fully parallel builds, concealed in the "One Definition Rule". The price is, if you violate the ODR the standard says your program is not valid C++ (and thus has no defined meaning) but there is no requirement for a diagnostic (ie a compile or link error) and the build might complete. This has sometimes been described as "False positives for the question is this a program?" and is a pretty serious penalty to pay for the benefit of improved compile time.

novok 5y ago
Could you have ODR and proper warnings / errors handling the issue when it pops up without much penalty?
- tialaramex 5y ago
  No. ODR allows the compile step to be embarrassingly parallel. Since all the separate definitions of X are, by fiat, identical we needn't detect inconsistency at all and so there's no interaction, it's like merge sorting the files, you can spin up as many threads or processes as you like and process more source files. If we decide "Oh, but I do want to detect inconsistencies, my users would want me to warn them about that" then we can't have the parallelization because we need to rendezvous constantly to verify the definitions are consistent. There are a bunch of tricks that people do today to get some semblance of ODR checking for not too high a cost, and to avoid some ODR pitfalls that might defeat the checks they have. C++ programmers have accepted this danger, if you don't like it then C++ isn't the language for you.
germandiago 5y ago
Modules mitigate in a big measure ODR violations. It will be quite more difficult. Compile times will also be better, at least incremental ones.

slavapestov 5y ago

> Honestly you would have gotten %80-%90 of the benefits of swift by making Obj-C use a new syntax that looked like swift and continued to improve Obj-C as a language than what you would have gotten with swift. A lot of the ugly of obj-c could have been translated away with very simple 1:1 syntactic sugar macros. This is a common talking point I hear in the Objective-C community, but nobody has come up with a credible design or implementation of "incrementally evolve Objective-C and drop the C part" beyond stating that it's trivial, etc.

Apocryphon 5y ago
Hypothetical designs are bandied about all the time https://medium.com/@mattmass/the-alternative-reality-of-objective-c-5-0-f3e6c8139a39 https://medium.com/@mattmass/the-alternative-reality-of-obje... https://twitter.com/tolmasky/status/1401972686037913601 https://twitter.com/tolmasky/status/1401972686037913601 https://mjtsai.com/blog/2014/10/14/hypothetical-objective-c-3-0/ https://mjtsai.com/blog/2014/10/14/hypothetical-objective-c-... https://web.archive.org/web/20141224114850/https://swiftopinions.wordpress.com/2014/10/12/an-objc-3-0-what-if/ https://web.archive.org/web/20141224114850/https://swiftopin...
- slavapestov 5y ago
  “Hypothetical” being the key word here, though. These proposals are all thin on details, and if it was so easy someone would’ve made such a language by now.
  - novok 5y ago
    That's a bit bad faith, making a language is never easy and takes a ton of resources. Swift is the bandwagon at Apple due to how Chris Latner started the project and his clout and I think it would be politically untenable to make ObjectiveSwift going against that, especially now at Apple. Nobody else but apple would make ObjectiveSwift too, because for better or worst ObjC & Swift are languages that are for the apple platform and nothing else. If you don't need to make something for apple, and you're going to do it without major tech company sponsorship, then you have freedom and you go make things like Rust, Nim or Elm instead. With all of Swift's problems, I would never recommend it for a server side platform, and it's adoption shows that reality. Because of all of the above, you'll only see hypothetical proposals, no implementations.

johnthuss 5y ago

This is a whole series of articles, and he does address type overloading in one of them, which is maybe what you're looking for. https://belkadan.com/blog/2021/08/Swift-Regret-Type-based-Overloading/?tag=swift-regrets https://belkadan.com/blog/2021/08/Swift-Regret-Type-based-Ov...