On Tuesday, 17 May 2022 at 11:53:40 UTC, zjh wrote:

It's not really endless use of memory and it does free. Depending on the strategy then it does so at different times, such as when allocating, but not enough memory has been allocated already.

The problem with GC is that the lifetime sometimes exceed what's expected.

Personally I don't have a problem with the GC.

On Tuesday, 17 May 2022 at 06:28:10 UTC, cc wrote:

Bad idea. You should only avoid GC if your profiling shows that it is bad in a specific piece of code (e.g. some inner loop that's called millions of times - the real bottlenecks). This frees you from the mental load of thinking about memory allocation at all unless it becomes necessary, which it will actually be only in very, very few places.
Better invest your precious time to really DO profiling and find out where the bottlenecks are!

Yes - and when you modularize your program, keep in mind that a module should avoid allocating anything large or often on its own at all. It should better work on memory given to it. So you remain able to decide on the calling side if you allocate by GC (default) or (if something turns out to be a bottleneck) manually allocate memory.

There's always gc.collect, which calls the maid to do her job, even if she is on vacation. Do so whenever you think you may have piled on a lot of trash and are out of house (have the time available that a collection may take). This way you can be sure there is never too much trash, so the GC is very unlikely to ever disturb you when there is no time for long collection cycles.

On Tuesday, 17 May 2022 at 11:50:30 UTC, zjh wrote:

As I've already mentioned I think the origin of GC is functional langs,
and the reason to have GC as essential part of a language is immutability,
immutability as a main principle.

Say, we have an array of 10 floats and we want to change 3rd element.
In truly functional language we can not do that - we must
produce new array in which 3rd element is changed.
Old array is now garbage, i.e. we naturally have A LOT of garbage in
functional langs.

But D as 'C/C++ with GC' still puzzles me.
Of course I know about BetterC, just have not had much time
to try this option.

On Tuesday, 17 May 2022 at 11:59:10 UTC, bauss wrote:

I am not sure if I get the sentence right,
but I've had program crash because GC
in some circumstances collects objects which
where supposed to have 'infinite' lifetime,
but were collected soon after program start.

(There was a thread in this forum started by me
where this was discussed).

And due to this I (just in case) had to write things like this:

        foreach (k; 0 .. nConnections) {
            auto sm = new WrkMachine(md, rxPool, txPool, host, port);
            wrkMachines ~= sm; // <<<<<<<
            sm.run();
        }

wrkMachines array is not needed by the program itself,
it's purpose is just to keep pointers in heap as the warranty
that GC will not collect corresponding objects.

On Tuesday, 17 May 2022 at 06:28:10 UTC, cc wrote:

Lol, what?
Don't misquote the wiki about LDC. If you can run DMD on your architecture, LDC has full support too.
The "lacking druntime/phobos support" is about architectures that are not x86, x86_64, ARM, AArch64, PowerPC, MIPS, WebAssembly. DMD supports only a subset of what LDC (and GDC) support.

-Johan

On Saturday, 21 May 2022 at 19:00:04 UTC, Johan wrote:

Forget target support, ldc runs on more architectures than dmd because it doesn't insist on using x87 all the time.

On Wednesday, 11 May 2022 at 05:41:35 UTC, Ali Çehreli wrote:

Hi Ali, thanks for asking.

Coming from C background I had problems with voldemort types. I kept wanting to know the storage type for items so that I could use it in interfaces, but that's not as big a deal anymore.

Currently my problem is integration into common tool chains in a Linux environment. On Linux the common development tools are built around gcc & gdb. The common package managers are apt and dnf. Right now I can't compile vibe.d using gdc, and I can't apt install vibe-d So I'd say lack of Linux integration is my most difficult problem using D.

I'd certainly contribute to a fund that focused on D Linux usability, namely:

1. Supporting gdc development and distribution.
2. Testing common packages against gdc
3. Updating dub so that it could assist with creating deb and yum packages
4. Having a standard GUI library (maybe).

These days the language itself is not so much of a concern. The development days for D2 are long over. What exists is excellent. I think the central focus should on libraries and integration with larger ecosystems.

On Sunday, 22 May 2022 at 19:01:41 UTC, rikki cattermole wrote:

Hats off to Iain for sure. Wish I had the resources to pay for his work, would certainly do so.

Mostly because I've put in about 15 hours effort so far trying to get a vibe.d based project to build using gdc, with no success. I'm about to give up and declare either gdc or vibe.d unsuitable for use in a large upcoming project. That's too bad really because D only has any credibility at all in my work group due to the existence of gdc, and vibe.d is a nice platform to build on.

For this item, if there was just a "dub install --prefix=" type command it would be good enough. Let the packaging tools take over from there and scoop-up the output.

Ah, if only. Let me check the couch cushions, should be a trust fund hiding in there somewhere ;)