4 ms·

> If yes, why people still even think about doing it with unsafe languages? What you need for OS or embedded development is a language that doesn't get in your

> If yes, why people still even think about doing it with unsafe languages? What you need for OS or embedded development is a language that doesn't get in your way. C doesn't get in your way. C is the first language that both stayed out of your way and also provided reasonable productivity features (over BCPL, B, and assembly). It was only recently that people have figured out how to come close to a "safe" language that doesn't get in your way. Here is a test case: grab an ARM Cortex-Mx processor. Boot, configure the I/O matrix, and set up, oh say, the counter/timer peripherals for PWM motor control and quadrature decode. If you can do that without a trip to an "unsafe" language, that is a worthy accomplishment for your safe language. Another test case might be doing page swapping and page-table updates on a virtual memory subsystem on a multi-core CPU without a trip to an unsafe language. I guess a more direct answer to your question is that when you get down to the hardware, you have to deal with weirdo bit fields, volatile hardware registers, strange read/write ordering requirements, interlocks, and even some totally non-interlockable volatile stuff. C can do it (although I admit it uses language features not everyone sees every day).

nmjohn 10y ago
> I guess a more direct answer to your question is that when you get down to the hardware, you have to deal with weirdo bit fields, volatile hardware registers, strange read/write ordering requirements, interlocks, and even some totally non-interlockable volatile stuff. C can do it (although I admit it uses language features not everyone sees every day). I agree with you that building an entire OS to interface with hardware without using _any_ unsafe code is, by some definition of the word, impossible. However that doesn't mean you must limit yourself to unsafe languages for the other 90% of the operating system code.
steveklabnik 10y ago
Funny you should mention the Cortex-M :) https://github.com/helena-project/tock/ https://github.com/helena-project/tock/ (written in Rust, just linked to it down thread as well)
- dbcurtis 10y ago
  I will check that out.
- orcy 10y ago
  $ grep -r unsafe | wc -l 292
  - steveklabnik 10y ago
    Sure. Hardware is inherently not safe; the key is to build up safe abstractions around it by using the type system.
pjmlp 10y ago
> C is the first language that both stayed out of your way and also provided reasonable productivity features If we ignore the history of computers outside AT&T....
- dbcurtis 10y ago
  Example? Standard language that never required a trip to assembly language for system level programming? On IBM's, PL/I didn't cut it that regard. On a UNIVAC you could do a lot of system programming in FORTRAN, but only because there were a zillion proprietary extensions that accessed system programming primitives. BASIC on a Commodore 64 had PEEK() and POKE() but that doesn't count either, very non-standard. FORTH? Nope... still asm at the bottom. Concurrent Pascal? Nope... not safe, despite the type checking, because you could twist variant records however you liked. And I think there was asm at the bottom anyway, IIRC. COBOL, well, CDC COBOL had a bunch of extensions, too, but you still ended up in asm for system programming. Show me the source code for a device driver in a high-level language that pre-dates C/B/BCPL.
  - pjmlp 10y ago
    > On a UNIVAC you could do a lot of system programming in FORTRAN, but only because there were a zillion proprietary extensions that accessed system programming primitives. Just like pure ANSI C without compiler extensions. > Standard language that never required a trip to assembly language for system level programming? Try to implement 100% of libc in ANSI C without writing one single line of Assembly, syscalls into the underlying OS or compiler specific language extensions. > Show me the source code for a device driver in a high-level language that pre-dates C/B/BCPL. ESPOL on Burroughs B5000, 1961.
  - Narishma 10y ago
    > Example? Standard language that never required a trip to assembly language for system level programming? That would exclude C as well.
  - stcredzero 10y ago
    FORTH? Nope... still asm at the bottom. I call shenanigans!

nmjohn 10y ago

> I guess a more direct answer to your question is that when you get down to the hardware, you have to deal with weirdo bit fields, volatile hardware registers, strange read/write ordering requirements, interlocks, and even some totally non-interlockable volatile stuff. C can do it (although I admit it uses language features not everyone sees every day). I agree with you that building an entire OS to interface with hardware without using _any_ unsafe code is, by some definition of the word, impossible. However that doesn't mean you must limit yourself to unsafe languages for the other 90% of the operating system code.

steveklabnik 10y ago

Funny you should mention the Cortex-M :) https://github.com/helena-project/tock/ https://github.com/helena-project/tock/ (written in Rust, just linked to it down thread as well)

dbcurtis 10y ago
I will check that out.
orcy 10y ago
$ grep -r unsafe | wc -l 292
- steveklabnik 10y ago
  Sure. Hardware is inherently not safe; the key is to build up safe abstractions around it by using the type system.

pjmlp 10y ago

> C is the first language that both stayed out of your way and also provided reasonable productivity features If we ignore the history of computers outside AT&T....

dbcurtis 10y ago
Example? Standard language that never required a trip to assembly language for system level programming? On IBM's, PL/I didn't cut it that regard. On a UNIVAC you could do a lot of system programming in FORTRAN, but only because there were a zillion proprietary extensions that accessed system programming primitives. BASIC on a Commodore 64 had PEEK() and POKE() but that doesn't count either, very non-standard. FORTH? Nope... still asm at the bottom. Concurrent Pascal? Nope... not safe, despite the type checking, because you could twist variant records however you liked. And I think there was asm at the bottom anyway, IIRC. COBOL, well, CDC COBOL had a bunch of extensions, too, but you still ended up in asm for system programming. Show me the source code for a device driver in a high-level language that pre-dates C/B/BCPL.
- pjmlp 10y ago
  > On a UNIVAC you could do a lot of system programming in FORTRAN, but only because there were a zillion proprietary extensions that accessed system programming primitives. Just like pure ANSI C without compiler extensions. > Standard language that never required a trip to assembly language for system level programming? Try to implement 100% of libc in ANSI C without writing one single line of Assembly, syscalls into the underlying OS or compiler specific language extensions. > Show me the source code for a device driver in a high-level language that pre-dates C/B/BCPL. ESPOL on Burroughs B5000, 1961.
- Narishma 10y ago
  > Example? Standard language that never required a trip to assembly language for system level programming? That would exclude C as well.
- stcredzero 10y ago
  FORTH? Nope... still asm at the bottom. I call shenanigans!