On Saturday, June 16, 2018 18:45:53 wjoe via Digitalmars-d-learn wrote:
> What you said earlier:
>
> On Monday, 11 June 2018 at 00:47:27 UTC, Jonathan M Davis wrote:
> > [...]
> >
> > 2. If the compiler knows that a function can't throw an Exception, then it doesn't have to insert any of the Exception handling mechanism stuff [...] So, the fact that a function is nothrow gives you a performance benefit, [...]
> >
> > - Jonathan M Davis
>
> made me believe that performance is one of the major reasons to use it. No?
>
>  From the betterC page https://dlang.org/spec/betterc.html section
> 40.2:
> ---
> Not Available
>
> D features not available with BetterC:
>
>      Garbage Collection
>      TypeInfo and ModuleInfo
>      Classes
>      Built-in threading (e.g. core.thread)
>      Dynamic arrays (though slices of static arrays work) and
> associative arrays
>      Exceptions
>      switch with strings
>      final switch
>      synchronized and core.sync
>      Static module constructors or destructors
>      Struct destructors
>      unittest (testing can be done without the -betterC flag)
> ---
> Apart from a few convenience features lost this list reads like a shopping list for performance gain over full fledged D, in the spirit of nothrow omitting exception handling mechanism, to me. You gain from no garbage collection overhead, no vtable overhead, no RTTI overhead, no exception overhead, etc, etc, ...
>
> Back in the late 90ies I used to write the lion's share of code in Pascal and implement mission critical algorithms in asm. Worked back then why wouldn't it work today, except that I wouldn't use asm anymore but something like C or betterC.
>
> Thus, people who need this kind of performance boost can benefit
> 2 fold from using betterC.
> 1. They get to keep most of D's awesomeness, including compile
> time features, scope statements, RAII, lack of a pre processor,
> memory safety protections and complete meta programming, are just
> _some_ of the highlights. And on the other hand
> 2. they gain by getting rid of a lot the 'performance hogs' like
> GC, exceptions and more, right?
> And, with no exceptions altogether they do not need to worry
> about it at all.
>
> I'm sold!

The _entire_ point of betterC is to be able to call D code from C code without having to deal with druntime (you can call D code from C code even without betterC, but then you have to worry about initializing and shutting down druntime). Basically every feature that you can't use in betterC is considered a loss, and efforts are being made to make more of them work. There's always going to be a limit to that, and some D features just plain require druntime (just like some of C++'s features require a runtime), but it was never the point of betterC to strip out a bunch of D features. That's just the natural consequence of the goal of being callable from C code without needing to worry about druntime.

All of those features that betterC can't use can be avoided in normal D code if you don't want them for whatever reason. nothrow is actually one of the few cases where you have to explicitly do something in order to avoid that list of features that you have there. In the other cases, you just don't use the feature, and the only cost you're paying is the startup and shutdown time for druntime and the few resources that it uses.

So, while you might choose to use betterC over concerns about the performance of D features that betterC doesn't allow, that was never the point of betterC.

- Jonathan M Davis

On Saturday, 16 June 2018 at 21:25:01 UTC, Jonathan M Davis wrote:
> On Saturday, June 16, 2018 18:45:53 wjoe via Digitalmars-d-learn wrote:
>> What you said earlier:
>>
>> On Monday, 11 June 2018 at 00:47:27 UTC, Jonathan M Davis wrote:
>> > [...]
>> >
>> > 2. If the compiler knows that a function can't throw an Exception, then it doesn't have to insert any of the Exception handling mechanism stuff [...] So, the fact that a function is nothrow gives you a performance benefit, [...]
>> >
>> > - Jonathan M Davis
>>
>> made me believe that performance is one of the major reasons to use it. No?
>>
>>  From the betterC page https://dlang.org/spec/betterc.html section
>> 40.2:
>> ---
>> Not Available
>>
>> D features not available with BetterC:
>>
>>      Garbage Collection
>>      TypeInfo and ModuleInfo
>>      Classes
>>      Built-in threading (e.g. core.thread)
>>      Dynamic arrays (though slices of static arrays work) and
>> associative arrays
>>      Exceptions
>>      switch with strings
>>      final switch
>>      synchronized and core.sync
>>      Static module constructors or destructors
>>      Struct destructors
>>      unittest (testing can be done without the -betterC flag)
>> ---
>> Apart from a few convenience features lost this list reads like a shopping list for performance gain over full fledged D, in the spirit of nothrow omitting exception handling mechanism, to me. You gain from no garbage collection overhead, no vtable overhead, no RTTI overhead, no exception overhead, etc, etc, ...
>>
>> Back in the late 90ies I used to write the lion's share of code in Pascal and implement mission critical algorithms in asm. Worked back then why wouldn't it work today, except that I wouldn't use asm anymore but something like C or betterC.
>>
>> Thus, people who need this kind of performance boost can benefit
>> 2 fold from using betterC.
>> 1. They get to keep most of D's awesomeness, including compile
>> time features, scope statements, RAII, lack of a pre processor,
>> memory safety protections and complete meta programming, are just
>> _some_ of the highlights. And on the other hand
>> 2. they gain by getting rid of a lot the 'performance hogs' like
>> GC, exceptions and more, right?
>> And, with no exceptions altogether they do not need to worry
>> about it at all.
>>
>> I'm sold!
>
> The _entire_ point of betterC is to be able to call D code from C code without having to deal with druntime (you can call D code from C code even without betterC, but then you have to worry about initializing and shutting down druntime). Basically

BetterC sounds like a C language with tons of features from.. well actually...it sounds like a C language that fixes C's shortcomings.
To get that point across it should maybe be called C2D Easy Interop Language.

> every feature that you can't use in betterC is considered a loss, and efforts are being made to make more of them work. There's always going to be a limit to that, and some D features just plain require druntime (just like some of C++'s features require a runtime), but it was never the point of betterC to strip out a bunch of D features. That's just the natural

It is what it is and if what it is is the best tool to fix a problem I would not hesitate to use it to that end.

But you make it sound like betterC _should only_ work if actual D code is called otherwise stick with good old C. From the POV of a C programmer most of what betterC offers is a net gain and nothing is a loss because what are they losing by upgrading from C? And in general not paying for something you don't use or need is considered a gain, no?

> consequence of the goal of being callable from C code without needing to worry about druntime.
> All of those features that betterC can't use can be avoided in normal D code if you don't want them for whatever reason. nothrow is actually one of the few cases where you have to explicitly do something in order to avoid that list of features that you have there. In the other cases, you just don't use the feature, and the only cost you're paying is the startup and shutdown time for druntime and the few resources that it uses.

Please tell me. How would I disable just the Error mechanism, for example ?
As far as I can tell it's not sufficient that I don't use nothrow in my code because if it was used in phobos or druntime or some other D code I'd have to deal with it.

But I know the answer to that. It's not possible because it was never considered because why would anyone want to do that and have the program just crash.

Let's say I don't want to deal with OutOfMemoryError. That means essentially I'm losing the GC. Which sucks big time as it is _the_ selling point for me to use D over C.

Let's say I didn't agree with RangeError for assoc. Arrays. I imagine it allocates dynamically and hence has a dependency on the GC so I have to consider the OutOfMemoryError headache even if I would agree to RangeError. Solution again don't use it and implement my own.

Really, I don't see the difference between not using a feature and not having a feature available; result's the same - I need a solution/replacement.

> So, while you might choose to use betterC over concerns about the performance of D features that betterC doesn't allow, that was never the point of betterC.
>
> - Jonathan M Davis

Looks like one can only choose the headache to deal with.

Now, from the point you make about betterC, it seems like a better idea to abandon ship now and return to C instead of having to deal with similar headaches with betterC in the future.

On Monday, June 18, 2018 15:22:48 wjoe via Digitalmars-d-learn wrote:
> On Saturday, 16 June 2018 at 21:25:01 UTC, Jonathan M Davis wrote:
> > every feature that you can't use in betterC is considered a loss, and efforts are being made to make more of them work. There's always going to be a limit to that, and some D features just plain require druntime (just like some of C++'s features require a runtime), but it was never the point of betterC to strip out a bunch of D features. That's just the natural
>
> It is what it is and if what it is is the best tool to fix a problem I would not hesitate to use it to that end.
>
> But you make it sound like betterC _should only_ work if actual D code is called otherwise stick with good old C. From the POV of a C programmer most of what betterC offers is a net gain and nothing is a loss because what are they losing by upgrading from C? And in general not paying for something you don't use or need is considered a gain, no?

I'm saying that -betterC is a subset of D that does not include D's runtime, and it includes as many of D's features as it currently can without using the runtime. You can choose to use it and never use normal D code, but the reason that it was created in the first place was so that it would be easier to port C code to D. Without -betterC, you tend to be forced to port the entire program at once, whereas with it, you can port it in pieces and then only switch to normal D once everything has been ported over. But there are some folks who elect to just write code targetting -betterC and who never intend for it to work as normal D code.

> > consequence of the goal of being callable from C code without
> > needing to worry about druntime.
> > All of those features that betterC can't use can be avoided in
> > normal D code if you don't want them for whatever reason.
> > nothrow is actually one of the few cases where you have to
> > explicitly do something in order to avoid that list of features
> > that you have there. In the other cases, you just don't use the
> > feature, and the only cost you're paying is the startup and
> > shutdown time for druntime and the few resources that it uses.
>
> Please tell me. How would I disable just the Error mechanism, for
> example ?
> As far as I can tell it's not sufficient that I don't use nothrow
> in my code because if it was used in phobos or druntime or some
> other D code I'd have to deal with it.

As with pretty much every other feature, if you don't want any Errors, you just don't use anything that uses it. The same goes with the GC and other features that you might choose to avoid. In some cases, that can be quite limiting, but it is possible to avoid it. It's simply that just like with any feature, avoiding it means losing out on features.

The primary difference with nothrow over most other features is that the compiler inserts code by default for Exceptions if nothrow isn't there. So, using nothrow is required to turn that off, whereas for most other features, they only get used if you choose to use them (or use something that uses them). But it has nothing to do with Errors either way. The only way to avoid those is to never use a feature that could throw them (which can be done but would be so limiting that it's probably a waste of time).

> But I know the answer to that. It's not possible because it was never considered because why would anyone want to do that and have the program just crash.
>
> Let's say I don't want to deal with OutOfMemoryError. That means essentially I'm losing the GC. Which sucks big time as it is _the_ selling point for me to use D over C.
>
> Let's say I didn't agree with RangeError for assoc. Arrays. I imagine it allocates dynamically and hence has a dependency on the GC so I have to consider the OutOfMemoryError headache even if I would agree to RangeError. Solution again don't use it and implement my own.
>
> Really, I don't see the difference between not using a feature and not having a feature available; result's the same - I need a solution/replacement.

If having the program crash due to an error condition being considered fatal is unacceptable to you, then D will be unacceptable to you - including with -betterC, since in that case, the Errors get turned into failed C assertions that aren't compiled out. So, you won't get the stack unwinding, but your program will be purposefully killed either way, because it encountered an error condition that is considered fatal. You're free to disagree with that approach, and you're free to disagree with which error conditions are considered fatal, but it's part of using D. So, you'll either have to learn to live with that or use a different language.

- Jonathan M Davis

On Monday, 18 June 2018 at 20:23:48 UTC, Jonathan M Davis wrote:
> On Monday, June 18, 2018 15:22:48 wjoe via Digitalmars-d-learn wrote:
>> On Saturday, 16 June 2018 at 21:25:01 UTC, Jonathan M Davis wrote:
>> > every feature that you can't use in betterC is considered a loss, and efforts are being made to make more of them work. There's always going to be a limit to that, and some D features just plain require druntime (just like some of C++'s features require a runtime), but it was never the point of betterC to strip out a bunch of D features. That's just the natural
>>
>> It is what it is and if what it is is the best tool to fix a problem I would not hesitate to use it to that end.
>>
>> But you make it sound like betterC _should only_ work if actual D code is called otherwise stick with good old C. From the POV of a C programmer most of what betterC offers is a net gain and nothing is a loss because what are they losing by upgrading from C? And in general not paying for something you don't use or need is considered a gain, no?
>
> I'm saying that -betterC is a subset of D that does not include D's runtime, and it includes as many of D's features as it currently can without using the runtime. You can choose to use it and never use normal D code, but the reason that it was created in the first place was so that it would be easier to port C code to D. Without -betterC, you tend to be forced to port the entire program at once, whereas with it, you can port it in pieces and then only switch to normal D once everything has been ported over. But there are some folks who elect to just write code targetting -betterC and who never intend for it to work as normal D code.

That's not how it came across.
It came across like the _entire_ purpose of it is to call D stuff without the need to deal with the druntime and nothing else.

>> Please tell me. How would I disable just the Error mechanism, for
>> example ?
>> As far as I can tell it's not sufficient that I don't use nothrow
>> in my code because if it was used in phobos or druntime or some
>> other D code I'd have to deal with it.
>
> As with pretty much every other feature, if you don't want any Errors, you just don't use anything that uses it. The same goes with the GC and other features that you might choose to avoid. In some cases, that can be quite limiting, but it is possible to avoid it. It's simply that just like with any feature, avoiding it means losing out on features.

So basically everything safe for what is betterC.

> The primary difference with nothrow over most other features is that the compiler inserts code by default for Exceptions if nothrow isn't there. So, using nothrow is required to turn that off, whereas for most other features, they only get used if you choose to use them (or use something that uses them). But it has nothing to do with Errors either way. The only way to avoid those is to never use a feature that could throw them (which can be done but would be so limiting that it's probably a waste of time).
>
> If having the program crash due to an error condition being considered fatal is unacceptable to you, then D will be

I never made that claim. Unacceptable to me is the implemented mechanism.

> unacceptable to you - including with -betterC, since in that case, the Errors get turned into failed C assertions that aren't compiled out. So, you won't get the stack unwinding, but your program will be purposefully killed either way, because it encountered an error condition that is considered fatal. You're

yes, it will be terminated via sigabrt. Which is the way it's supposed to be.
Not to continue running to a function that prints possibly invalid stuff, iff a console like device is attached, and abort in a central, completely unrelated, part of the druntime.
If no console is attached, you'll end up with nothing.

Seriously, the entire mechanism is contradicting itself. How can it declare program state invalid and unfit to continue at the point the Error was detected and thrown but do it regardless ?

> free to disagree with that approach, and you're free to disagree with which error conditions are considered fatal, but it's part of using D. So, you'll either have to learn to live with that or use a different language.
>
> - Jonathan M Davis

One could also argue that Exceptions are an integral part of using D and there is really never a situation where you need to turn it off just like there is never a situation where you would catch an Error. Deal with it.

If a programming language doesn't so much as to help the developer to be more productive, e.g. by making it easier to squash bugs but, by definition i.e. invalid program state, make it impossible to troubleshoot them, then this language is at least a bad decision from an economic point of view. Which makes it a toy language.

I know that much of what can be done actually works in practice but that's not the point. As soon as program is in invalid state it must not continue but immediately abort - and if it continues regardless nothing at all can be relied upon, including what the druntime spits out before aborting because the druntime is, at least by definition, in invalid state, too.
And all of this is completely unrelated to my personal opinion.

On Friday, 15 June 2018 at 17:46:02 UTC, wjoe wrote:
>> D allows various levels of performance and safety. Though I'd say Errors not working in debug mode is not intended, the
>
> Intention matters not. By definition all program state is invalid at the point an Error was thrown. From there on it is impossible to rely on any output, too, because it could be either correct, corrupted, or completely invalid.

The program is in invalid state when it hits a bug before Error is thrown, this is seen as a property of a buggy algorithm, Error is thrown only as a diagnostic of a bug that has happened already. The state is invalid in a sense that the program shouldn't continue to serve its intended purpose. Even if Error was technically correctly unwound, it won't necessarily provide a correct cleanup when algorithm doesn't expect an exception.
Though in case of D situation may be not as clear as there is safe code, but we just recently had a nasty memory corruption bug caused by incorrect trusted code.

> A core dump is created by the OS. In a format that a native debugger understands.

Most of the time a stack trace is enough to diagnose the error and provides a better UX than a core dump (especially to newbies). I saw gdb crash trying to make sense of a debugged program too. Runtime allows to override failure handlers, but it's not centralized.

On Tuesday, 19 June 2018 at 12:26:15 UTC, Kagamin wrote:
> On Friday, 15 June 2018 at 17:46:02 UTC, wjoe wrote:
>>> D allows various levels of performance and safety. Though I'd say Errors not working in debug mode is not intended, the
>>
>> Intention matters not. By definition all program state is invalid at the point an Error was thrown. From there on it is impossible to rely on any output, too, because it could be either correct, corrupted, or completely invalid.
>
> The program is in invalid state when it hits a bug before Error is thrown, this is seen as a property of a buggy algorithm, Error is thrown only as a diagnostic of a bug that has happened already. The state is invalid in a sense that the program shouldn't continue to serve its intended purpose. Even if Error was technically correctly unwound, it won't necessarily provide a correct cleanup when algorithm doesn't expect an exception.
> Though in case of D situation may be not as clear as there is safe code, but we just recently had a nasty memory corruption bug caused by incorrect trusted code.
>

I wrote that 4 days ago. I lost some sleep over that matter and am long past the idea of trying to correctly clean up in this situation. You would know that had you read my more recent posts.

>> A core dump is created by the OS. In a format that a native debugger understands.
>
> Most of the time a stack trace is enough to diagnose the error

I'll say it again. The program must have a console(like) device attached. Otherwise you will not have a stack trace - or at least it needs to be redirected to a file but that's not very newbie friendly either because each shell has their own way of doing it and csh, for example, can't even redirect individually. I'm not sure about Windows. Even if possible, considering the heavy focus on GUI, I doubt it's considered best practices there and is a PITA for sure.

But maybe I missed something else and the only purpose of D is to make console applications for *NIX like OSs and expect users to be professional enough to save that stack trace before they close the terminal ?

And how can you be sure that this bug didn't corrupt memory of the druntime or anything else related to the stack trace, or even that it is a single bug ?

And how useful is a stack trace that shows a back trace to the point of the location the Error was thrown compared to a back trace to the location of the bug (report)?

> and provides a better UX than a core dump (especially to

Please explain. A core dump has everything a printed stack trace has and more and is as easy as using the debugger itself.

> newbies). I saw gdb crash trying to make sense of a debugged program too. Runtime allows to override failure handlers, but it's not centralized.

And what guarantee is there that the runtime doesn't crash trying to print a stack trace ? Could happen just as likely.

On Tuesday, 19 June 2018 at 15:03:49 UTC, wjoe wrote:
> But maybe I missed something else and the only purpose of D is to make console applications for *NIX like OSs and expect users to be professional enough to save that stack trace before they close the terminal ?

I just read stack trace from console.
Initially D ecosystem focused on windows console applications, linux support came later, and compiling windows gui application is not straightforward. Simply because console support is the first thing to implement.

> And how can you be sure that this bug didn't corrupt memory of the druntime or anything else related to the stack trace, or even that it is a single bug ?

The state is invalid in a sense that program shouldn't continue to serve its intended purpose.

> And how useful is a stack trace that shows a back trace to the point of the location the Error was thrown compared to a back trace to the location of the bug (report)?

In most cases stack trace is enough to diagnose the error.

>> and provides a better UX than a core dump (especially to
>
> Please explain. A core dump has everything a printed stack trace has and more and is as easy as using the debugger itself.

Do you know how to extract information from it on an unfamiliar OS? Reading stack trace is easier and self-evident.

On Wednesday, 20 June 2018 at 12:22:33 UTC, Kagamin wrote:
> On Tuesday, 19 June 2018 at 15:03:49 UTC, wjoe wrote:
>> But maybe I missed something else and the only purpose of D is to make console applications for *NIX like OSs and expect users to be professional enough to save that stack trace before they close the terminal ?
>
> I just read stack trace from console.
> Initially D ecosystem focused on windows console applications, linux support came later, and compiling windows gui application is not straightforward. Simply because console support is the first thing to implement.
>
>> And how can you be sure that this bug didn't corrupt memory of the druntime or anything else related to the stack trace, or even that it is a single bug ?
>
> The state is invalid in a sense that program shouldn't continue to serve its intended purpose.

Either it is invalid, or if it is safe for the druntime to assume that it's safe to do whatever it does, then it's just as safe to assume that an installed signal handler called by the OS is doing it's thing just fine as well, like stopping a motor.

>> And how useful is a stack trace that shows a back trace to the point of the location the Error was thrown compared to a back trace to the location of the bug (report)?
>
> In most cases stack trace is enough to diagnose the error.

In most cases errors are easy to fix, too. I worry about the corner cases. The really annoying bugs. The bugs you might only get one shot at because you don't know how to reproduce, which you can only diagnose and fix via post mortem debugging.

>
>>> and provides a better UX than a core dump (especially to
>>
>> Please explain. A core dump has everything a printed stack trace has and more and is as easy as using the debugger itself.
>
> Do you know how to extract information from it on an unfamiliar OS? Reading stack trace is easier and self-evident.

Counter question: How do you develop for an unfamiliar OS with unfamiliar tools in the first place ?
The concept of a debugger and a memory dump is fundamentally the same on every OS I know or care about just as much as the D error implementation doesn't care about niche cases.

Of course you can debug your applications via print to console if you feel that this is productive enough and ignore the bugs you can't fix that way.

On Thursday, June 21, 2018 13:16:28 wjoe via Digitalmars-d-learn wrote:
> On Wednesday, 20 June 2018 at 12:22:33 UTC, Kagamin wrote:

> > Do you know how to extract information from it on an unfamiliar OS? Reading stack trace is easier and self-evident.
>
> Counter question: How do you develop for an unfamiliar OS with
> unfamiliar tools in the first place ?
> The concept of a debugger and a memory dump is fundamentally the
> same on every OS I know or care about just as much as the D error
> implementation doesn't care about niche cases.
>
> Of course you can debug your applications via print to console if you feel that this is productive enough and ignore the bugs you can't fix that way.

Simply having a stack trace would be plenty in many cases, and if you're primarily developing an a different OS from the one the user was on when the error occurred, getting a stack trace may allow you to see what the problem is and fix it without setting up a debugger on the OS that the user was running (which could be a huge timesaver if you don't normally use that OS). That being said, the optimal solution is likely printing out the error message and stack trace, and then giving a coredump (or the OS' equivalent) at the point of the failure. Then if the message and stack trace are enough, you're good to go, and if you need the coredump to get more detailed information, then you have it.

- Jonathan M Davis

On Thursday, 21 June 2018 at 19:52:25 UTC, Jonathan M Davis wrote:
> On Thursday, June 21, 2018 13:16:28 wjoe via Digitalmars-d-learn wrote:
>> On Wednesday, 20 June 2018 at 12:22:33 UTC, Kagamin wrote:
>
>> > Do you know how to extract information from it on an unfamiliar OS? Reading stack trace is easier and self-evident.
>>
>> Counter question: How do you develop for an unfamiliar OS with
>> unfamiliar tools in the first place ?
>> The concept of a debugger and a memory dump is fundamentally the
>> same on every OS I know or care about just as much as the D error
>> implementation doesn't care about niche cases.
>>
>> Of course you can debug your applications via print to console if you feel that this is productive enough and ignore the bugs you can't fix that way.
>
> Simply having a stack trace would be plenty in many cases, and if you're primarily developing an a different OS from the one the user was on when the error occurred, getting a stack trace may allow you to see what the problem is and fix it without setting up a debugger on the OS that the user was running (which could be a huge timesaver if you don't normally use that

That is if that other OS provides the means to print one and the user is skilled enough to relay that info to the developer.
There's apparently no other option. Because as I learned here that installing your own crash handler, for instance, which writes this stack trace to a file and submits a crash report to the developer, is not possible.

Additionally, you might end up empty handed in case of a daemon since best practice in this domain is to close stdin/out/err to prevent them to litter the terminal with output and/or they may be runnig headless and this kind of output would never be seen.

> OS). That being said, the optimal solution is likely printing out the error message and stack trace, and then giving a coredump (or the OS' equivalent) at the point of the failure. Then if the message and stack trace are enough, you're good to go, and if you need the coredump to get more detailed information, then you have it.
>
> - Jonathan M Davis

Those who are comfy rarely see the needs of others. My attempt in this regard was to show how it feels like not to have that info.