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
