On exceptions, errors, and contract violations

via Digitalmars-d digitalmars-d at puremagic.com
Mon Oct 6 08:16:03 PDT 2014


On Monday, 6 October 2014 at 13:11:25 UTC, Marco Leise wrote:
> Ok, I get it. You are asking for a change in paradigms. But it
> is way outside my comfort zone to say yes or no to it. I will
> just go on duplicating the error checking through input
> validation.

I think D, Go, Rust and C++ struggle with high-level vs low-level 
programming. It is a difficult balancing act if you want to keep 
the language/libraries reasonably simple and uniform.

Go has more or less kicked out the low-level aspect and are now 
spending effort on getting acceptable response times in a high 
concurrency, memory safe niche. Useful, but limited.

Rust is too young to be evaluated, but kind of attempt to get 
safety through wrapping up unsafe stuff in unique_ptr boxes. 
Immature and at the moment inconvenient, but they are at least 
clear on keeping a razor sharp fence between unsafe and safe code.

C++ struggles with their high level effort and will do so 
forever. Primarily useful if your needs for high level support is 
limited and use C++ as a "better C".

Cost efficient web programming requires expressive high level 
programming frameworks where things are caught at runtime by a 
rich semantic system and turned into appropriate HTTP responses. 
There is usually little incentive to turn off safety features.

Engine/kernel/DSP/AI programming requires low level programming 
frameworks where you get to treat all data in their binary 
representation or close to it. Safety features are too expensive, 
but useful during debugging.

D tries to cover both, but the priorities are unclear and it 
isn't suitable for either out-of-the-box. Which is natural when 
you don't want to give up performance and still want to have 
convenience. I guess the current focus is to take the 
performance-limiting aspects of convenience out of the 
language/runtime and put it into libraries so that you can more 
easily configure according to the application domain.

The question is if you can do that without sacrificing ease of 
use, interoperability, performance and convenience.

It will be interesting to see how D without GC plays out, though.


More information about the Digitalmars-d mailing list