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)))`
Ask HN: What is must-have for a systems programming language?
1–10 of 12 posts
Re: Ask HN: What is must-have for a systems programming language?
#2Re: Ask HN: What is must-have for a systems programming language?
#3Ideally, 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.
Re: Ask HN: What is must-have for a systems programming language?
#4The 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?
Re: Ask HN: What is must-have for a systems programming language?
#5It 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, e…
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?
Re: Ask HN: What is must-have for a systems programming language?
#6For 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 wi…
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?
Re: Ask HN: What is must-have for a systems programming language?
#7Procedures? 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!
Re: Ask HN: What is must-have for a systems programming language?
#8Re: Ask HN: What is must-have for a systems programming language?
#9It 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, e…
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.
Re: Ask HN: What is must-have for a systems programming language?
#10It 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, e…
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?