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.
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.
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.
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
> Swift is intended as a replacement for C-based languages (C, C++, and Objective-C).
https://swift.org/about/
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.
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://blog.arduino.cc/2019/08/23/tinygo-on-arduino/
https://gvisor.dev/
https://github.com/mit-pdos/biscuit
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/O...
4 replies →
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.
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.