Talk on what a systems programming language needs to replace C

Russel Winder russel at winder.org.uk
Tue Aug 27 16:07:02 UTC 2019


On Mon, 2019-08-26 at 11:00 +0000, IGotD- via Digitalmars-d wrote:
[…]
> 
> These are typically, intrusive lists, structures that points to 
> each others (circular references), custom allocators. 
> "Impossible" was a little bit the wrong word that I used. 
> Difficult would be the word or "not worth it". Some of the 
> algorithms can be done but those I've seen require a huge amount 
> of boiler plate for something C would just need a few lines. 
> Circular references is something Rust cannot deal with, unless 
> you explicitly use pointers or RC objects. RC objects are not 
> always welcome in systems programming and raw pointers requires 
> you to do your own memory management so Rust loses its point. I 
> just think the way you program Rust doesn't fit systems 
> programming and it is not worth the extra hazzle. The amount of 
> unsafe hatches you would open in Rust would contradict its grand 
> "safe" selling point.

But circular data structures requires pointers in C, so to claim implementing
such things in Rust using Rust pointers is a failing of Rust is a bit unfair.
Also std::collections::LinkedList seems to do most of the work needed.

It is the case that the Rust split of crate_X for the Rust facing, and
crate_X_sys for the C facing creates apparent infrastructure issues, but it
does allow for properly constraining all the unsafe stuff into properly tested
small chinks. 

Writing library/application code using a Rust with a Rust facing wrapper based
over the unsafe C facing wrapper makes things much, much easier that writing C
code with all the manual RAII rubbish required because C has no support for
RAII.

[…]
> The speaker is right about one thing and that is that a systems 
> programming language must not have a runtime dependency, or the 
> runtime is completely OS independent. With this definition this 
> includes C, C++, D (-betterC only) and Rust. As far as I know Go 
> is runtime dependent and does not qualify for this definition.

I suspect this also rules out C as a systems programming language since there
is a C runtime system which is OS specific, along with the C library. :-)

But yes D and Go rule themselves out for any situation that cannot admit a GC
initialisation, though I suspect fear of GC is over-prevalent in far too much
of systems programming. 

-- 
Russel.
===========================================
Dr Russel Winder      t: +44 20 7585 2200
41 Buckmaster Road    m: +44 7770 465 077
London SW11 1EN, UK   w: www.russel.org.uk

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 833 bytes
Desc: This is a digitally signed message part
URL: <http://lists.puremagic.com/pipermail/digitalmars-d/attachments/20190827/7d8cf7a1/attachment.sig>


More information about the Digitalmars-d mailing list