On 1/4/18 8:42 AM, deadalnix wrote:
On Saturday, 30 December 2017 at 16:59:41 UTC, aberba wrote:
In this video[1] from 2016, developer talks about C++ memory safety
features, meta-programming, maturity and few others as main reasons
they choose it for developing their blockchain software (the way I got
it from a quick view).
Besides, D maturity (which I can't confirm or deny), what else does D
miss to be considered a better alternative for blockchain in 2018?
D is also more productive, has safety and unittest built-in.
1. https://www.youtube.com/watch?v=w4jq4frE5v4
I can talk about this first hand as I have a project running in D.
However, I would sadly not recommend D ATM for such a project for 2
reasons:
1/ It is practically not possible to write efficient crypto routines
without cent/ucent, short of writing them in asm.
2/ The network layer become very tedious very quick because of how
broken shared is and because there is no ownership mechanism. While none
of this is present in C++ it doesn't get in your way either.
I would *LOVE* to be able to use more D on a day to day basis, but these
2 problems make it very hard. It is especially sad considering 1/ could
be solved very easily. It literally took me less than 1h to add support
for it in SDC.
Thanks for these thoughts!
* (u)cent support
* fixes for the shared qualifier
* ownership mechanism
These took less than 1h to add support for? That would be awesome... but
realistically only the (u)cent sounds like that size of effort.
I've always wondered why we can't implement struct LargeInt(uint bytes)
as a library mechanism for larged fixed-size integers, with asm
specialization for LargeInt!8. Is adding the type to the compiler
necessary, and if so, why?
Andrei
