Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

What Is Systems Programming, Really?

willcrichton.net

Post reply on HN
Print view View original

31–40 of 93 posts

Re: What Is Systems Programming, Really?

#31

Post by saagarjha »

pjmlp wrote: post #17
gjvc wrote: post #15

... this deserves a supplementary question: what will get us beyond UNIX to the next platform, not just the next paystub?

Maybe something like Android, OS X/iOS, ChromeOS, UWP, Fuchsia, Unikernels, Language runtimes on Hypervisors. And since I sense the question coming, Android, OS X/iOS, ChromeOS might use an UNIXy kernel, but its exposure surface to applications is so small, that it can be easily exchange for something else, it is just a matter of cost. Which brings us to the next point, given the commodity of free UNIX-like OSes, may…

> And since I sense the question coming, Android, OS X/iOS, ChromeOS might use an UNIXy kernel, but its exposure surface to applications is so small, that it can be easily exchange for something else, it is just a matter of cost.

Android, macOS, and iOS expose almost the full set of POSIX to the programmer. Now, you may argue that it goes mostly unused, but it is there, and there are people using it.

Re: What Is Systems Programming, Really?

#32

Post by clouddrover »

saagarjha wrote: post #26
jillesvangurp wrote: post #9

System programming is definitely a bit overloaded these days though I believe it is now widely understood to be languages like C/C++ that can be used for OS, kernel, and embedded development. I would agree though that the language ecosystem is shifting a lot in the last few years. IMHO there are now a few languages that are becoming proper full stack languages in the sense that they scale from embedded all the way to…

> IMHO there are now a few languages that are becoming proper full stack languages in the sense that they scale from embedded all the way to browser development. I think you're being a bit optimistic here: traditionally, the only language that has been able to do this is C++, and Rust is displacing it simply because Rust really tries to target C++ developers and their pains. But other than that I don't see much else…

> the only language that has been able to do this is C++

I'd say Object Pascal is able do it too, though it's certainly true that Pascal is not as widely used as C++. Free Pascal and Delphi are the two major Pascal implementations today:

https://www.freepascal.org/

https://www.embarcadero.com/products/delphi

Re: What Is Systems Programming, Really?

#33

Post by josteink »

eterps wrote: post #24
josteink wrote: post #21

Earlier quoted context omitted.

Lots of languages (like C#) allow pointers, but only inside blocks explicitly declared to be unsafe. void DoSomeUnsafeStuffHere() { // regular code here. pointers verboten. unsafe { // pointery stuff here } } I think that is equally clear, if not even more. And again: I don't think this is any more polluting than weird out of place PEEK/POKE statements.

What makes it unclear is exactly this 'pointery stuff'. There's nothing inherently unsafe about strongly typed pointers, but that's not the same as direct memory modification (which is obviously unsafe).

Strongly typed pointers is just another name for direct memory access.

The following is perfectly typesafe:

    SuperClass[] items = GetArrayOfSubClass();
Now if we try to do unsafe things to items, we may end up accidentally accessing memory we shouldn't.

    unsafe
    {
        for (int i=0; i
This may or may not work, based on the runtime memory-layout of the subclass.

Basically the presence of unsafe {} means that beyond this point correctness cannot be guaranteed by the compiler. That's in fact what the keyword is for.

And that's the marker you are looking for. No need to go digging deeper into the code looking for the actual pointers themselves.

Re: What Is Systems Programming, Really?

#34

Post by raggi »

saagarjha wrote: post #27
tralarpa wrote: post #18

Earlier quoted context omitted.

> It is acceptable to require a very small amount of assembly code, for example to implement something like memcpy or bcopy, or to provide atomic operations. There is some stuff missing in your list: preparing the stack pointer, address layout, etc. You also need tools to produce text and data sections that can be loaded at a specific address. Even if C is a low level language, there is still quite some stuff between…

> You also need tools to produce text and data sections that can be loaded at a specific address. Though, of course, most compilers provide extensions that make this task generally possible within C (using the loose definition of "I don't need any separate files or inline assembly, just attributes and flags).

So we're getting closer to it. The linker inputs and scripts are the only "real" systems programming language.

Re: What Is Systems Programming, Really?

#36

Post by m_mueller »

saagarjha wrote: post #30
m_mueller wrote: post #25

Earlier quoted context omitted.

As someone who likes Fortran90+ for numerics in HPC, I'd put it this way: * Pointers are required mainly so you can do pointer swaps and be sure there is no unnecessary allocation (in simulations this often means being sure there's no 10-100GB allocation each timestep, which is where it really matters). * Pointer math is unnecessary and only there because C has no/poor support of multidimensional arrays. Use a reason…

> Pointers are required mainly so you can do pointer swaps and be sure there is no unnecessary allocation Many languages are getting around this issue by hiding pointers in their type system, performing copy-on-write, and taking the decision of whether allocations are performed on the stack or heap out of the hands of the programmer.

> out of the hands of the programmer

see, and that's where these languages become really clunky for HPC purposes. A compiler/runtime with HPC support (and I think also systems programming) should provide (a) performant defaults with safety as a second (but still high) priority and (b) the ability for programmers to go and set things a certain way when it is clear to them how things should be implemented on the machine.

Otherwise, in large applications, there's just too many moving parts that the compiler (optimization) can mess up. As long as we have no AGI baked into compilers it's an illusion to think that compilers will do the job of HPC engineers, so if you take away these tools we just have to look elsewhere.

Re: What Is Systems Programming, Really?

#37

Post by pjmlp »

saagarjha wrote: post #31
pjmlp wrote: post #17

Earlier quoted context omitted.

Maybe something like Android, OS X/iOS, ChromeOS, UWP, Fuchsia, Unikernels, Language runtimes on Hypervisors. And since I sense the question coming, Android, OS X/iOS, ChromeOS might use an UNIXy kernel, but its exposure surface to applications is so small, that it can be easily exchange for something else, it is just a matter of cost. Which brings us to the next point, given the commodity of free UNIX-like OSes, may…

> And since I sense the question coming, Android, OS X/iOS, ChromeOS might use an UNIXy kernel, but its exposure surface to applications is so small, that it can be easily exchange for something else, it is just a matter of cost. Android, macOS, and iOS expose almost the full set of POSIX to the programmer. Now, you may argue that it goes mostly unused, but it is there, and there are people using it.

Android does not, use at your own peril as it is not part of the official APIs and will get your app terminated if you use unauthorized APIs.

Using libc is not the same as POSIX.

https://developer.android.com/ndk/guides/stable_apis

https://developer.android.com/about/versions/nougat/android-...

https://android-developers.googleblog.com/2016/06/android-ch...

As for macOS, and iOS, if Apple removed POSIX how many apps written in Objective-C and Swift (not UNIX cli tools ported from Linux) would actually be affected?

Very few, because those written in C and C++ ported from other platforms are most likely making use of ANSI C and C++ standards.

Re: What Is Systems Programming, Really?

#38

Post by pjmlp »

clouddrover wrote: post #32
saagarjha wrote: post #26

Earlier quoted context omitted.

> IMHO there are now a few languages that are becoming proper full stack languages in the sense that they scale from embedded all the way to browser development. I think you're being a bit optimistic here: traditionally, the only language that has been able to do this is C++, and Rust is displacing it simply because Rust really tries to target C++ developers and their pains. But other than that I don't see much else…

> the only language that has been able to do this is C++ I'd say Object Pascal is able do it too, though it's certainly true that Pascal is not as widely used as C++. Free Pascal and Delphi are the two major Pascal implementations today: https://www.freepascal.org/ https://www.embarcadero.com/products/delphi

That Borland management board.... :(

Re: What Is Systems Programming, Really?

#39

Post by pjmlp »

m_mueller wrote: post #36
saagarjha wrote: post #30

Earlier quoted context omitted.

> Pointers are required mainly so you can do pointer swaps and be sure there is no unnecessary allocation Many languages are getting around this issue by hiding pointers in their type system, performing copy-on-write, and taking the decision of whether allocations are performed on the stack or heap out of the hands of the programmer.

> out of the hands of the programmer see, and that's where these languages become really clunky for HPC purposes. A compiler/runtime with HPC support (and I think also systems programming) should provide (a) performant defaults with safety as a second (but still high) priority and (b) the ability for programmers to go and set things a certain way when it is clear to them how things should be implemented on the machin…

Have you looked at Chapel?

Re: What Is Systems Programming, Really?

#40

Post by _dps »

zaarn wrote: post #28
antirez wrote: post #6

My idea of system programming is that, other than the "near to the bare metal" element, which may not be always true, has this quality of creating infrastructures for other layers to use. A game 3D engine and a DNS server may be both written in C++ and may use the same low level programming techniques to achieve speed, but the fundamental difference is that one is just part of an application program of some type, and…

I think systems programming should be split in two, honestly. You have the kernel-level systems programming where you need to be near the bare metal, where you write kernels or program microcontrollers with less RAM than a x86 CPU has L1 cache, where taking a microsecond longer can mean the overall system crashing (or even costing a human life). And you have system-level systems programming where you write services a…

I think the two "poles" you've identified are good ones (~microseconds matter and ~100ms matters) but there's a wide range in between. If you do anything with video at modern resolutions, then you're in the single-millisecond-matters regime (this includes games as mentioned upthread, and just about anything in VR as well).
Post reply on HN