4 ms·

Yes, there are some people who simply prefer Objective-C, but you need to also realize that Swift is still not ready for system-level programming. Analysis tool

Yes, there are some people who simply prefer Objective-C, but you need to also realize that Swift is still not ready for system-level programming. Analysis tools aren’t ready; debugging basically means you go to printing variables to stderr and praying. The standard library defaults to crashing at runtime for simple float <-> integer conversion bounds errors which you’d think would be caught statically with more thoughtful design. Still a lot of rough edges. SwiftUI in particular is excellent and if you can use it you should. But you can’t say Swift in general is ready to replace Objective-C. It’s not.

saagarjha 5y ago
Swift is not ready, but it's not for those reasons. The real problem is that Swift needs a hefty runtime and is fairly slow due to excessive ARC traffic, plus it has no way of recovering from memory exhaustion. So you can't really use it in the kernel, but it's perfectly fine for writing system frameworks and daemons.
- stephencanon 5y ago
  Realistically none of the commonly used systems languages have a mechanism to recover from memory exhaustion. Some pretend to, but if you actually try to use them, yeeeeech The big missing features (from my perspective) are fixed-size arrays, placement allocation, and the ability to guarantee that no allocations or refcount operations occur in a marked critical section. There’s a lot of other stuff I would like to have, but those are the things I can’t live without.
  - saagarjha 5y ago
    Yeah, I agree, I'm just saying that Linus won't use it unless he feels like it gives him that "control" ;)
stephencanon 5y ago
> The standard library defaults to crashing at runtime for simple float <-> integer conversion bounds errors which you’d think would be caught statically with more thoughtful design. There are very real ways in which Swift isn't ready for systems programming, but this sure ain't one of them. - In C and C++, this doesn't trap, it's undefined behavior. Trapping is _always_ better than UB. Are C and C++ "not ready for systems-level programming"? (Yes, but that hasn't stopped people from doing it). - C and C++ compilers don't catch this statically either by default. They just silently invoke UB (https://godbolt.org/z/seTh9cva6 https://godbolt.org/z/seTh9cva6). - Unlike C and C++, Swift's standard library provides the tools you need to easily do something about it: if you don't want to trap, you can write `Int(exactly: x.rounded(.towardZero))` and get an Int? that is nil if a floating-point value is out of range. There are rough edges here, but they are much, much less rough than the languages that people routinely use for systems programming. Sibling poster got at some of the real problems that _do_ need to be addressed.
- saagarjha 5y ago
  One can make the argument that UB allows implementations flexibility on how they define overflow, allowing e.g. -fwrapv and trapping to be permissible based on what your desire is. But it's a fairly weak argument and doesn't detract from the rest of your points.
  - stephencanon 5y ago
    Yeah, I used to think that, but compilers are already allowed to do whatever they want in non-standard modes. Defining the result wouldn’t prevent implementing fwrapv or trapv. (Also note that neither of these applies to float-int conversions, so let’s not pretend that either helps here).

saagarjha 5y ago

Swift is not ready, but it's not for those reasons. The real problem is that Swift needs a hefty runtime and is fairly slow due to excessive ARC traffic, plus it has no way of recovering from memory exhaustion. So you can't really use it in the kernel, but it's perfectly fine for writing system frameworks and daemons.

stephencanon 5y ago
Realistically none of the commonly used systems languages have a mechanism to recover from memory exhaustion. Some pretend to, but if you actually try to use them, yeeeeech The big missing features (from my perspective) are fixed-size arrays, placement allocation, and the ability to guarantee that no allocations or refcount operations occur in a marked critical section. There’s a lot of other stuff I would like to have, but those are the things I can’t live without.
- saagarjha 5y ago
  Yeah, I agree, I'm just saying that Linus won't use it unless he feels like it gives him that "control" ;)

stephencanon 5y ago

> The standard library defaults to crashing at runtime for simple float <-> integer conversion bounds errors which you’d think would be caught statically with more thoughtful design. There are very real ways in which Swift isn't ready for systems programming, but this sure ain't one of them. - In C and C++, this doesn't trap, it's undefined behavior. Trapping is _always_ better than UB. Are C and C++ "not ready for systems-level programming"? (Yes, but that hasn't stopped people from doing it). - C and C++ compilers don't catch this statically either by default. They just silently invoke UB (https://godbolt.org/z/seTh9cva6 https://godbolt.org/z/seTh9cva6). - Unlike C and C++, Swift's standard library provides the tools you need to easily do something about it: if you don't want to trap, you can write `Int(exactly: x.rounded(.towardZero))` and get an Int? that is nil if a floating-point value is out of range. There are rough edges here, but they are much, much less rough than the languages that people routinely use for systems programming. Sibling poster got at some of the real problems that _do_ need to be addressed.

saagarjha 5y ago
One can make the argument that UB allows implementations flexibility on how they define overflow, allowing e.g. -fwrapv and trapping to be permissible based on what your desire is. But it's a fairly weak argument and doesn't detract from the rest of your points.
- stephencanon 5y ago
  Yeah, I used to think that, but compilers are already allowed to do whatever they want in non-standard modes. Defining the result wouldn’t prevent implementing fwrapv or trapv. (Also note that neither of these applies to float-int conversions, so let’s not pretend that either helps here).