3 ms·

i never heard the term “systems programming language” before. is that a FAANG invention?

by b20000 3y ago

AlotOfReading 3y ago
It's had its current meaning at least since the 60s with IBM and PL/S. I wouldn't be surprised if it was regularly used even before that though.
- b20000 3y ago
  i don’t understand why c++ and other languages are labeled that way.
  - AnimalMuppet 3y ago
    Because you can do "systems programming" in them. What is "systems programming"? Roughly, writing OSes and the programs that come with the OS - compilers, linkers, debuggers, databases, and so on. The distinction is between "systems" and "application" programming. Again, this is 1960s language. These days, there is a FAANG take on this. If I understand correctly, Google thinks of their software infrastructure as "systems programming". That kind of tracks with the old definition if you think of the entire company network as "the machine", instead of thinking about only one computer.
  - rpnx 3y ago
    I think one common trait is that systems programming languages have pointers and manual memory management or ctor/dtor based memory management (as opposed to a garbage collector). Non-systems languages abstract away pointers with some kind of runtime. Pointers cannot be escaped. They are how the computer actually works. Either you expose pointers to the user, and all the errors that can result, or you have an abstraction layer where the limited set of automatic transformations are known to be memory safe. Low level/systems languages operate at the pointer level, high level languages translate to pointers through a limited set of transformations that have been proven memory safe. Rust is a bit weird because it somehow figured out how to do manual memory management in a mostly safe way that didn't result in a huge amount of overhead. Basically Rust works like other systems programming languages that use pointers with the additional constraint that also you have to write "lifetimes" that formally prove to the compiler that your use of those pointers is safe. Think of it as writing C++ but also having to write a proof that your code is correct.
  - oconnor663 3y ago
    I think the meaning and the boundary has changed over time, but one of the most consistent features/requirements for a systems programming language is "embedability": - functions that are called from a different language, like how parts of NumPy are written in C - code that runs in kernel space - code that runs on tiny little devices that don't really have an OS at all In theory almost any language can do those things, but for a variety of reasons in practice we only use a small set of languages to do them.

i never heard the term “systems programming language” before. is that a FAANG invention?

by b20000 3y ago

i never heard the term “systems programming language” before. is that a FAANG invention?

It's had its current meaning at least since the 60s with IBM and PL/S. I wouldn't be surprised if it was regularly used even before that though.

b20000 3y ago
i don’t understand why c++ and other languages are labeled that way.
- AnimalMuppet 3y ago
  Because you can do "systems programming" in them. What is "systems programming"? Roughly, writing OSes and the programs that come with the OS - compilers, linkers, debuggers, databases, and so on. The distinction is between "systems" and "application" programming. Again, this is 1960s language. These days, there is a FAANG take on this. If I understand correctly, Google thinks of their software infrastructure as "systems programming". That kind of tracks with the old definition if you think of the entire company network as "the machine", instead of thinking about only one computer.
- rpnx 3y ago
  I think one common trait is that systems programming languages have pointers and manual memory management or ctor/dtor based memory management (as opposed to a garbage collector). Non-systems languages abstract away pointers with some kind of runtime. Pointers cannot be escaped. They are how the computer actually works. Either you expose pointers to the user, and all the errors that can result, or you have an abstraction layer where the limited set of automatic transformations are known to be memory safe. Low level/systems languages operate at the pointer level, high level languages translate to pointers through a limited set of transformations that have been proven memory safe. Rust is a bit weird because it somehow figured out how to do manual memory management in a mostly safe way that didn't result in a huge amount of overhead. Basically Rust works like other systems programming languages that use pointers with the additional constraint that also you have to write "lifetimes" that formally prove to the compiler that your use of those pointers is safe. Think of it as writing C++ but also having to write a proof that your code is correct.
- oconnor663 3y ago
  I think the meaning and the boundary has changed over time, but one of the most consistent features/requirements for a systems programming language is "embedability": - functions that are called from a different language, like how parts of NumPy are written in C - code that runs in kernel space - code that runs on tiny little devices that don't really have an OS at all In theory almost any language can do those things, but for a variety of reasons in practice we only use a small set of languages to do them.