my first kernel in betterC D

[Laeeth Isharc]

On Wednesday, 19 June 2019 at 13:45:45 UTC, matheus wrote:
> On Sunday, 16 June 2019 at 16:14:26 UTC, Laeeth Isharc wrote:
>> ...
>
> Nice indeed, maybe you should mention this on reddit?
>
> Matheus.

Feel free to.  But I didn't do any work - I changed a few lines 
in the C code and of course it just worked.  So I would feel 
embarrassed posting to Reddit because the original author did the 
hard bit and I just made trivial changes.

You know I think Atila is right about social factors and 
integration being everything.   The objections to using D are 
just that - it's not really about what people say mostly, but 
those are excuses to rationalize how they feel.

One aspect of that is just showing something is possible.  Adam 
Ruppe's talk at dconf a while back has had a lasting influence on 
how we approach things, mostly for giving me permission to do 
what I'm naturally inclined to do anyway.  If you're not sure 
then bet a little time to try - the worst thing that can happen 
in user code is a segfault and so what.

For example our business is not primarily about network 
programming at a lowish level.  But when people say file 
transfers to Asia are slow because of the speed of light and 
latency one doesn't need to accept that.  It's quite a similar 
problem - latency and packet loss - to the days of 300 baud 
models and XModem and there's an obvious solution.  But before 
doing it myself I figured someone must have solved it and I found 
UDT.  I spent half a Saturday wrapping it so it built but 
wouldn't work and Robert Schadek finished the job in a day or 
two.  What's a decent performance improvement these days?  Well 
I'm pretty happy with a 300 times (not 300%) improvement in file 
transfer speed between regions!  And we can pull that plus libzfs 
in D plus our little language to have a tool for managing zfs 
snapshots and replication that makes everything simple because 
it's coherently designed and integrated.

Anyway I think sometimes a barrier to adoption is sometimes just 
nobody has yet shown the problem is easily solved using D in your 
domain.  We are in an age that's short on daring and ambition, 
which means a little bit of courage goes a long way.  Nobody 
could break the four minute mile.  One guy did it and then lots 
of people followed.

Most people closest to using D that aren't I guess will have a 
decent size C or C++ code base.  DPP keeps getting better in 
relation to
C++ and we want to get it to a stage where it can be used to 
expose an internal library that's still got a C++ interface but 
is being replaced step by step with D.  Thanks, Daniel Murphy for 
showing the way there, though we aren't able to do the 
translation programmatically.  DPP has paid for the modest 
support we provided many times over already even just considering 
direct benefits.

I wonder a bit about translation from C.  Rust 2C was a multi 
million DoD project.  We could steal the front end that dumps out 
the libclang C AST as CBOR.  I suppose it shouldn't be hard to 
translate that to C-style D programmatically.  It "adds nothing" 
to libclang in theory but it saves a lot of time as libclang is 
not the most complete or pleasant API I have seen.

If we had something dependable it would be much easier to move a 
C codebase incrementally to D because you could just do what you 
can manage at that time and you don't need that much imagination 
or courage because it doesn't end up being a big binary bet.  I 
guess translating C++ programmatically is a much harder, maybe 
almost impossible problem.  But C would be a start.

I have my hands full right now but I would play with doing it 
myself if I had more time...


Laeeth