Developing blockchain software with D, not C++

[Andrei Alexandrescu]

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