IMO the best answer is Alexandrescu: "A systems programming languages must be able to allow you to write your own memory allocator in it."
Without any philosophy, clear and concise.
What Is Systems Programming, Really? (2018)
61–70 of 81 posts
Re: What Is Systems Programming, Really? (2018)
#62Earlier quoted context omitted.
What's the significant difference between having users, and having a chain of users, in purpose, philosophy and reality?
if we simplify it to being an OS (systems) vs a gui (applications) programs, we can see their purpose, philosophy, and reality. The OS' purpose is to run other programs, and thus that interface, Elf, is full of technical implementation details fitting the philosophy of a OS that allows multiple processes to run, and reality - Linux (OS) does not compete with Airbnb (application). Contrast this to a GUI program a user…
This appears both incomprehensible and wrong, but let me check if I understood.
Systems:
- Lacks a GUI.
- There are technical details.
- Doesn't compete with applications.
- Memory pressure is an issue.
Applications:
- Has a GUI.
- Need to be responsive.
- Power usage is important.
- Memory pressure results in slowness.
I don't think we got any closer to a useful answer.
Re: What Is Systems Programming, Really? (2018)
#63Earlier quoted context omitted.
A somewhat better dichotomy, faulty as all dichotomies, I suppose would be: No Magic Programming and Plenty of Magic Programming (or even All the Magic Programming). Where by magic one understands the expectation of the developer for the system to "just work": from the CSS developer writing a line such as `color: red;` and having no second thoughts to the browser engine developer knowing/caring about all the layers,…
I think this is a different dichotomy - declarative vs imperative. Generally, the declarative languages have all the magic implemented in an imperative engine.
Sure, but the context is very important: you can use Rust to control the DOM from WASM [1] and then you can use Haskell to write a load balancer [2].
[1] https://rustwasm.github.io/wasm-bindgen/examples/dom.html
[2] https://thewagner.net/blog/2019/01/30/load-balancer (off-topic: Rob Pike's Concurrency is not Parallelism https://www.youtube.com/watch?v=oV9rvDllKEg)
Re: What Is Systems Programming, Really? (2018)
#64Application programming: bug affects user.
System programming: bug bricks box.
:-)
Re: What Is Systems Programming, Really? (2018)
#65To the extent that there is a real distinction between "Systems Programming" and "Whatever is not Systems Programming" and to the extent that this distinction matters, I tend to align with the take espoused in the Systems Programming[1] Wikipedia page: The primary distinguishing characteristic of systems programming when compared to application programming is that application programming aims to produce software whic…
In practice, the demarcation line for "systems programming" is when the software directly controls and manages the hardware resources it uses. Software like this takes on some of the characteristics of an operating system because it is required to provide similar functionality, even if not an operating system per se . In application code, some other piece of software, usually the operating system, takes care of this…
Under your definition, would embedded programming fall under systems programming or do you see them as distinct areas?
Re: What Is Systems Programming, Really? (2018)
#66To the extent that there is a real distinction between "Systems Programming" and "Whatever is not Systems Programming" and to the extent that this distinction matters, I tend to align with the take espoused in the Systems Programming[1] Wikipedia page: The primary distinguishing characteristic of systems programming when compared to application programming is that application programming aims to produce software whic…
[deleted]
Re: What Is Systems Programming, Really? (2018)
#67To the extent that there is a real distinction between "Systems Programming" and "Whatever is not Systems Programming" and to the extent that this distinction matters, I tend to align with the take espoused in the Systems Programming[1] Wikipedia page: The primary distinguishing characteristic of systems programming when compared to application programming is that application programming aims to produce software whic…
Rabbitmq is a good counterexample. It is overwhelmingly used to provide services to other programs, deal with resource/performance constraints every second, but is an application-level program. Written in non-system programming language and not part of operating system and never will be.
[deleted]
Re: What Is Systems Programming, Really? (2018)
#68I always thought Systems Programming == using syscalls, even if done in an interpreted language. Not sure where I picked up that definition or if anyone actually shares it.
Re: What Is Systems Programming, Really? (2018)
#69To the extent that there is a real distinction between "Systems Programming" and "Whatever is not Systems Programming" and to the extent that this distinction matters, I tend to align with the take espoused in the Systems Programming[1] Wikipedia page: The primary distinguishing characteristic of systems programming when compared to application programming is that application programming aims to produce software whic…
Rabbitmq is a good counterexample. It is overwhelmingly used to provide services to other programs, deal with resource/performance constraints every second, but is an application-level program. Written in non-system programming language and not part of operating system and never will be.
I think based on the parent posts choice to go with the "who is your customer" definition and the fact that we intuitively think of RabbitMQ as some sort of systems program, it probably fits the modern definition of systems program that we all kind of agree with but do not necessarily put into words.
I don't think RabbitMQ being written in a "non systems language" is relevant. Its a systems program even if it was written in shell (if it was it might be a bad systems program, but a systems program nonetheless because of it's intended customers and use case).
Which brings us to browsers, which are not systems programs (and I think we tend to not think of them as such) almost entirely due to their primary customers not being programmers. This is despite the fact that they fit the "complexity/size and close to the metal" definitions a lot better than many other programs that are commonly considered to be systems level.
Re: What Is Systems Programming, Really? (2018)
#70I always thought Systems Programming == using syscalls, even if done in an interpreted language. Not sure where I picked up that definition or if anyone actually shares it.
Well, a systems programming language (for one thing) should be able to write the code that actually _executes the syscall_, i.e. it implements the OS