4 ms·

IMO this is huge. Thankfully, Apple is starting to hire Rust developers as well as AWS. The tide is changing, one day we will see some Rust code in iOS/macOS

IMO this is huge. Thankfully, Apple is starting to hire Rust developers as well as AWS. The tide is changing, one day we will see some Rust code in iOS/macOS so that these issues are a thing of the past.

zepto 6y ago
It seems unlikely that they’ll solve the problems in iOS with Rust. It seems much more likely that they will use Swift in some form.
- KMag 6y ago
  Swift seems an unlikely choice for incrementally replacing portions of kernel code.
  - zepto 6y ago
    In its current form perhaps this is true. However Chris Lattner and others have expressed the desire to have it be suitable for systems programming. There is reason to believe they will adapt it.
    - KMag 6y ago
      Has Chris specifically mentioned OS kernel programming? As the Golang team have pointed out, there's lots of systems programming going on in userspace, which is what they refer to when they call Golang a systems programming language. That being said, ARC is probably easier to get to work well in-kernel vs. tracing garbage collection. There's a performance cost to all of those reference count updates, but at least the variance is extremely low.
  - pjmlp 6y ago
    Apple clearly states Swift is a systems programming language. > Swift is a successor to both the C and Objective-C languages. https://developer.apple.com/swift https://developer.apple.com/swift > Swift is intended as a replacement for C-based languages (C, C++, and Objective-C). https://swift.org/about/ https://swift.org/about/
    - KMag 6y ago
      There are systems languages and then there are systems languages. As the Golang team have pointed out, there's lots of systems programming going on outside of OS kernels. Neither of those links mention kernel development. Pervasive refcount updates (ARC) and a vtable-unfriendly dynamic dispatch mechanism inherited from Objective-C are fine for userspace, but most kernel code is very performance-sensitive.
      - pjmlp 6y ago
        Go team only changed their message due to the pitch forks they were getting from the UNIX/C crowd. There are people that believe systems programming languages in an OS kernel is doable with some form of GC, and then there those that will never change their mind. https://www.f-secure.com/en/consulting/foundry/usb-armory https://www.f-secure.com/en/consulting/foundry/usb-armory https://blog.arduino.cc/2019/08/23/tinygo-on-arduino/ https://blog.arduino.cc/2019/08/23/tinygo-on-arduino/ https://gvisor.dev/ https://gvisor.dev/ https://github.com/mit-pdos/biscuit https://github.com/mit-pdos/biscuit https://github.com/ycoroneos/G.E.R.T https://github.com/ycoroneos/G.E.R.T By the way, NeXTSTEP drivers were written in Objective-C, and the new userspace framework, DriverKit, is an homage to the NeXTSTEP driver API. https://www.nextop.de/NeXTstep_3.3_Developer_Documentation/OperatingSystem/Part3_DriverKit/Concepts/1_Overview/Overview.htmld/index.html https://www.nextop.de/NeXTstep_3.3_Developer_Documentation/O...
        KMag 6y ago
        I'm familiar with Biscuit and Midori. The Biscuit paper estimates a 10% performance hit in syscall-intensive benchmarks due to using Golang vs. C. That being said, ARC may faire much better than a tracing GC, particularly in latency variance, throughput variance, and mean heap usage. Though, I think we're best off moving off of hypervisors and onto 4th generation microkernels with isolation similar to AIX LPARs / Solaris Containers. After all, a hypervisor is essentially a microkernel that's forced to use hardware traps/faults plus hardware emulation for its syscall interface (plus upcalls for performance, which use a calling convention much closer to traditional syscalls). There are stability, security, and performance advantages to throwing out all of that hardware emulation code, moving everything to upcalls, and getting rid of the second (guest OS) kernel running between the application and the hardware. If you push most of the system functionality out of kernel space, then rewriting some of the less performance-critical components in a language with ARC or tracing GC starts to make more sense.
blub 6y ago
By the time we all retire in a few decades they'll be a thing of the past, probably. There's so much low-hanging fruit to pick in that code and switching to Rust is like saying that we should go to Mars to pick fruit instead.

zepto 6y ago

It seems unlikely that they’ll solve the problems in iOS with Rust. It seems much more likely that they will use Swift in some form.

KMag 6y ago
Swift seems an unlikely choice for incrementally replacing portions of kernel code.
- zepto 6y ago
  In its current form perhaps this is true. However Chris Lattner and others have expressed the desire to have it be suitable for systems programming. There is reason to believe they will adapt it.
  - KMag 6y ago
    Has Chris specifically mentioned OS kernel programming? As the Golang team have pointed out, there's lots of systems programming going on in userspace, which is what they refer to when they call Golang a systems programming language. That being said, ARC is probably easier to get to work well in-kernel vs. tracing garbage collection. There's a performance cost to all of those reference count updates, but at least the variance is extremely low.
- pjmlp 6y ago
  Apple clearly states Swift is a systems programming language. > Swift is a successor to both the C and Objective-C languages. https://developer.apple.com/swift https://developer.apple.com/swift > Swift is intended as a replacement for C-based languages (C, C++, and Objective-C). https://swift.org/about/ https://swift.org/about/
  - KMag 6y ago
    There are systems languages and then there are systems languages. As the Golang team have pointed out, there's lots of systems programming going on outside of OS kernels. Neither of those links mention kernel development. Pervasive refcount updates (ARC) and a vtable-unfriendly dynamic dispatch mechanism inherited from Objective-C are fine for userspace, but most kernel code is very performance-sensitive.
    - pjmlp 6y ago
      Go team only changed their message due to the pitch forks they were getting from the UNIX/C crowd. There are people that believe systems programming languages in an OS kernel is doable with some form of GC, and then there those that will never change their mind. https://www.f-secure.com/en/consulting/foundry/usb-armory https://www.f-secure.com/en/consulting/foundry/usb-armory https://blog.arduino.cc/2019/08/23/tinygo-on-arduino/ https://blog.arduino.cc/2019/08/23/tinygo-on-arduino/ https://gvisor.dev/ https://gvisor.dev/ https://github.com/mit-pdos/biscuit https://github.com/mit-pdos/biscuit https://github.com/ycoroneos/G.E.R.T https://github.com/ycoroneos/G.E.R.T By the way, NeXTSTEP drivers were written in Objective-C, and the new userspace framework, DriverKit, is an homage to the NeXTSTEP driver API. https://www.nextop.de/NeXTstep_3.3_Developer_Documentation/OperatingSystem/Part3_DriverKit/Concepts/1_Overview/Overview.htmld/index.html https://www.nextop.de/NeXTstep_3.3_Developer_Documentation/O...
      - KMag 6y ago
        I'm familiar with Biscuit and Midori. The Biscuit paper estimates a 10% performance hit in syscall-intensive benchmarks due to using Golang vs. C. That being said, ARC may faire much better than a tracing GC, particularly in latency variance, throughput variance, and mean heap usage. Though, I think we're best off moving off of hypervisors and onto 4th generation microkernels with isolation similar to AIX LPARs / Solaris Containers. After all, a hypervisor is essentially a microkernel that's forced to use hardware traps/faults plus hardware emulation for its syscall interface (plus upcalls for performance, which use a calling convention much closer to traditional syscalls). There are stability, security, and performance advantages to throwing out all of that hardware emulation code, moving everything to upcalls, and getting rid of the second (guest OS) kernel running between the application and the hardware. If you push most of the system functionality out of kernel space, then rewriting some of the less performance-critical components in a language with ARC or tracing GC starts to make more sense.

blub 6y ago

By the time we all retire in a few decades they'll be a thing of the past, probably. There's so much low-hanging fruit to pick in that code and switching to Rust is like saying that we should go to Mars to pick fruit instead.