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