4 ms·

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 (h

by wbhart 15y ago

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 15y ago
> 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.
- eli_gottlieb 15y ago
  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.
- rdtsc 15y ago
  > 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 15y ago
    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.

by wbhart 15y ago

eternalban 15y ago

> 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.

eli_gottlieb 15y ago
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.
rdtsc 15y ago
> 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 15y ago
  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.