back
79 comments
As someone who has worked on a systems programming language for a long time, my strongest advice would be to avoid trying to make syntactic or semantic choices that are just different unless they're really motivated by making the systems aspect better, or to make the language more self-coherent. Having surprises and syntax to learn is a barrier to entry and probably won't impress anyone.

That is to say, do focus on systems problems. Key ones I identified are efficient data representation, avoiding needless memory churn/bloat, and talking directly to lower-level software/hardware, like the kernel.

Focus on systems programming and not on syntactic niceties or oddities.

Yes, I also found the description a little weird because of the emphasis on linear-time parsing. It is cool theoretically, and it could be understandable from a perspective of "make the compiler fast", but parsing is never the bottleneck in modern compilers. For a systems programming language this seems to be the wrong emphasis.
Yes, I would go the opposite in terms of simplicity.

Parse once for syntax and symbol definition, 2nd pass over parsed structure to link symbol references to their definitions. Two uncomplicated passes.

That handles a general code graph - so the language can go anywhere, and never be fundamentally held up by limitations of early syntax/parsing decisions.

While working on my systems PL, Cwerg, I adopted a "syntax last" approach:

For the longest time the syntax was just glorified s-exprs. This made it much easier to focus on the semantic choices and improved iteration times and willingness to experiment since the parser changes were always trivial.

I highly recommend this approach for new PLs.

Interesting.

For Virgil, I started with mostly Java/C syntax, but with "variable: type" instead of "type variable", because it was both easier to parse and was more like standard ML and what you encounter in programming language theory. That syntax was already catching on, so I felt like I was swimming with the stream. I initially made silly changes like array indexing being "array(index)" instead of "array[index]", which turned out to be annoying to just take random code and change all the "[" to "(" and "]" to ")". Also, I had keywords "method" and "field", but eventually decided things looked better as "def" and "var", because they were easier to eyeball and readily understandable to people who write JavaScript (and Scala, as it turns out).

Overall Virgil's syntax is a kind of an average of all the curly braced languages and where it differs at all, it's been to make things more composable and avoid cryptic line-noise-looking things. For example, to allocate an object of class C, one writes "C.new(args)", because that can be understood as "C.new" as a function applied to "(args)"--so one can easily write "C.new" and yes, indeed, that's a first class function. That works with delegates and so on. So I don't regret not exactly matching the "new C()" you'd find in Java or C++.

You have a lot of questions, so go to https://www.reddit.com/r/ProgrammingLanguages/

Some possible answers:

> . Unfortunately I also designed a language with top-level execution and nested functions - neither of which I could come up with a good compilation model for if I wanted to preserve the single-pass, no AST, no IR design of the compiler.

- This is the major PITA of C: Is an actual terrible target for transpilers that have aspirations and sophisticated features like Strings, some decent type system, or whatever. So, your option is to target something that is as close to semantics of your language (Basically, any other language that is not C), to the point where your target is MORE sophisticated than your own lang.

- I think Zig (for speed/apparent simplicity) and Rust could be good targets instead of C (I wish Rust were way faster to compile!). Assuming Zig, it will simplify other aspects like cross compiling

- I don't think is totally possible to avoid have a semi-interpreter for the transpiler, where you at most need a prelude with some hand-crafted functions that do the lifting. With this I mean things like `fn int(I:Int):Int'` so your code output is like `plus(int(1), int(2))`. Langs like APL/J use this for great effects and basically side-step the need for a vm/opcode. (see also: Compiling with closures)

> where your target is MORE sophisticated than your own lang.

I.. hadn't thought of this. I mean I wouldn't transpile to a slow lang like python but choosing Zig or C++ is tempting. Zig maybe not as it's unfinished. But C++ instead of C would make my life easier (for ex. implementing classes).

> prelude with some hand-crafted functions that do the lifting. With this I mean things like `fn int(I:Int):Int'` so your code output is like `plus(int(1), int(2))`

Curious what you mean here. Is it `1+2` -> ast Binop{'+', left, right} -> gen `plus(1,2)` ?? Sorry it's late here and I should sleep..

I've been down this path. Code generation is great; but the downside to this approach is that making the language debug-able is pretty much impossible. (An MPEG-SA structured audio compiler with a C++ back end).
> Curious what you mean here. Is it `1+2` -> ast Binop{'+', left, right} -> gen `plus(1,2)` ?? Sorry it's late here and I should sleep..

Yes, `plus(1,2)`. The problem will become more apparent when you find things like `plus` need some overloading support/macros/generics/etc, so thing like `print` too.

So, eventually you need to think in macros, multiple versions of the same thing, or, if you craft things very carefully, only support things your target support so you can avoid it (but I wonder how much is feasible)

> Zig maybe not as it’s unfinished

But, but, but…

They share the same two start letters! They were clearly meant to cohabitate!

Zinc on Zig, what a Zing!

(Just a casual at-a-distance zig fan)

this subreddit suffers from insufferable admins that purged any useful activity and sense of community from this sub
Nearly all of reddit is presently political spam, and bot spam - often political bot spam. Every subreddit has to some degree been infiltrated by political spam - even subs that have absolutely nothing to do with politics.

It's really unfortunate... reddit used to make me laugh - now it just makes me angry.

How do you mean?
One of the issues with systems programming languages is that the definitions programmers use for "well-understood" terms vary wildly in actual practice.

For example, the term "side effects" has half a dozen different meanings in common use. A Haskell programmer wouldn't consider memory allocation to be a side effect. A realtime programmer might consider taking too long might be a side effect, hence tools like realtime sanitizer [0]. Cryptography developers often consider input-dependent timing variance a critical side effect [1]. Embedded developers often consider things like high stack usage to be a meaningful side-effect.

This isn't to say that a systems language needs to support all of these different definitions, just a suggestion that any systems language should be extremely clear about the use cases it's intending to enable and the definitions it uses.

[0] https://clang.llvm.org/docs/RealtimeSanitizer.html

[1] https://www.bearssl.org/constanttime.html

I've never seen anyone actually refer to time variance for either realtime or crypto as "side effects".

It's true that these are all somewhat related concepts, but I'm pretty sure the term "side effect" is consistently used in the functional sense.

Even if you limit "side effects" to observable behavior in the abstract machine sense, it's not entirely clear what is meant by a function to be "pure".

GCC has two attributes for marking functions, "pure" and "const" (not the language const qualifier). C23 introduced the [[reproducible]] and [[unsequenced]] attributes, that are mostly modeled by the GCC extensions, but with some subtle but important differences in their description.

Turns out it's pretty hard to define these concepts if the language is not built around immutability and pure functions from the ground up.

>One of the issues with systems programming languages is that the definitions programmers use for "well-understood" terms vary wildly in actual practice.

I think he used side effect with a functional programming meaning. A pure function will just take immutable data and produce other immutable data without affecting state. A function which adds 1 to a number has no side effects, while a function that adds 1 to a number and prints to the console has side effects.

What makes this a "systems programming language", especially since it has "no pointers or references"?
Indeed, that makes it not a systems language by any definition I am familiar with.

> Reasonable C interop, and probably, initial compilation to C.

How do you achieve "reasonable C interop" without pointers, I wonder?

I wonder the same, but aren't pointers just integers?

So if you store a memory address in the integer variable X, you just need a way to access that memory.

In assembly languages, usually, you have no pointers.

Like we did in BASIC, with PEEK and POKE, just have to keep track what those numbers are for.
The term was introduced so long ago, it's basically prehistoric now. Pointers are needed only for system programming language, they can be absent in systems programming language.

  int ptr
I think you have something promising there.

I like that everything starts with a keyword, it makes the language feel consistant and I assume the parser is simple to understand because of it.

I like that you distinguish a procedure from a function in regards to side-effects and that you support both mutable and immutable types.

I like that you dont have to put a semicolon after each line but instead just use newline.

I like that you don't need parenthesis for ifs and whiles, however I am not sure I like the while syntax. Maybe I need to try it a bit before I can make up my mind.

On the other hand I think the type system could be expanded to support more types of different sizes. Especially if you are going for a systems programming language you want to be able to control that.

I think you could have a nil type because it is handy but it would be good if the language somehow made sure that any variable that could potentially be nil has to be explicitly checked before use.

> The language splits side-effects from non-side-effecting code. Or rather would once functions and subroutines are implemented. Subroutines can have side-effects, functions cannot. Expressions can only apply functions, not call subroutines. It's like Haskell but better.

You mean, "worse". There is a reason why e.g. Pascal only had this misfeature in its very first version and gave up on it in the Revised Report, at which point having both functions and procedures arguably became an unnecessary distinction without difference.

> And there's always the issue of what to do about side-effects on module load.

You execute them. Just be sure to only run them once, and maintain proper traversal order (that being post-order): e.g. if your main program has "import A; import B", and A has "import B, import C", and B has "import D", you first run D's init, then B's, then C's, then main's.

There's no meaningful order to shared dependencies or cyclic dependencies. You can pick one, but making it undefined is a lot more useful as the language implementer.

As a language user, don't rely on order for your side effects. Actually, just don't have side effects on module load. You almost never need it. Lazily initialize your globals.

I like where you're going with this.

If you haven't looked into Zig's 'comptime' system, you might find some relevant inspiration there.

Since you need to use a `call` statement to invoke a function, is it possible to invoke a function inside of a function call? I.e. can you write `call f(g(x))` or `call f(call g(x))` or something like that?
I wish someone is inventing a systems programming language with a bit of safety but without a borrow checker. Is it even possible? Of course, having a garbage collector wouldn't qualify.
Already exists: https://verdagon.dev/blog/generational-references
I think thats Zig in the future - there's already allocators you can use that will detect some memory safety crimes
Something modern like Modula-2 and Object Pascal?
Starting a new language with header files (.h)? No thanks. I’d rather leave the 70s behind.
Why not create an improved HLA - MASM?

What You See is What Is Executed

easy back and forth to assembly + inline assembly.

TIL. I learnt about the owl parser generator. Looks decent. Anyone's experience?
Is it called Zinc because zinc doesn’t easily corrode ;)?
It's called zinc because you are avoiding rust?
I wonder if there are PLs named after metals, or even other elements of the periodic table, other than Zinc, Carbon and Mercury? :)
This looks lovely, it's so readable!
Is it just me or is this sounding quite like BCPL?
> No package manager to distract you

What decade am I in? This is not optional any more. Hard pass.

Definitely a feature to me.

I don't have to be worried that a 3rd party library without dependency begins to have 30 transitive dependencies which now can conflict with other diamond dependencies.

I need my dependency tree to be small to avoid every single factor of friction.

Language specific package manager is exactly what encourage the exponential explosion of packages leading to dependency hell (and lead to major security concerns).

Package managers are such an odd thing from a social perspective.

You'll see cases like NPM and to a lesser degree Cargo where projects have hefty dependency graphs because it is so easy to just pull in one more dependency, but on the other side you have C++ that has conan and vcpkg but the opinions on them are so mixed people rely on other methods like cmake fetch package instead.

I appreciate having tools that let me pull in what I need when I need it, but the dependency explosion is real and I dunno how to have one without the other.

For recreational programming purposes (and sometimes professional depending on the domain), they really are a distraction.

The existence of a package manager causes a social problem within the language community of excessive transitive dependencies. It makes it difficult to trust libraries and encourages bad habits.

Much like Rust has memory safety benefits as a result of some choices that make it difficult to work with in some context, lack of a package manager can have benefits that make it difficult to work with in certain contexts.

These are all just tradeoffs and I'm glad "no package manager" languages are still being created because I personally enjoy using them more.

I'd rather have my languages focus on being a language and use something non-language-specific like nix or bazel to situate the dependencies.

Sure, the language maintainers will need to provide some kind of api which can be called by the more general purpose tool, but why not have it be a first class citizen instead of some kind of foo2nix adapter maintained by a totally separate group of people?

There's no need to have a cozy CLI and a bespoke lockfile format and a dedicated package server when I'll be using other tools to handle those things in a non-language-specific way anyhow.

I am on the complete opposite side here. I detest language specific package managers for many reasons.
One of the non-goals is “to be useful to anyone,” after all.

I like this language, it shares my aesthetics.

Big feature for me. In frontend dev, 3k dependencies in a hello world app is considered normal. In systems, a free-for-all dependency graph is a terrible plan, especially if it's an open ecosystem. NPM, Cargo, etc are good examples.

This is also why systems people will typically push back if you ask for non-official repos added to apt sources, etc.