[wbhart]

One of the examples in the repository is an implementation of malloc.

I tend to think of Go as an attempt to redefine what a systems programming language is (hence the "modern").

I don't think that there can be an established definition of what a modern systems language is, otherwise it would no longer be termed modern. Almost by definition theorists will differ on what the essential characteristics must be.

[eternalban]

> One of the examples in the repository is an implementation of malloc.

Right. And (imho) malloc is quite possibly an "old fashioned" way of looking at things:

   function malloc(num_bytes: nat): @byte

A reference to a byte block obtained from specifying the number of bytes! I would like to see the modern memory manger be type aware, have a very rich memory model, and allow for the propagation of application level semantics to OS (so they can cooperate in dealing with the current issue: memory access latencies and concurrency).

> I don't think that there can be an established definition of [a] modern systems language

Key word is "modern" so here is an attempt to box that a bit: There are 2 possible dimensions to the notion of modern:

1 - it addresses new hardware realities

2 - it enables "progress" in dealing with matter rendered difficult by existing paradigms of system programming.

The realities of a modern system surely include: multi-core SMP; strong likelihood to be employed as distributed nodes; virtualization. So "modern" platforms and deployment patterns are not addressed.

Second, Deca, I gather, would delegate dealing with all this to some higher level (user level) framework built on top of the language. I don't see any progress in that critical front, either.

[rdtsc]

> I would like to see the modern memory manger be type aware

Because these are system languages, that would happen when hardware is type aware.

[nponeccop]

It is not necessary. With software replacement for MMU possible (see Singularity OS), hardly any hardware safety support is a requirement nowadays. TAL is the way to go - AFAIK it is possible to make plain x86 assembly dependently typable by attaching proof witnesses to EXE.

[eli_gottlieb]

Deca does deal with SMP and concurrency in one way: module-level variables are tagged thread-local in the bitcode by default, at least if they're mutable.

Once the "newsig" branch (it's a rewrite from scratch after the original code had troubles with multi-module compilation) with the new signature system (region, effect, type, mutability) can compile some example code again, I'm merging it back into the main branch.