5 ms·

It's been a while since I've used it, but before I made native apps I had a little web development business going, and used Ruby on Rails extensively. I couldn'

by gdubs 6y ago

It's been a while since I've used it, but before I made native apps I had a little web development business going, and used Ruby on Rails extensively. I couldn't articulate the similarities at the time with ObjC, but looking back I'm sure it had a lot to do with my comfort working in Ruby. And, I credit that web work I did in Ruby with my becoming a better programmer. Being able to drop in to low-level C for real-time applications (audio, in my case) was a great aspect of ObjC. Though there were plenty of times I wished I could program in ObjC in the real-time threads. There were many debates on the Core Audio forums about whether ObjC was safe in real-time threads. Most of Core Audio was developed by C++ programmers, and their default was to avoid ObjC out of a fear that a surprise lock or memory allocation would glitch out the audio. There was, however, at least one NeXT veteran on the forums who felt this was nonsense, and recalled writing device drivers in ObjC.

mpweiher 6y ago
> one NeXT veteran on the forums who felt this was nonsense, and recalled writing device drivers in ObjC So did I. https://www.nextop.de/NeXTstep_3.3_Developer_Documentation/OperatingSystem/Part3_DriverKit/Concepts/1_Overview/Overview.htmld/ https://www.nextop.de/NeXTstep_3.3_Developer_Documentation/O... It was quite lovely, and I later heard from Apple kernel devs that moving to C++ from Objective-C was one of their biggest regrets.
- pjmlp 6y ago
  Apparently they did not regret enough, because DriverKit was the opportunity to reboot that decision, and it was decided to still be C++ only.
PaulDavisThe1st 6y ago
It isn't a "fear" - it's avoidance of demonstrated behavior. You cannot use any GC-based language if you want to guarantee an upper bound on latency. You cannot use any language that uses global or even large-scope locks if you want to guarantee an upper bound on latency. It has nothing to do with "writing device drivers" - there are plenty of device drivers for which latency is not anything like the issue that it is for audio.
- 1over137 6y ago
  >You cannot use any GC-based language if you want to guarantee an upper bound on latency ObjC wasn't then and isn't now an GC-based language.
  - jolux 6y ago
    Ignoring the problem with calling something a “GC-based” language, Objective-C is most typically used with ARC these days, which is definitely GC.
    - deleted 6y ago
      [deleted]
    - snuxoll 6y ago
      Reference counting is still not garbage collection. ARC causes the compiler to implicitly insert calls to retain and release, that’s it. Everything is still 100% deterministic at runtime.
      - jolux 6y ago
        It’s not tracing GC, but it’s well-known as a garbage collection algorithm: https://en.wikipedia.org/wiki/Reference_counting#Garbage_collection https://en.wikipedia.org/wiki/Reference_counting#Garbage_col...
      - PaulDavisThe1st 6y ago
        It's not deterministic because you don't know the timing relationship between threads which may drop references. The only sense in which it is deterministic is that "when the reference count reaches zero, the object will be destroyed". That's a long way from the determinism of manual/explicit memory management. It gets even worse if there are per-thread pools in use, though to be fair, this is mostly an application design issue rather than a language one.
      - pcwalton 6y ago
        Reference counting is a form of garbage collection [1]. Any automatic memory management is garbage collection. There is in fact a continuum of memory management strategies between full reference counting on one end and full stop-the-world mark/sweep on the other. Malloc heuristics also mean that it is not true that everything is 100% deterministic at runtime. It's easy to forget that malloc is simply an abstraction like any other. When do free memory blocks get reshuffled between threads in a thread-caching malloc? When does unused memory get returned to the OS? These are all things that cannot be predicted. Even retain and release are not 100% deterministic, as they can and will be optimized away by the compiler. [1]: https://www.memorymanagement.org/glossary/g.html#term-garbage-collection https://www.memorymanagement.org/glossary/g.html#term-garbag...

by gdubs 6y ago

mpweiher 6y ago

> one NeXT veteran on the forums who felt this was nonsense, and recalled writing device drivers in ObjC So did I. https://www.nextop.de/NeXTstep_3.3_Developer_Documentation/OperatingSystem/Part3_DriverKit/Concepts/1_Overview/Overview.htmld/ https://www.nextop.de/NeXTstep_3.3_Developer_Documentation/O... It was quite lovely, and I later heard from Apple kernel devs that moving to C++ from Objective-C was one of their biggest regrets.

pjmlp 6y ago
Apparently they did not regret enough, because DriverKit was the opportunity to reboot that decision, and it was decided to still be C++ only.

PaulDavisThe1st 6y ago

It isn't a "fear" - it's avoidance of demonstrated behavior. You cannot use any GC-based language if you want to guarantee an upper bound on latency. You cannot use any language that uses global or even large-scope locks if you want to guarantee an upper bound on latency. It has nothing to do with "writing device drivers" - there are plenty of device drivers for which latency is not anything like the issue that it is for audio.

1over137 6y ago
>You cannot use any GC-based language if you want to guarantee an upper bound on latency ObjC wasn't then and isn't now an GC-based language.
- jolux 6y ago
  Ignoring the problem with calling something a “GC-based” language, Objective-C is most typically used with ARC these days, which is definitely GC.
  - deleted 6y ago
    [deleted]
  - snuxoll 6y ago
    Reference counting is still not garbage collection. ARC causes the compiler to implicitly insert calls to retain and release, that’s it. Everything is still 100% deterministic at runtime.
    - jolux 6y ago
      It’s not tracing GC, but it’s well-known as a garbage collection algorithm: https://en.wikipedia.org/wiki/Reference_counting#Garbage_collection https://en.wikipedia.org/wiki/Reference_counting#Garbage_col...
    - PaulDavisThe1st 6y ago
      It's not deterministic because you don't know the timing relationship between threads which may drop references. The only sense in which it is deterministic is that "when the reference count reaches zero, the object will be destroyed". That's a long way from the determinism of manual/explicit memory management. It gets even worse if there are per-thread pools in use, though to be fair, this is mostly an application design issue rather than a language one.
    - pcwalton 6y ago
      Reference counting is a form of garbage collection [1]. Any automatic memory management is garbage collection. There is in fact a continuum of memory management strategies between full reference counting on one end and full stop-the-world mark/sweep on the other. Malloc heuristics also mean that it is not true that everything is 100% deterministic at runtime. It's easy to forget that malloc is simply an abstraction like any other. When do free memory blocks get reshuffled between threads in a thread-caching malloc? When does unused memory get returned to the OS? These are all things that cannot be predicted. Even retain and release are not 100% deterministic, as they can and will be optimized away by the compiler. [1]: https://www.memorymanagement.org/glossary/g.html#term-garbage-collection https://www.memorymanagement.org/glossary/g.html#term-garbag...