4 ms·

Some Apple devs still seem to love C and Obj-C (at least the ones my former employer worked with directly) and hate on Swift. Both Swift and Rust can be written

Some Apple devs still seem to love C and Obj-C (at least the ones my former employer worked with directly) and hate on Swift. Both Swift and Rust can be written to a much higher standard where the language protects you from stupidity, but only if you give up the past and use them. While you can write pretty good C-ish code (i.e. Linux), its far too easy to slip up once and the language does nothing to save your ass. Some of Apple's OS code is pretty ancient. Switching to Swift or Rust is not necessarily a panacea if you call too many OS routines still in C-ish.

raspasov 5y ago
I agree. Swift is a nice language, compared to the alternatives. I have a few months experience in it, and I can definitely agree that if you're writing Swift-only, it's very nice. The emphasis on values, and value semantics is definitely a differentiator from most other languages. However, anytime you have to use/interop with an older API designed for Obj-C (for example, AVFoundation), it's much more of a pain. Effectively, you're writing Obj-C in Swift. If someone is insisting on Obj-C instead of Swift in 2021, I would attribute it to a form of a Stockholm Syndrome. Many people form psychological bonds with whatever they are familiar with.
- setpatchaddress 5y ago
  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).
RavlaAlvar 5y ago
I can totally relate to people who love the simplistic of C, but ObjC? I couldn’t fathom why anyone would prefer this mess to Swift.
- saagarjha 5y ago
  Objective-C is really a fairly simple language. Swift has complexity that approach that of C++.
- andrewcarter 5y ago
  swift is by far an easier language, safer language, and has a lot of power and nice functional bits, but _oh my god_ those compile times and the lack of a stable debugger and refactoring tools can make it miserable to work in. That and ever since swift 4 or so I feel like we're leaning towards the c++ "everything and the kitchen sink" kinda problems when it comes to features. Used to be there were fairly obvious "right" or idiomatic ways of doing things, but now it's gotten a lot more complicated. Property wrappers, combine, all the stuff with opaque types and the insane stuff you can do with protocols and protocol extensions, all the fad architectures and patterns. Most swift codes bases I've worked in are highly over engineered and kinda feel like the developer of the project just learned about X cool thing in swift and wanted to use it everywhere. It's amazing how the crash rate of apps I've worked on in swift are like consistently less than 1%, it's easy to learn, very modern feeling. But gosh some days I'm just longing for some classic objective c spaghetti code that compiles instantly and gives me that great debugger I've come to rely on. Oh and don't get me started on the abysmal auto correct, code completion, and error messages. Swift still has a ways to go IMO, but I do think it's the choice for an iOS app in 2021- just be thoughtful about which language features you use and not going bananas with extensions and protocols.

raspasov 5y ago

I agree. Swift is a nice language, compared to the alternatives. I have a few months experience in it, and I can definitely agree that if you're writing Swift-only, it's very nice. The emphasis on values, and value semantics is definitely a differentiator from most other languages. However, anytime you have to use/interop with an older API designed for Obj-C (for example, AVFoundation), it's much more of a pain. Effectively, you're writing Obj-C in Swift. If someone is insisting on Obj-C instead of Swift in 2021, I would attribute it to a form of a Stockholm Syndrome. Many people form psychological bonds with whatever they are familiar with.

setpatchaddress 5y ago
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).

RavlaAlvar 5y ago

I can totally relate to people who love the simplistic of C, but ObjC? I couldn’t fathom why anyone would prefer this mess to Swift.

saagarjha 5y ago
Objective-C is really a fairly simple language. Swift has complexity that approach that of C++.
andrewcarter 5y ago
swift is by far an easier language, safer language, and has a lot of power and nice functional bits, but _oh my god_ those compile times and the lack of a stable debugger and refactoring tools can make it miserable to work in. That and ever since swift 4 or so I feel like we're leaning towards the c++ "everything and the kitchen sink" kinda problems when it comes to features. Used to be there were fairly obvious "right" or idiomatic ways of doing things, but now it's gotten a lot more complicated. Property wrappers, combine, all the stuff with opaque types and the insane stuff you can do with protocols and protocol extensions, all the fad architectures and patterns. Most swift codes bases I've worked in are highly over engineered and kinda feel like the developer of the project just learned about X cool thing in swift and wanted to use it everywhere. It's amazing how the crash rate of apps I've worked on in swift are like consistently less than 1%, it's easy to learn, very modern feeling. But gosh some days I'm just longing for some classic objective c spaghetti code that compiles instantly and gives me that great debugger I've come to rely on. Oh and don't get me started on the abysmal auto correct, code completion, and error messages. Swift still has a ways to go IMO, but I do think it's the choice for an iOS app in 2021- just be thoughtful about which language features you use and not going bananas with extensions and protocols.