4 ms·
What would we write drivers in then if C was obsoleted?
by dvdbloc 7y ago
What would we write drivers in then if C was obsoleted?
- gpderetta 7y agopcwalton might have an opinion :). He is Rust lead designer.
- pcwalton 7y agoNot lead designer :) But yes, Rust, or even in userspace, as newer and/or more microkernel-ish OS's allow for. Apple is doing work to allow drivers to be written in Swift...
- saagarjha 7y agoI believe DriverKit is still C++.
- mpweiher 7y ago...and of course pre-Apple, DriverKit was Objective-C.
- pjmlp 7y agoAnd pre-OS X, Mac OS was Object Pascal. :)
- pjmlp 7y agoJust some parts of it. Some device classes (not to mix with OOP ones) can only be programmed with C++, while others can be developed in any compiled language able to link to the OS APIs. There is a WWDC session on it.
- merlincorey 7y agoC has a standard with multiple competing compilers. Rust does not have these same features to date.
- pjmlp 7y agoWith multiple slightly incompatible competing compilers.
- Athas 7y agoThe Oberon system has drivers in, well, Oberon (which is a high-level Pascal successor with garbage collection). Low-level memory access is done through magical peek/poke functions, in which all the dirtyness is concentrated (and these might not be allowed in user programs - not sure). This means the language as a whole is not littered with unsafe pointers just to service the tiny subset of programs that need them.
- pjmlp 7y agoAnd it is used commercially. Astrobe has been selling development kits for ARM based boards for years now.
- WalterBright 7y agoD as BetterC !
- satyenr 7y agoRust? I know a lot of people evangelise rust — to the point of annoyance of others — but as we move into an era where the entire world is run on computers, it is just not acceptable to have decades old infrastructure susceptible to bugs often caused by someone not understanding undefined or implementation dependent behaviour.
- xondono 7y agoIs still a little early, but as someone who works at the bare metal level, Rust shows early promise. The features required are still unstable (as in not in the stable version of the compiler), but it’s getting there, and doing it fast. In any case, firmware behaves a lot like banking software, language change will take time
- jason0597 7y agoCargo feels like too bloated to me for it to be something suitable for something low level like embedded. Unless the rust team can make it more appealing to use the language without cargo, I don't think there's much future.
- xedrac 7y agoWe use rust in embedded and love cargo! Coming from C++ and the endless mess of build systems that exist there, cargo is a breath of fresh air! What don't you like about it?
- xondono 7y agoIn bare metal systems, cargo would run on the developers host system, so that should not be an issue. Also, most toolchains of the sector are way more complex to maintain and way more bloated.
- pjmlp 7y agoApple says the future is C++ and Swift. Microsoft says the future is a mix of constrained C++ (Core Guidelines), Rust and AOT C#. Google says the future is C++ and Java (as of Treble) on Android, with Go, C++ and Rust on ChromeOS and Fuchsia. ARM says C++ on mbed. GenodeOS says C++ and Ada. Newton, Symbian, Bada and BeOS used C++. C is married with UNIX, they were born to each other, other OSes have long followed other paths.
- Nightshaxx 7y agoMinor point, but isn't Android moving to Kotlin? I don't think they see Java being a sustainable choice for the long term.
- pjmlp 7y agoYes they are, but in what concerns Treble and platform libraries, they plan to keep their Java 8 variant around. Apparently they are also adding support for desugaring Java 10 language features (yep 10 not 12) that don't rely on new JVM bytecodes (as per Google IO talk about state of Android tooling). At least for now.
- ant6n 7y agoZig