November 17

On Wednesday, 17 November 2021 at 22:53:45 UTC, Steven Schveighoffer wrote:

>

Nothing wrong with it. It works correctly if you use it correctly.

That is a meaningless statement!

When I write assembly everything works correctly if I use it correctly.

November 17
On Wednesday, 17 November 2021 at 09:04:42 UTC, Ola Fosheim Grøstad wrote:
>
> @nogc gave those who understand system level programming a signal of direction. I don't remmber people demanding it, IIRC Walter just did it. Nobody said it was significant.


That isn't not what happened, people did demand @nogc back before it existed and considered it necessary. (I was a sceptic and am now an avid user of @nogc).

GC in D did receive many improvements over the years: @nogc, speed and space enhancements, -profile=gc... A bit surprised by the disinformation on this thread.
November 17

On Wednesday, 17 November 2021 at 01:57:23 UTC, zjh 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?.
-BetterC , of course. I just can't use it with the STD library,It's like walking on one leg.

I guess you need to just replace the leg with builtin ai (gc) for convenient walking, with manually tuned one, like https://code.dlang.org/packages/tanya

It is probably impossible to have a standard lib that satisfies necessities for entire community. Therefore it may be best if it is split in different packages each caring for a subset of community. The best case being if those modules could interoperate well between themselves.

I hope that the decision board will take the best option in current situation for future of dlang :).

Best, regards,
Alexandru.

November 17
On Wednesday, 17 November 2021 at 22:36:51 UTC, Greg Strong wrote:
> On Wednesday, 17 November 2021 at 18:47:35 UTC, Imperatorn wrote:
>> On Wednesday, 17 November 2021 at 18:09:56 UTC, Zoadian wrote:
>>> 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:
>>>>> [...]
>>>>
>>>> Why bend over backwards to please the GC-phobic crowd?  They've already made up their minds, there's no convincing them.
>>>>
>>>> [...]
>>>
>>> I 100% agree with this. There are more important things that need improvement. GC and no-GC work well enough in D (Exceptions are the only thing that needs a bit of extra work with @nogc).
>>
>> Yes, we need to focus on the bigger picture
>
> Agreed.  Trying to please everybody is a losing battle.  If the GC is so offensive to you, why are you here?  There are other languages.
>
> I'm using D to build a chess variant engine where there are recursive functions that call each other a million times a second.  I absolutely, positively cannot have any GC happening there!  No problem.  I pre-allocate what I need and I can further add @nogc to be certain.  (Which helped me because there was a place where I was doing a closure that could allocate and I didn't realize it.)
>
> ...The hysterical no-gc crowd should find another language.


> That being said, reducing GC usage in phobos is a worth goal...

You realize this particular thread of comments started with a question about being able to use Phobos without GC?..
November 17

On Wednesday, 17 November 2021 at 23:01:44 UTC, Guillaume Piolat wrote:

>

That isn't not what happened, people did demand @nogc back before it existed and considered it necessary. (I was a sceptic and am now an avid user of @nogc).

I am sorry if my memory is off, but I thought people suggested a command-line switch for nogc and that Walter came up with the idea for the attribute. I could be wrong as this is ten years ago! I never thought it was essential, let me put it that way. I thought it was a nice feature that confirmed that Walter wants programmers to view D as proper system programming language. Which is significant to what could happen down the road, but not a replacement for compiler backed no-gc memory management.

>

GC in D did receive many improvements over the years: @nogc, speed and space enhancements, -profile=gc... A bit surprised by the disinformation on this thread.

There has been many improvements, but that does not change the O(N) limitation and the fact that it essentially is a Boehm-collector like C++ has. Almost no projects use that one. And that says a lot of what system level programmers look for.

November 17

On Wednesday, 17 November 2021 at 23:01:44 UTC, Guillaume Piolat wrote:

>

That isn't not what happened, people did demand @nogc back before it existed and considered it necessary. (I was a sceptic and am now an avid user of @nogc).

To give my statement some context, this is a quote from a 2014 posting I made:

>

I got very happy when Walter announced "@nogc" and his intent to create a "better C" switch on the compiler.

>

I felt this was a nice change of direction, but I also feel that this direction has stagnated and taken a turn for the worse with the ref-counting focus… Phobos is too much of a scripting-language library to me, too much like Tango, and hacking in ref counting makes it even more so.

DIP60 was created on 2014-4-15, shortly after I had engaged in some criticism of the GC (IIRC). I saw DIP60 as a response to that, but when I search the forums I see that there have been suggestions of various kinds several years prior to this.

Now, please also understand that my view of RC/GC in D has changed since then.

November 17

On Wednesday, 17 November 2021 at 22:48:43 UTC, Ola Fosheim Grøstad wrote:

>

The hysterical no-gc crowd already found another language.

The low latency gc crowd also found another language.

And yet they still post here. It wouldn't be so bad if they posted things that made sense. They say things like "D forces you to use the GC" which is clearly nonsense. Then when someone says to use nogc, they say "But there are parts of the standard library that require GC". Which has nothing to do with their original complaint, and has absolutely nothing to do with their decision to use another language.

November 17

On Wednesday, 17 November 2021 at 23:39:18 UTC, bachmeier wrote:

>

And yet they still post here. It wouldn't be so bad if they posted things that made sense. They say things like "D forces you to use the GC" which is clearly nonsense.

If you want parity with C++ language features you have to use the GC. So that is an issue.

I've never complained about not being able to use Phobos, as I've always viewed Phobos as being too much of a high level scripting-oriented library.

Let me quote more from the same post I linked above, where I in 2014 wrote:

>

To me, a "better C" would have a minimal runtime, a tight minimalistic standard library and very simple builtin ownership semantics (uniqe_ptr). Then a set of supporting libraries that are hardware-optimized (with varying degree of portability).

>

However, I think those that are interested in D as a tight system level language have to spec out "better C" themselves as a formal language spec sketch. I'd be happy to contribute to that, maybe we could start a wiki-page. Since a "better C" would break existing code, it would allow a more "idealistic" language design discussion. I think that could cut down on the noise.

On this I still agree with myself. :-)

November 18

On Wednesday, 17 November 2021 at 23:39:18 UTC, bachmeier wrote:

>

And yet they still post here. It wouldn't be so bad if they posted things that made sense. They say things like "D forces you to use the GC" which is clearly nonsense. Then when someone says to use nogc, they say "But there are parts of the standard library that require GC". Which has nothing to do with their original complaint, and has absolutely nothing to do with their decision to use another language.

But nobody wanted nogc in 2010?

https://forum.dlang.org/post/hhjho8$1paq$1@digitalmars.com

November 18

On Wednesday, 17 November 2021 at 23:06:01 UTC, Alexandru Ermicioi wrote:

>

for convenient walking, with manually tuned one, like https://code.dlang.org/packages/tanya

If the d core maintainer could support one,that's Good.

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