On Thu, Oct 29, 2020 at 02:28:58PM +0000, Mike Parker via Digitalmars-d wrote:
> On Thursday, 29 October 2020 at 11:50:12 UTC, Dibyendu Majumdar wrote:
[...]
> > I was wondering if it worthwhile branding -betterC differently - e.g.  use a brand such as 'micro-D' or some nicer name. That is, give it a new identity that highlights that it not just better C  - but a D version without GC.
> 
> I think it's a bad, bad, bad idea to put any emphasis on BetterC other than as a tool to help in porting C or C++ code to D, or to integrate D into existing C and C++ projects. I see too many people reaching for it first thing, probably out of a misguided GC phobia. D is the language we need to be promoting. BetterC was intended for a specific purpose. Beyond that, it's a crippled D. If some people prefer to use it that way, fine, but we shouldn't encourage it.

+1.

Most people with GC phobia don't actually need to avoid the GC. You really only need to avoid the GC if you're working in very specific niches, like hard real-time requirements (game engines, rocket booster controllers, etc.).  Your general software project does not need to avoid the GC; you just need to know how to use it effectively (and/or apply @nogc where it matters).


T

-- 
Freedom of speech: the whole world has no right *not* to hear my spouting off!

On Thursday, 29 October 2020 at 14:43:50 UTC, H. S. Teoh wrote:
> On Thu, Oct 29, 2020 at 02:28:58PM +0000, Mike Parker via Digitalmars-d wrote:

>> 
>> I think it's a bad, bad, bad idea to put any emphasis on BetterC other than as a tool to help in porting C or C++ code to D, or to integrate D into existing C and C++ projects. I see too many people reaching for it first thing, probably out of a misguided GC phobia. D is the language we need to be promoting. BetterC was intended for a specific purpose. Beyond that, it's a crippled D. If some people prefer to use it that way, fine, but we shouldn't encourage it.
>
> +1.
>
> Most people with GC phobia don't actually need to avoid the GC. You really only need to avoid the GC if you're working in very specific niches, like hard real-time requirements (game engines, rocket booster controllers, etc.).  Your general software project does not need to avoid the GC; you just need to know how to use it effectively (and/or apply @nogc where it matters).
>
>

Maybe my point is being missed. There is a market for languages that do what D does but where GC is not an option. D's better C version is essentially what they need, so if you are happy to cede that market to Jai/Zig and similar then fine.

On Thursday, 29 October 2020 at 14:43:50 UTC, H. S. Teoh wrote:
> On Thu, Oct 29, 2020 at 02:28:58PM +0000, Mike Parker via Digitalmars-d wrote:
>> On Thursday, 29 October 2020 at 11:50:12 UTC, Dibyendu Majumdar wrote:
> [...]
>> > [...]
>> 
>> I think it's a bad, bad, bad idea to put any emphasis on BetterC other than as a tool to help in porting C or C++ code to D, or to integrate D into existing C and C++ projects. I see too many people reaching for it first thing, probably out of a misguided GC phobia. D is the language we need to be promoting. BetterC was intended for a specific purpose. Beyond that, it's a crippled D. If some people prefer to use it that way, fine, but we shouldn't encourage it.
>
> +1.
>
> Most people with GC phobia don't actually need to avoid the GC. You really only need to avoid the GC if you're working in very specific niches, like hard real-time requirements (game engines, rocket booster controllers, etc.).  Your general software project does not need to avoid the GC; you just need to know how to use it effectively (and/or apply @nogc where it matters).
>
>
> T

We could really use some more @nogc containers that use the allocators, in the standard library. Even if they don't work that well it's good marketing for the language. Unfortunately I think D's approximation move semantics might be a problem?

On Thursday, 29 October 2020 at 16:15:28 UTC, Dibyendu Majumdar wrote:
> On Thursday, 29 October 2020 at 14:43:50 UTC, H. S. Teoh wrote:
>> On Thu, Oct 29, 2020 at 02:28:58PM +0000, Mike Parker via Digitalmars-d wrote:

> Maybe my point is being missed. There is a market for languages that do what D does but where GC is not an option. D's better C version is essentially what they need, so if you are happy to cede that market to Jai/Zig and similar then fine.

I can't think of a better name than betterC if your goal is to do the same things as with C, only with some added features. The important thing to me is to emphasize that it's a subset of C but has many limitations. I'm in strong agreement with Mike on this one.

More generally, if you want to promote it effectively, write a big project using betterC and promote your project instead.

On Thursday, 29 October 2020 at 18:20:56 UTC, bachmeier wrote:
> On Thursday, 29 October 2020 at 16:15:28 UTC, Dibyendu Majumdar wrote:
>> On Thursday, 29 October 2020 at 14:43:50 UTC, H. S. Teoh wrote:
>>> On Thu, Oct 29, 2020 at 02:28:58PM +0000, Mike Parker via Digitalmars-d wrote:
>
>> Maybe my point is being missed. There is a market for languages that do what D does but where GC is not an option. D's better C version is essentially what they need, so if you are happy to cede that market to Jai/Zig and similar then fine.
>
> I can't think of a better name than betterC if your goal is to do the same things as with C, only with some added features. The important thing to me is to emphasize that it's a subset of C but has many limitations. I'm in strong agreement with Mike on this one.
>
> More generally, if you want to promote it effectively, write a big project using betterC and promote your project instead.

subset of C -> superset of C

On Thursday, 29 October 2020 at 16:15:28 UTC, Dibyendu Majumdar wrote:
> On Thursday, 29 October 2020 at 14:43:50 UTC, H. S. Teoh wrote:
>> On Thu, Oct 29, 2020 at 02:28:58PM +0000, Mike Parker via Digitalmars-d wrote:
>
>>> 
>>> I think it's a bad, bad, bad idea to put any emphasis on BetterC other than as a tool to help in porting C or C++ code to D, or to integrate D into existing C and C++ projects. I see too many people reaching for it first thing, probably out of a misguided GC phobia. D is the language we need to be promoting. BetterC was intended for a specific purpose. Beyond that, it's a crippled D. If some people prefer to use it that way, fine, but we shouldn't encourage it.
>>
>> +1.
>>
>> Most people with GC phobia don't actually need to avoid the GC. You really only need to avoid the GC if you're working in very specific niches, like hard real-time requirements (game engines, rocket booster controllers, etc.).  Your general software project does not need to avoid the GC; you just need to know how to use it effectively (and/or apply @nogc where it matters).
>>
>>
>
> Maybe my point is being missed. There is a market for languages that do what D does but where GC is not an option. D's better C version is essentially what they need, so if you are happy to cede that market to Jai/Zig and similar then fine.

That market exists because of GC-phobia.

https://www.ptc.com/en/products/developer-tools/perc

https://astrobe.com/Oberon.htm, https://astrobe.com/boards.htm

https://www.wildernesslabs.co/developers

https://www.f-secure.com/en/consulting/foundry/usb-armory

https://dotnet.microsoft.com/apps/games

All examples of products, whose authors just didn't care for the anti-GC crowd and pushed forward with their ideas.

On Thursday, 29 October 2020 at 14:28:58 UTC, Mike Parker wrote:
> On Thursday, 29 October 2020 at 11:50:12 UTC, Dibyendu Majumdar wrote:
>
>>
>> I was wondering if it worthwhile branding -betterC differently - e.g. use a brand such as 'micro-D' or some nicer name. That is, give it a new identity that highlights that it not just better C  - but a D version without GC.
>
> I think it's a bad, bad, bad idea to put any emphasis on BetterC other than as a tool to help in porting C or C++ code to D, or to integrate D into existing C and C++ projects. I see too many people reaching for it first thing, probably out of a misguided GC phobia. D is the language we need to be promoting. BetterC was intended for a specific purpose. Beyond that, it's a crippled D. If some people prefer to use it that way, fine, but we shouldn't encourage it.

Indeed, what I appreciate in the Java Panama/Valhala efforts, C# 7+ memory handling, Swift and Go, is the attitute to improve their low level programming capabilities without making concessions to the anti-GC folks.

D has more to gain by fixing the corner cases in the language, compiler/library bugs, and having a good library ecosystem than trying to please everyone.

On Thursday, 29 October 2020 at 21:13:20 UTC, Paulo Pinto wrote:
> Indeed, what I appreciate in the Java Panama/Valhala efforts, C# 7+ memory handling, Swift and Go, is the attitute to improve their low level programming capabilities without making concessions to the anti-GC folks.

But Swift uses refcounting...

On Thursday, 29 October 2020 at 14:28:58 UTC, Mike Parker wrote:
> I think it's a bad, bad, bad idea to put any emphasis on BetterC other than as a tool to help in porting C or C++ code to D, or to integrate D into existing C and C++ projects.

Only because it is a poster child. If exceptions were value types and classes were structs with some extra fields then betterC would be more attractive.

On Thursday, 29 October 2020 at 21:45:47 UTC, Ola Fosheim Grøstad wrote:
> On Thursday, 29 October 2020 at 14:28:58 UTC, Mike Parker wrote:
>> I think it's a bad, bad, bad idea to put any emphasis on BetterC other than as a tool to help in porting C or C++ code to D, or to integrate D into existing C and C++ projects.
>
> Only because it is a poster child. If exceptions were value types and classes were structs with some extra fields then betterC would be more attractive.

I have a DIP I think you'll like:

https://github.com/dlang/DIPs/blob/02594a09d9daf1d393ebce2cfc2f0c4f90d4bcf8/DIPs/1NNN-PJB.md