DIP 1025--Dynamic Arrays Only Shrink, Never Grow--Community Review Round 1
Ola Fosheim Grøstad
ola.fosheim.grostad at gmail.com
Tue Nov 12 11:22:56 UTC 2019
On Tuesday, 12 November 2019 at 10:25:40 UTC, Robert Schadek
> Hm, when I think of go I think of docker/kubernetes.
> For me that is systems programming.
> I see your point, but I think there are other ways to look at
> You can actually get Microcontrollers that run python not c.
Yep, that is true.
> I think saying, and I'm not saying you say that, systems
> programming therefore
> mmm is at least a "Hasty Generalization".
I think the long term future even for embedded programming is
high level languages that allows you to "bind" datastructures to
low level representations where you need them (but otherwise
leave it to the compiler).
So yes, how to do systems programming will hopefully evolve over
But for me there ought to be a separation between high level and
low level constructs. In C++ all high level types are library
only, that means the compiler can only do low level optimization.
D has some room to innovate there, so I certainly am sympathetic
to the idea that high level features should not be undermined.
Maybe the question ought to be, can the high level features be
strenghtened in a way that allows the compiler to be smarter and
that allows the compiler to "understand" where low level
assumptions are being made and where it has free hands to be
smart. So rather than downgrading high level construct, upgrade
them from runtime-constructs to compiler-constructs.
It is quite intriguing though that something as simple as slices
can be so complex to figure out. I've written some variations of
slices for C++ before they added it, and there are so many trade
offs... Maybe one has to classifiy all the different use
scenarios for slice-like types and then figure out some solution
that allows the compiler to be more clever than in other
More information about the Digitalmars-d