On Friday, 8 July 2016 at 15:31:53 UTC, ketmar wrote:
> core.exception.AssertError@z00.d(2): BOOM!
> ----------------
>
> what am i doing wrong? O_O

That's an exception, not a segfault.
Try something like int* x; *x = 42;

On Friday, 8 July 2016 at 16:08:42 UTC, bachmeier wrote:
> On Friday, 8 July 2016 at 12:46:03 UTC, Chris wrote:
>
>> As for GC, it's hard to tell. When D was actually (not hypothetically) created, GC was _the_ big thing. Java had just taken off, people were pissed off with C/C++, programming and coding was becoming more and more common. Not having GC might actually have been a drawback back in the day. People would have complained that "Ah, D is like C++, no automatic memory management, I might as well stick to C++ or go for Java!" So no, I think D is where it is, because things are like they are, and "what if" discussions are useless. D has to keep on keeping on, there's no magic.
>
> Yep. If you're going to pick any feature to use to sell a new language, lack of GC is the worst. The only ones that care (and it's a small percentage) are the ones that are least likely to switch due to their existing tools, libraries, and knowledge.

True. The last sentence is something to bear in mind whenever we discuss attracting more people. If someone is really into C++ bare metal micro-optimization kinda stuff, we won't win him/her over with "no GC". As you said, they're the least likely to switch for said reasons. To be able to opt out of GC is still important, but it's not that we will attract thousands and thousands of new users because of that.

On Friday, 8 July 2016 at 15:30:12 UTC, Schrom, Brian T wrote:
> I've had reasonable success using lldb on mac.

I was referring to the stack trace on segfault, but regarding the user of debuggers on a Mac with D, most of the time it doesn't work very well for me. I think last time I used lldb (maybe last week) when I tried to print something in a D program nothing would happen, not even an error. Now that lldc is more up-to-date I'll check if that helps lldb get less confused.

On Friday, 8 July 2016 at 16:08:42 UTC, bachmeier wrote:
> Yep. If you're going to pick any feature to use to sell a new language, lack of GC is the worst. The only ones that care (and it's a small percentage) are the ones that are least likely to switch due to their existing tools, libraries, and knowledge.

I said strong support for nogc (e.g. easy to do things with the stdlib without allocating), not that GC would not be available.

On Friday, 8 July 2016 at 17:04:04 UTC, Luís Marques wrote:
> On Friday, 8 July 2016 at 15:31:53 UTC, ketmar wrote:
>> core.exception.AssertError@z00.d(2): BOOM!
>> ----------------
>>
>> what am i doing wrong? O_O
>
> That's an exception, not a segfault.
> Try something like int* x; *x = 42;

segfault is impossible to catch outside of debugger. any hackish "solution" to this is WRONG.

p.s. it's not something specifical to D. any program that "catches" segfault by itself should be burnt with fire.

On 7/8/2016 8:17 AM, Luís Marques wrote:
> On Sunday, 3 July 2016 at 06:23:05 UTC, Walter Bright wrote:
>> If the program is compiled with -g and it crashes (seg faults) you'll usually
>> at least get a stack trace. Running it under a debugger will get you much more
>> information.
>
> Only on Windows, and that's a common source of frustration for me :(

Linux too.

On Friday, 8 July 2016 at 21:26:19 UTC, Walter Bright wrote:
>> Only on Windows, and that's a common source of frustration for me :(
>
> Linux too.

Not by default, right? Only with the magic import and call. That's certainly better than on OS X, where there's no segfault handler at all (I don't think there's anything wrong with using it for a debug build), but it's something a bit obscure that is often not enabled when a segfault crash appears by surprise.

On Friday, 8 July 2016 at 12:46:03 UTC, Chris wrote:
> As for GC, it's hard to tell. When D was actually (not hypothetically) created, GC was _the_ big thing. Java had just taken off, people were pissed off with C/C++, programming and coding was becoming more and more common.

Errr... Garbage collection was common since the 60s. One problem with GC in the late 80s and early 90s is that it requires twice as much memory and memory was scarce so reference counting was/is the better option. You could make the same argument about templates, memory...

I also don't recall anyone being in awe of Java having GC. The big selling point was portability and the very hyped up idea that Java would run well in the browser, which did not materialize. Another selling point was that it wasn't Microsoft...

On Friday, 8 July 2016 at 21:53:58 UTC, Ola Fosheim Grøstad wrote:
> On Friday, 8 July 2016 at 12:46:03 UTC, Chris wrote:
>> As for GC, it's hard to tell. When D was actually (not hypothetically) created, GC was _the_ big thing. Java had just taken off, people were pissed off with C/C++, programming and coding was becoming more and more common.
>
> Errr... Garbage collection was common since the 60s.

Which is not the point. My point was that everybody wanted GC after Java. And D was invented when GC was expected by many people.

> One problem with GC in the late 80s and early 90s is that it requires twice as much memory and memory was scarce so reference counting was/is the better option. You could make the same argument about templates, memory...

Which is why D wouldn't have taken off in the 80ies (see my post above).

> I also don't recall anyone being in awe of Java having GC. The big selling point was portability and the very hyped up idea that Java would run well in the browser, which did not materialize. Another selling point was that it wasn't Microsoft...

GC was a big selling point. Every Java book went on about how much safer it is, that you have more time for productive code, blah ... Apple even added GC to Objective-C to appease the GC crowd.