On Friday, 21 May 2021 at 10:12:00 UTC, Paulo Pinto wrote:

D has never changed memory management, only the implementation.

That IS the issue...

On Wednesday, 19 May 2021 at 16:16:39 UTC, Guillaume Piolat wrote:

I think JUCE is largely the reason for why almost everyone starts out with C++.

Anyway, audio is an area where you have to write your own MM no matter which language, sabso it a bit atypical. If you create many similar products, then you can create you own framework with your own MM. Most dont, so then you need a solid MM for that application.

I find that the easy option for GUI on mac now is SwiftUI, implies xcode, implies C++.

If I planned to do many similar applications, then I might have considered something else...

On Friday, 21 May 2021 at 13:59:23 UTC, Ola Fosheim Grostad wrote:

Commercial audio dev was almost 100% C++ before JUCE. The plugin APIs are all C/C++, most of the hosts were/are C++. Its really nothing to do with JUCE imo.

On Friday, 21 May 2021 at 14:55:38 UTC, claptrap wrote:

But JUCE came before Rust... The point I tried to make was that there is a threshold you have to cross to get developers over to your language. People look for the easiest/most used solution. (Many audio engines are C + DSL, but that wasn't my point)

On Friday, 21 May 2021 at 13:00:54 UTC, Ola Fosheim Grostad wrote:

The issue is that D doesn't offer a wide variety of memory management options. Right now we have discussion about which GC is the best and if the GC in D is enough. Basically GC X is better than Y, which this is not about. What this is about is that D should offer the programmers a choice, a memory management that suits them whatever that is.

Right now the GC in D is one size should fit all, which it doesn't.

On Friday, 21 May 2021 at 15:15:37 UTC, Ola Fosheim Grostad wrote:

Ola is right in that choice of framework is the primary driver of language selection.
The handlful of people that chose Dplug didn't know D before.

That's why I think (sorry for turning this into another "D needs X" argument) D needs a slightly better library ecosystem to have more users ("yes you can do that in 3 lines, here are the lines"), and documentation is one way to achieve it.

JUCE has lasting power thanks to better documentation and identifiers. It's easy to overlook how much an easy API with good identifiers can lure people. I feel like this is a grave shortcoming of the Stepanov STL style.

On Friday, 21 May 2021 at 16:16:06 UTC, IGotD- wrote:

Right, but the one size GC will not scale. It has been improved over 10 years, but computers also have 8x cores and 64x memory. In another 10 years, the highend could have another 8x cores and another 64x memory. At some point we have like 64 cores and 1TB memory... At some point this type of GC will only work for small applications.

But D also needs something that is coherent. Something that can migrate between threads (possibly between CPUs in the future).

So regardless of how people feel, the concept of a task/actor is becoming more relevant. We see this on many scales, also in cloud solutions. Partioning computations and memory, making it less dependent on architecture, allows for scaling (and ultimately distributed computing).

Have you heard of a language called pony? They seem to be going in that direction.

ponylang.io/

The following is a video of a guy whose company made a nanosecond-level response time data stream processor with it. It has a task based GC, like you want.Don't know about metaprogramming though.

https://youtu.be/GigBhej1gfI

On Friday, 21 May 2021 at 17:44:51 UTC, Tejas wrote:

Yes, it is interesting, especially the type system, but it is a high level language, not a systems level language.

I believe C++ is getting tasks, their coroutines are also (at least MS implementation) switchable in nanoseconds so that you can switch to another task/coroutine while waiting for memory to be transferred to the cache. At least that it was is being claimed.

On Friday, 21 May 2021 at 17:58:59 UTC, Ola Fosheim Grostad wrote:

It turns out that Swift is going heavy in the direction of actors too.

I read some of the future direction documenation for Swift and it was pointed out that copying values is what keeps the performance down, so they are working on that, but also on concurrency.

They are switching from thread-local to task-local:

https://github.com/apple/swift-evolution/blob/main/proposals/0311-task-locals.md

Tasks and executors:

https://github.com/apple/swift-evolution/blob/main/proposals/0304-structured-concurrency.md

C++ also have things in the pipeline on concurrency/tasks/executors...

Seems like Swift and C++ are heading in the same direction then. Maybe D's main competitor will be Swift, in addition to Nim et al.