November 17

On Wednesday, 17 November 2021 at 02:32:21 UTC, H. S. Teoh wrote:

You're right. GC is good for experts.
For plain users, he left when he heard GC. You can't increase the number of user base.
No matter how good your language is, it's useless.
Why can Rust attract C/C++ users, but d can't. It's GC.
Without GC, D might have been popular ten years ago.java is a big hole.
Moreover, if the speed is increased by one point and the memory is reduced by one point, the customer will have more users. No one thinks users are enough.
The speed/memory of the machine is much more important than the speed/comfort of the programmer.

November 17

On Wednesday, 17 November 2021 at 02:45:10 UTC, zjh wrote:

>

Why can Rust attract C/C++ users, but d can't. It's GC.

tbf until we can a solid definition of what D actually want to be then complaining that "We're not getting the C/C++/Python/Java/JS/TS///// users" is a bit pointless, because until we know what D wants to be, we don't know who the actual target audience is.

DConf is only a few days away, so maybe we'll get some surprises then :)

November 17

On Wednesday, 17 November 2021 at 03:02:05 UTC, SealabJaster wrote:

>

DConf is only a few days away, so maybe we'll get some surprises then :)

Yes, I haven't seen D's PPT for a long time.

November 17

On Wednesday, 17 November 2021 at 02:45:10 UTC, zjh wrote:

>

On Wednesday, 17 November 2021 at 02:32:21 UTC, H. S. Teoh wrote:

You're right. GC is good for experts.
For plain users, he left when he heard GC. You can't increase the number of user base.
No matter how good your language is, it's useless.

I'm not sure if you're serious or if this is some kind of parody and I'm missing the joke.

>

Why can Rust attract C/C++ users, but d can't. It's GC.

Well obviously. That's about the only reason anyone still uses either language. Everyone else left for the greener pastures of the GC-world long ago.

>

The speed/memory of the machine is much more important than the speed/comfort of the programmer.

There is no doubt that there are small number of cases in which this is true. Judging from the software that gets written these days, including Electron apps, I don't think the world agrees with you that it's only about maximizing speed and minimizing memory usage. Java, Python, C#, Javascript - they're all popular languages.

November 17

On Wednesday, 17 November 2021 at 03:24:24 UTC, bachmeier wrote:

>

Java, Python, C#, Javascript - they're all popular languages.

When you compete with Java, python, c#, JavaScript ..., you lose.

November 17
On Wednesday, 17 November 2021 at 03:38:54 UTC, zjh wrote:
> On Wednesday, 17 November 2021 at 03:24:24 UTC, bachmeier wrote:
>> Java, Python, C#, Javascript - they're all popular languages.
>
> When you compete with `Java, python, c#, JavaScript` ..., you lose.

I'd add to that... that when D becomes 'popular', that popularity will become a significant constraint on how D further evolves/develops.

Be careful what you wish for ;-)

And btw. competition has it's own downfalls.

November 17
On Wednesday, 17 November 2021 at 02:32:21 UTC, H. S. Teoh wrote:
> On Wed, Nov 17, 2021 at 01:57:23AM +0000, zjh via Digitalmars-d wrote:
>> On Wednesday, 17 November 2021 at 01:32:50 UTC, H. S. Teoh wrote:
>> 
>> Can I make full use of the `STD` library without garbage collection?
>> If this is achieved, it can be advertised everywhere.
>> ,Then why not remove `GC` on the home page?.
>
> Why bend over backwards to please the GC-phobic crowd?  They've already made up their minds, there's no convincing them.
>
> Having a GC IME is an extremely powerful thing, contrary to what the GC haters will tell you.  It frees up your APIs from being littered with memory-management minutiae.  It makes your APIs clean, refactorable, and maintainable.  Easy to use.  It makes your code clean.  You get to make progress in your problem domain instead of wasting 75% of your brain power thinking about memory management at every step.  You save countless hours writing manual memory management code, and countless more hours debugging said code.
>
> And in D, you also get to choose to use manual memory management in performance bottlenecks *where it actually matters*. 90% of application code is not on the hot path, it's a completely waste of effort to meticulously manage memory in such code, when you could be focusing your efforts on the 10% hot path where 90% of the performance gains are made.
>
> Writing code without a GC is wasteful of programmer time, which equals to wasting money paying programmers to do something that should have been done in 10% of the time, leaving the rest of the time to work on things that actually matter, like implementing features and making progress in your problem domain.  You spend tons of wages paying said programmers to debug memory-related bugs, which are notorious to be extremely hard to find and require a lot of time, when these wages could have been used to pay them to implement new features and drive your business forward.  *And* you waste tons of wages paying them to maintain code that's needlessly complex due to having to manually manage memory all the time.  It takes a lot of time and effort to maintain such code, time that could have been diverted for more useful work had a GC been in place.
>
> And you know what?  In spite of all this time and effort, programmers get it wrong anyway -- typical C code is full of memory leaks, pointer bugs, and buffer overflows.  Most of them are latent and only trigger in obscure environments and unusual inputs, and so lie undiscovered, waiting for the day it suddenly explodes on a customer's production environment.  Or somebody comes up with a security exploit...
>
> With a GC, you instantly eliminate 90% of these problems.  Only 10% of the time, you actually need to manually manage memory -- in inner loops and hot paths where it actually matters.
>
> GC phobia is completely irrational and I don't see why we should bend over backwards to please that crowd.
>
>
> T



I can't believe this is what still being debated, yet again..

--

D's GC:

- doesn't scale, the more pointers to scan the slower the collection is
- stop the entire world whenever a collection happen
- no R&D

What's your use case with this?


And you want to attract what kind of people? in a cloud native world with such GC? what kind of people will you attract if you are doing worse than NodeJS's GC? scripters? is that what D is? a language for scripters? want to replace BASH, is that it?



--


You complain about @nogc being what the "gc phobic" people wanted, and yet they didn't come?

People don't want tags, they want a platform where they can use D, not "annotated" D

--

-betterC failed to bring C/C++ people?


Yeah, i mean..

```D
struct Test
{
    float[32] data;
}

extern (C) int main()
{
    Test b;
    Test c;

    bool r = b == c;

    return 0;
}
```

this code doesn't compile in -betterC, who will you attract if such basic and common code doesn't work?

also it sounds like it is some bone you give to a dog so he can play and you relax in peace, not a good message


fragmentation, that's what you get


--

GO became ultra popular thanks to **its** GC and its applications, not because **of a** GC, big difference ;)

--

bandaid solutions doesn't attract people, saying "we have a no GC story at home" BUT you have to do X, Y, Z, and give up on A, B, C is not what the people wanted and that you gave the "@nogc tag" and the "non functioning -betterc"

they want what Rust provide, a modern system programming language

they want what Zig provide, a modern system programming language

they want what Odin provide, a modern system programming language

they want what Jai provide, a modern system programming language


--

Don't expect those people to want a modern Java alternative


Because GO already took that role, something D could have done, and yet didn't, you have a GC, why it failed? why people complained about a GC in D? but not a GC in GO?, this is the message you REFUSE to hear


--

There are no GC-phobia, there is a poor's man GC phobia!, big difference

Instead of investing billions into a competitive GC, with nobody wants to do, including the GC advocators, let's adopt the Allocator aware mindset, it's much cheaper, and much more effective ;)





November 17

On Wednesday, 17 November 2021 at 04:38:52 UTC, forkit wrote:

>

popularity will become a significant constraint on how D further evolves/develops.

As long as the location is accurate, no your question. Find the target user.
C++:speed + memory, extreme speed .
Rust:speed + memory security.
D:speed + memory security + extreme metaprogramming.
If GC is only an option, I believe it can attract users.
If you don't force the user, the user will come naturally.
Provide options, not mandatory.

November 17
On Wednesday, 17 November 2021 at 02:08:22 UTC, H. S. Teoh wrote:
>
>
> One day, the realization will dawn on decision-makers that using such an outdated language in today's radically different environment from the 70's when C was designed, is a needless waste of resources. And then the inevitable will happen.
>
>
> T

I don't accept your assertion that C is outdated.

Is assembly outdated?

C should be the closest to assembly you can get, and no closer. That is the value proposition of C, in 'modern times'.

If your assertion was, instead, that there are problem domains where something other than C should be considered, then I would whole heartedly accept such an assertion. And in such domains, D is certainly worth evaluating.
November 17

On Wednesday, 17 November 2021 at 02:10:02 UTC, jmh530 wrote:

>

On Tuesday, 16 November 2021 at 22:38:13 UTC, IGotD- wrote:

>

[snip]

The Achilles heel of D and its memory management was never the GC itself or GC/not GC. It was that D didn't separate raw pointers from managed pointers as different types. If D had done that, it would have many more options.

This borrow checker implementation in D, I'm not sure what the purpose is and I don't have the whole picture either.

I'm confused by this because it seems as if the managed C++ iterations from Microsoft do not have much traction. What is the benefit of different types for GC/non-GC pointers?

They do, to the point that C++/CLI support was a major milestone for .NET Core 3.0.

C++/CLI is used on the context of native interop, its goal isn't to rewrite the world in C++, and is much easier than figuring out the right set of P/Invoke declarations.

And then since Longhorn debacle, Windows team has pushed COM everywhere as replacement for .NET ideas, so you have COM reference counting across all OS stack.

What we don't have is a developer friendly way to author COM, because politics killed C++/CX and we are back into editing IDL files, but AddRef/Release are everywhere.

1 2 3 4 5 6 7 8 9 10 11 12 13