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