On Tuesday, 24 July 2018 at 16:15:52 UTC, bpr wrote:
> On Tuesday, 24 July 2018 at 14:07:43 UTC, Ecstatic Coder wrote:
>> On Tuesday, 24 July 2018 at 13:23:32 UTC, 12345swordy wrote:
>>> On Tuesday, 24 July 2018 at 09:54:37 UTC, Ecstatic Coder wrote:
>>>> So, at the moment, I don't see how you can EASILY convince people to use BetterC for C/C++ use cases, like programming games, microcontrollers, etc.
>>>
>>> *Extremely powerful meta programming that blows c++ meta programming out of the water
>>> *Clean readable syntax
>>> *No header file nonsense
>>> *Standard keyword for ASM if you really need the performance boost.
>>> *Compiler enforce memory safety.
>>>
>>> -Alex
>>
>> I know.
>>
>> And D's builtin strings/arrays/slices/maps/etc and automatic memory deallocation are part of what makes D a better alternative to C++ too.
>
> No. For many C++ users, tracing GC is absolutely not an option. And, if it were, D's GC is not a shining example of a good GC. It's not even precise, and I would bet that it never will be. If I'm able to tolerate a GC, there are languages with much better GCs than the D one, like Go and Java.
>
> I work in a mostly C++ shop where exceptions are intolerable in C++ code, and in many places we use CRTP to eliminate dispatch overhead. DasBetterC would be usable here but it's too late given the existing investment in C++. Obviously there's no CRTP in DasBetterC without struct inheritance, but there are other designs to address this issue.
>
> Besides having more betterC libraries, I'd like to see some kind of restricted approach to exception handling, like the ones being investigated in http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2018/p0709r1.pdf. If you want a better C++, look at what people who have to use C++ use it for, and where the pain points are.

I agree.

What I leant is that after having built several realtime 3D engines using simoly strong/weak references to transparently release unused objects, I don't see why such features couldn't be integrated in a language like D as a core feature (T,T^,T*), instead of being a template library.

This gets the job done, and while not perfect, this remains very handy. A cycle detector is only required as a debugging tool.

All you need is 3 kinds of pointers:
- strong reference
- weak reference
- raw pointer

And, unfortunately, more discipline to manage mutual references yourself, instead of letting the GC manage that for you. So in some cases, having an optional cycle colkector can be very useful when using D in a Go-like way...

On Tuesday, 24 July 2018 at 16:15:52 UTC, bpr wrote:
> On Tuesday, 24 July 2018 at 14:07:43 UTC, Ecstatic Coder wrote:
>> [...]
>
> No. For many C++ users, tracing GC is absolutely not an option. And, if it were, D's GC is not a shining example of a good GC. It's not even precise, and I would bet that it never will be. If I'm able to tolerate a GC, there are languages with much better GCs than the D one, like Go and Java.
>
> [...]

There was a precise GC in the works at one point, no clue what happened to it.

On Tuesday, 24 July 2018 at 17:14:53 UTC, Chris M. wrote:
> On Tuesday, 24 July 2018 at 16:15:52 UTC, bpr wrote:
>> On Tuesday, 24 July 2018 at 14:07:43 UTC, Ecstatic Coder wrote:
>>> [...]
>>
>> No. For many C++ users, tracing GC is absolutely not an option. And, if it were, D's GC is not a shining example of a good GC. It's not even precise, and I would bet that it never will be. If I'm able to tolerate a GC, there are languages with much better GCs than the D one, like Go and Java.
>>
>> [...]
>
> There was a precise GC in the works at one point, no clue what happened to it.

The newest PR is:

https://github.com/dlang/druntime/pull/1977

Though there's already a bit of precise scanning on Windows, e.g. https://github.com/dlang/druntime/pull/1798 and IIRC Visual D uses a precise GC too.

On Tuesday, 24 July 2018 at 09:54:37 UTC, Ecstatic Coder wrote:
> On Tuesday, 24 July 2018 at 00:41:54 UTC, RhyS wrote:
>> [...]
>
> +1
>
> IMO, D in its current state, and with its current ecosystem, even after more than a decade of existence, is still NOT the best alternative to C/C++ where they HAVE to be used (microcontrollers, game engines, etc), despite D has always had this objective in mind. And despite C++ is an unsafe language which makes it easy to have memory leaks, dangling pointers, etc.
>
> [...]

I might add that the C# 7.x improvements for low level memory management, and the effort that Unity is doing with their C# subset (HPC# with Burst compiler toolchain) to migrate core subsystems from C++ to C#, it gets even harder for adoption in the games industry.

https://unity3d.com/unity/features/job-system-ECS

Mike Acton and Andreas Fredriksson left Insomianc Games to help drive this effort.

Mike opinions regarding performance and C vs C++ are very well known across the gaming industry, and here he is improving C# performance at Unity.

--
Paulo

On Monday, 23 July 2018 at 22:45:15 UTC, Walter Bright wrote:
> On 7/23/2018 5:39 AM, Joakim wrote:
>> In my experience, people never learn, even from the blatantly obvious, _particularly_ when they're invested in the outdated. What inevitably happens is the new tech gets good enough to put them out of business, then they finally pick it up or retire. Until most system software is written in D/Go/Rust/Swift/Zig/etc., they will keep mouthing platitudes about how C is here to stay.
>
> I've predicted before that what will kill C is managers and customers requiring memory safety because unsafeness costs them millions. The "just hire better programmers" will never work.

It ought to be obvious that "just use better tools" is far cheaper and more effective, but I think one of the problems is something that I also see in politics quite a bit: a lot of people are more interested in feeling superior or punishing people for their flaws than in avoiding bad outcomes. And there's also the magical "if only everyone would ..." thinking. If you want to get everyone to do something they aren't currently doing, you need some *causal mechanism* (and it has to be feasible, which "avoid all mistakes through discipline" is not).

On Wednesday, 25 July 2018 at 08:23:40 UTC, Paulo Pinto wrote:
> On Tuesday, 24 July 2018 at 09:54:37 UTC, Ecstatic Coder wrote:
>> On Tuesday, 24 July 2018 at 00:41:54 UTC, RhyS wrote:
>>> [...]
>>
>> +1
>>
>> IMO, D in its current state, and with its current ecosystem, even after more than a decade of existence, is still NOT the best alternative to C/C++ where they HAVE to be used (microcontrollers, game engines, etc), despite D has always had this objective in mind. And despite C++ is an unsafe language which makes it easy to have memory leaks, dangling pointers, etc.
>>
>> [...]
>
> I might add that the C# 7.x improvements for low level memory management, and the effort that Unity is doing with their C# subset (HPC# with Burst compiler toolchain) to migrate core subsystems from C++ to C#, it gets even harder for adoption in the games industry.
>
> https://unity3d.com/unity/features/job-system-ECS
>
> Mike Acton and Andreas Fredriksson left Insomianc Games to help drive this effort.
>
> Mike opinions regarding performance and C vs C++ are very well known across the gaming industry, and here he is improving C# performance at Unity.
>
> --
> Paulo

Yop :)

Orthodox C++ and data-oriented designs are now the basis of most new game engines since several years.

I'm glad that the Unity management has finally decided to switch its engin to a more modern archicture, so we can now develop our games as everybody else in the industry...

On Tuesday, 24 July 2018 at 17:24:41 UTC, Seb wrote:
> On Tuesday, 24 July 2018 at 17:14:53 UTC, Chris M. wrote:
>> On Tuesday, 24 July 2018 at 16:15:52 UTC, bpr wrote:
>>> On Tuesday, 24 July 2018 at 14:07:43 UTC, Ecstatic Coder wrote:
>>>> [...]
>>>
>>> No. For many C++ users, tracing GC is absolutely not an option. And, if it were, D's GC is not a shining example of a good GC. It's not even precise, and I would bet that it never will be. If I'm able to tolerate a GC, there are languages with much better GCs than the D one, like Go and Java.
>>>
>>> [...]
>>
>> There was a precise GC in the works at one point, no clue what happened to it.
>
> The newest PR is:
>
> https://github.com/dlang/druntime/pull/1977
>
> Though there's already a bit of precise scanning on Windows, e.g. https://github.com/dlang/druntime/pull/1798 and IIRC Visual D uses a precise GC too.

Well, this is a big problem with D IMO. There are a lot of unfinished, half baked features which linger in development for years. How long for precise GC now, over 5 years? I don't think D was really designed to be friendly to GC, and it just isn't realistic to expect that there will *ever* be a production quality precise GC for all of D. Maybe giving up on some things and finishing/fixing others would be a better strategy? I think so, which is why I think DasBetterC is the most appealing thing I've seen in D lately.

On Wednesday, 25 July 2018 at 16:39:51 UTC, bpr wrote:
> On Tuesday, 24 July 2018 at 17:24:41 UTC, Seb wrote:
>> On Tuesday, 24 July 2018 at 17:14:53 UTC, Chris M. wrote:
>>> On Tuesday, 24 July 2018 at 16:15:52 UTC, bpr wrote:
>>>> On Tuesday, 24 July 2018 at 14:07:43 UTC, Ecstatic Coder wrote:
>>>>> [...]
>>>>
>>>> No. For many C++ users, tracing GC is absolutely not an option. And, if it were, D's GC is not a shining example of a good GC. It's not even precise, and I would bet that it never will be. If I'm able to tolerate a GC, there are languages with much better GCs than the D one, like Go and Java.
>>>>
>>>> [...]
>>>
>>> There was a precise GC in the works at one point, no clue what happened to it.
>>
>> The newest PR is:
>>
>> https://github.com/dlang/druntime/pull/1977
>>
>> Though there's already a bit of precise scanning on Windows, e.g. https://github.com/dlang/druntime/pull/1798 and IIRC Visual D uses a precise GC too.
>
> Well, this is a big problem with D IMO. There are a lot of unfinished, half baked features which linger in development for years. How long for precise GC now, over 5 years? I don't think D was really designed to be friendly to GC, and it just isn't realistic to expect that there will *ever* be a production quality precise GC for all of D. Maybe giving up on some things and finishing/fixing others would be a better strategy? I think so, which is why I think DasBetterC is the most appealing thing I've seen in D lately.

+1

But don't be too optimistic about BetterC...

Honestly, considering D's leadership current priorities, I don't see how it could become soon a true C++ or Go competitor, even with the half-baked BetterC initiative...

For instance, I've suggested they consider using reference counting as an alternative default memory management scheme, and add it to the lists of scolarship and crowdsourced project, and of course they have added all the other suggestion, but not this one. What a surprise ;)

Despite this is probably one of the most used allocation management scheme in typical C++ development, as this drastically reduces the risks of memory leaks and dangling pointers...

Anyway, meanwhile D remains a fantastic strongly-typed scripting language for file processing and data analysis, and its recent adoption at Netflix has once again clearly proved it...

On Wednesday, 25 July 2018 at 17:23:40 UTC, Ecstatic Coder wrote:
> But don't be too optimistic about BetterC...

I'm too old to get optimistic about these things. In the very best case, D has quite an uphill battle for market share. Any non mainstream language does. If I were a betting man, I'd bet on Rust.

> Honestly, considering D's leadership current priorities, I don't see how it could become soon a true C++ or Go competitor, even with the half-baked BetterC initiative...

There are a few ways I can see, and doubtless others can see different ones. Here's one: use Mir and BetterC to write a TensorFlow competitor for use in developing and deploying ML models. I'm sure you can shoot holes in that idea, but you get the point. Try lots of things and see what works, and keep doing more of those things. Worked for Python.

> For instance, I've suggested they consider using reference counting as an alternative default memory management scheme, and add it to the lists of scolarship and crowdsourced project, and of course they have added all the other suggestion, but not this one. What a surprise ;)

I'm pretty sure D leadership is pursuing such things. In fact,

https://wiki.dlang.org/Vision/2018H1

rather prominently mentions it.

> Despite this is probably one of the most used allocation management scheme in typical C++ development, as this drastically reduces the risks of memory leaks and dangling pointers...

> Anyway, meanwhile D remains a fantastic strongly-typed scripting language for file processing and data analysis, and its recent adoption at Netflix has once again clearly proved it...

For this and similar uses, tracing GC is fine, better in fact than the alternatives. I'm only making noise about betterC for the cases where C++ dominates and tracing GC is a showstopper.

In an alternative timeline, DasBtterC would have been released before D with GC, and the main libraries would have been nogc, and maybe there'd be a split between raw pointers and traced refs (like Nim and Modula-3) and then maybe there'd have been no strong desire for Rust since D could have filled that niche.

On 7/24/2018 4:53 AM, Ecstatic Coder wrote:
>      str = str1 + " " + str2;

But you have to be careful how it is written:

    str = "hello" + "world";
    str = "hello" + "world" + str1;

don't work, etc.