HN Explorer

Ask HN: What is must-have for a systems programming language?

8 points by mrbait ↗ HN
Obviously, any systems language must have predictable memory layout for at least a subset of its types, including atomic (as in primitive) and composite types -- but probably it's not quite necessary (nor possible) for function types.

What are other language features that are similarly crucial? I'd argue even arrays are kinda optional, since they can be encoded as `Array = exists (n: Size, a: Type); (repeat a > take n > reduce ((x, y) -> (x, y)))`

11 comments

[ 3.3 ms ] story [ 37.7 ms ] thread
082349872349872
I'd say a low-to-no dependency build: unless you're planning on cross-compiling everything, you'll want to be using your systems language to bring up other toolchains, not need to already have some other toolchain in place to bring up your systems language.
mikewarot
It has to be able to link to and/or predictably generate machine code, for all the bootstrapping sections.

Ideally, it has to support a return stack, and a data stack.

I've seen ROM code that couldn't assume a return stack... not fun.

It would be really, REALLY nice if it could manage reference counted, counted, automatically allocated, strings, so that you could just use them without needing to allocate/free them, etc... just return a string like you return an integer.

mrbait
Oh yes, automatic stack is a good one!

How do you think automatically managed strings might work, so that there is as little hidden code and costs as possible, but still decently ergonomic for your taste?

Would you consider automatic strings good enough if restricted to (a) statically known length, (b) statically known buffer size, or is it only worth it when they can be fully dynamic?

mikewarot
There is a nice implementation buried deep inside the Free Pascal run time libraries. There has to be some way to allocate memory at runtime for them to work properly.
bruce343434
What about a built in string table sort of feature? Each string is recorded once in a central string table, and gets turned into a unique id. To get it back to string repr, just look it up.

Though that might count as too complex of a runtime for "low level", the idea is sometimes used in compilers to speed up and ergonomize basically everything that might deal with strings, which compilers do a lot.

horsh1
For a systems language execution environment there is a huge list of crucial questions: what is a library, what is a package, how does linking works, how do you interact with different build systems, how you separately compile having only interface declarations, how to manage alternative libraries for the same interface, how to tweak compilation for multiple targets, how do you ffi?

The answers to all of the above will have an impact on your language features: how you import, how you declare foreign entities, what visibilities are possible, what data storage classes are theere, what is the module initialization order, what code can be executed during module initialization, what is your conditional compilation mechanisms?

mrbait
These all are excellent questions for someone making a systems language, but that's not quite what I had in mind.

I'm more interested in surveying the boundary between systems and application languages, rather than exploring the design space for a systems language.

In other words, what Python, Haskell or JavaScript lack that systems languages must have?

funcDropShadow
- Predictable memory layout of data structures.

- Static typing. System-level programming often has more complete requirements and more stable requirements than, business information applications. Languages for system-level programming should utilize that.

- Ability to run without heavy runtime-system.

mrbait
Is automatic register allocation necessary? Would anybody contest that?

Procedures? In and out parameters? Return values? Pointers? References? Integers? Signed? Unsigned? Structs? Unions? Arrays? Goto? Loops?

Do you enjoy implementing variable length encodings? What do you imagine would make that less error-prone?

What an application language can't have that a systems language can? What a systems language cannot ever afford and how to cope with that? What a systems language can afford lacking that an application language won't get away with?

I need your hottest takes!

Doctor-R
You need to be able to generate any machine instruction. like clear the cache, turn interrupts off and on, access the hardware bits on the I/O cards, access privileged instructions, etc. The language needs to use every instruction. In C, there is a feature to embed/call assembly language instructions which are architecture dependent.