www.digitalmars.com         C & C++   DMDScript  

digitalmars.D - Tasks, actors and garbage collection

reply Ola Fosheim =?UTF-8?B?R3LDuHN0YWQ=?= <ola.fosheim.grostad gmail.com> writes:
As computer memory grows, naive scan and sweep garbage collection 
becomes more and more a burden.

Also, languages have not really come up with a satisfactory way 
to simplify multi-threaded programming, except to split the 
workload into many single-threaded tasks that are run in parallel.

It seems to me that the obvious way to retain the easy of use 
that garbage collection provides without impeding performance is 
to limit the memory to scan, and preferably do the scanning when 
nobody is using the memory.

The actor model seems to be a good fit. Or call it a task, if you 
wish. If each actor/task has it's own GC pool then there is less 
memory to scan, and you can do the scanning when the actor/task 
is waiting on I/O or scheduling. So you would get less intrusive 
scanning pauses. It would also fit well with async-await/futures.

Another benefit is that if an actor is deleted before it is 
scanned, then no scanning is necessary at all. It can simply be 
released (assuming destructor-free classes are allocated in a 
separate area). This is of great benefit to web-services, they 
can simply implement a request-handler as an actor/task.

The downside is that you need a non-GC mechanism for dealing with 
inter-actor/task communication. Such as reference counting, 
however that should be quite ok, as you would expect the 
time-consuming stuff to happen within an actor/task as well as 
complex allocation patterns.

Is this a direction D is able to move in or is a new language 
needed?
Apr 20
next sibling parent reply Petar Kirov [ZombineDev] <petar.p.kirov gmail.com> writes:
On Tuesday, 20 April 2021 at 09:52:07 UTC, Ola Fosheim Grøstad 
wrote:
 As computer memory grows, naive scan and sweep garbage 
 collection becomes more and more a burden.

 Also, languages have not really come up with a satisfactory way 
 to simplify multi-threaded programming, except to split the 
 workload into many single-threaded tasks that are run in 
 parallel.

 It seems to me that the obvious way to retain the easy of use 
 that garbage collection provides without impeding performance 
 is to limit the memory to scan, and preferably do the scanning 
 when nobody is using the memory.

 The actor model seems to be a good fit. Or call it a task, if 
 you wish. If each actor/task has it's own GC pool then there is 
 less memory to scan, and you can do the scanning when the 
 actor/task is waiting on I/O or scheduling. So you would get 
 less intrusive scanning pauses. It would also fit well with 
 async-await/futures.

 Another benefit is that if an actor is deleted before it is 
 scanned, then no scanning is necessary at all. It can simply be 
 released (assuming destructor-free classes are allocated in a 
 separate area). This is of great benefit to web-services, they 
 can simply implement a request-handler as an actor/task.

 The downside is that you need a non-GC mechanism for dealing 
 with inter-actor/task communication. Such as reference 
 counting, however that should be quite ok, as you would expect 
 the time-consuming stuff to happen within an actor/task as well 
 as complex allocation patterns.

 Is this a direction D is able to move in or is a new language 
 needed?
A few years ago, when [`std.experimental.allocator`][0] was still hot out of the oven, I considered that this would one of primary innovations that it would enable. The basic idea is that since allocators are composable first-class objects, you can pass them to any function and that way you can override and customize its memory allocation policy, without resorting to global variables. (The package does provide convenience [thread-local][1] and [global variables][2], but IMO that's an anti-pattern, as if you prefer the simplicity, you can either use the GC (as always), or `MAllocator` directly. IMO, if you're reaching for `std.experimental.allocator`, you do so, in order to gain more control over the memory management. Also knowing whether `theAllocator` points to `GCAllocator`, or an actually separate thread-local allocator, can be critical for ensuring that code is lock-free. You either know what you're doing, or the code is not performance critical, so it doesn't matter, and you should be using the GC anyway.) By passing the allocator as an object, you allow it to be used safely from `pure` functions. (If `pure` functions were to somehow be allowed to use those global allocator variables, you could have some ugly consequences. For example, a pure function can be preempted in the middle of its execution, only to have the global allocator replaced under its feet, thereby leaving all the memory allocated from the previous allocator dangling.) Pure code (even in the relaxed D sense) is great for parallelism, as a scheduler can essentially assume that it's both lock-free and wait-free - it doesn't need to interact with any other thread/fiber/task to make progress. Having multiple per thread/fiber/actor/task GC heaps fits naturally in the model you propose. There could be a new LocalGCAllocator, which the runtime / framework can simply pass to the actor on its creation. There two main challenges: 1. Ensuring code doesn't brake the assumptions of the actor model by e.g. sharing memory between threads in an uncontrolled manner. This can be addressed in a variety of ways: * The framework's build-system can prevent you from importing code that doesn't fit its model * The framework can run a non-optional linter as part of the build process, which would ensure that you don't have: * ` system` or ` trusted` code * `extern` function declarations (otherwise you could define ` safe pure int printf(scope const char* format, scope const ...);`) * reference capabilities like [Pony][3]'s * other type-system or language built-in static analysis 2. Making it ergonomic and easy to use, as is using the GC. Essentially having all language and library features that currently require the GC use `LocalGCAllocator` automagically. I think this can be done in several steps: * Finish transitioning druntime's compiler interface from unchecked "magic" extern(C) functions to regular D (template) functions * Add `context` as the last parameter to each of druntime function that may need to allocate memory set it's default value to the global GC context. This is a pure refactoring, no change in behavior. * Add Scala `implicit` parameters [⁴][4] [⁵][5] [⁶][6] [⁷][7] [⁸][8] to the language and mark the `context` parameters as `implicit` [0]: https://dlang.org/phobos/std_experimental_allocator.html [1]: https://dlang.org/phobos/std_experimental_allocator.html#theAllocator [2]: https://dlang.org/phobos/std_experimental_allocator.html#.processAllocator [3]: https://tutorial.ponylang.io/reference-capabilities/reference-capabilities.html [4]: https://scala-lang.org/files/archive/spec/2.13/07-implicits.html#implicit-parameters [5]: https://docs.scala-lang.org/tour/implicit-parameters.html [6]: https://docs.scala-lang.org/tutorials/FAQ/finding-implicits.html [7]: https://stackoverflow.com/questions/10375633/understanding-implicit-in-scala [8]: https://dzone.com/articles/scala-implicits-presentations
Apr 20
next sibling parent Ola Fosheim =?UTF-8?B?R3LDuHN0YWQ=?= <ola.fosheim.grostad gmail.com> writes:
On Tuesday, 20 April 2021 at 16:21:39 UTC, Petar Kirov 
[ZombineDev] wrote:
 By passing the allocator as an object, you allow it to be used 
 safely from `pure` functions. (If `pure` functions were to 
 somehow be allowed to use those global allocator variables, you 
 could have some ugly consequences. For example, a pure function 
 can be preempted in the middle of its execution, only to have 
 the global allocator replaced under its feet, thereby leaving 
 all the memory allocated from the previous allocator dangling.)
Yes, but I think it is too tedious to pass around allocators. Having a global user-modified variable is also not good for static analysis. I think a Task ought to be a compiler construct, or at least a language-runtime-construct. It might be desirable to have different types of Tasks, like one that is GC based and another type that is more like C++. Then the compiler need to keep tabs of the call-tree and ensure that only a GC call-tree allows a regular pointer to own a new object. And shared pointers could always be owning (possibly RC-based) unless some kind of borrowing scheme is implemented.
 Pure code (even in the relaxed D sense) is great for 
 parallelism, as a scheduler can essentially assume that it's 
 both lock-free and wait-free - it doesn't need to interact with 
 any other thread/fiber/task to make progress.
I guess that could be useful. How would it affect scheduling?
 There two main challenges:
 1. Ensuring code doesn't brake the assumptions of the actor 
 model by e.g. sharing memory between threads in an uncontrolled 
 manner. This can be addressed in a variety of ways:
     * The framework's build-system can prevent you from 
 importing code that doesn't fit its model
Hm, what implications are you thinking of that are different from what D has to deal with under the current scheme? Are you thinking about coexisting with the current regime of having a global GC as a transition, perhaps?
     * The framework can run a non-optional linter as part of 
 the build process, which would ensure that you don't have:
         * ` system` or ` trusted` code
But you should be able to call trusted? Or maybe have a different mechanism like unsafe.
     * reference capabilities like [Pony][3]'s
Yes, I think being able to transition a shared object with a refcount of 1 into a GC-owned non-shared object could be desirable.
 2. Making it ergonomic and easy to use, as is using the GC. 
 Essentially having all language and library features that 
 currently require the GC use `LocalGCAllocator` automagically.
Yes, I think you either have a thread local current_task pointer or have a dedicated hardware-register point to the current task. (implementation defined)
     * Add `context` as the last parameter to each of druntime 
 function that may need to allocate memory set it's default 
 value to the global GC context. This is a pure refactoring, no 
 change in behavior.
I guess an alternative would be to transition to a new runtime. Then code that depends on the current runtime will have to be rewritten to work with the new regime, and compilation failure would protect mistakes from going unnoticed. Or, if a transition is needed, then I guess each runtime could assert that it isn't called from a task call-tree (check a thread local variable).
     * Add Scala `implicit` parameters [⁴][4] [⁵][5] [⁶][6] 
 [⁷][7] [⁸][8] to the language and mark the `context` parameters 
 as `implicit`
The FAQ on implicits was long... maybe it is a language design mistake? :-) Ola.
Apr 20
prev sibling parent Ola Fosheim =?UTF-8?B?R3LDuHN0YWQ=?= <ola.fosheim.grostad gmail.com> writes:
On Tuesday, 20 April 2021 at 16:21:39 UTC, Petar Kirov 
[ZombineDev] wrote:
     * The framework can run a non-optional linter as part of 
 the build process, which would ensure that you don't have:
         * ` system` or ` trusted` code
Just want to add that there should be imposed some constraints on what can execute as safe code in a task so that one can get fully precise garbage collection and over time add compaction. I guess untagged unions is the main source for imprecision. One might also want to prevent non-safe code from allocating GC objects so that all code that is GC-relevant is checked properly by the compiler.
Apr 20
prev sibling next sibling parent reply russhy <russhy gmail.com> writes:
GC is not the right model if you don't have the same ressources 
as Microsoft / Google / Oracle to invest massively on GC R&D, 
there is no way D can comepte with the latest Java's sub 1ms GC, 
no way

IMHO, Apple made the right decision to go with a RC with Swift, 
like they did with Obj-C

D's future is with memory ownership / reference counting

The more we stick to the GC, the more we'll have to play catchup 
with the competition

Even GO's GC is starting to become a negative amongst certain 
users 
https://blog.discord.com/why-discord-is-switching-from-go-to-rust-a190bbca2b1f


We need to transition to RC instead of GC, the sooner, the better

I know people like the GC, i do too, but in its current state it 
is absolute garbage when you compare to the competition

Again, the more we fill the STD library with GC code, the faster 
we'll get shadowed by the competition
Apr 20
next sibling parent reply russhy <russhy gmail.com> writes:
It is very sad because it is the same discussion, every weeks, 
every months, every years

People agree that GC is trash, and yet no action done to improve 
things

I reiterate, i know i choose strong words, it's on purpose

D 3.0 needs to happen, with a GC-free features/std

That's the only way to be future proof and pragmatic


How many people who wrote the GC dependent std are still here 
using D? i bet close to 5%

They made D unusable for some workloads, and they made it 
dependent on very bad GC implementation, the wrong memory model 
when you advertise yourself as being a "system language"


D with core.stdc is the best version of D

Add traits/signature system and RC and you'll have a very capable 
and pragmatic system language

Simpler than to come up with 15151 different GC implementation 
with 2618518 different config options to waste months tweaking 
them *cough* JVM *cough*
Apr 20
parent reply russhy <russhy gmail.com> writes:
And please note that i never said GC hinders the language 
adoption! because i never believed in that argument, it is a 
distraction from the real core issue, the memory model, when it 
is confusing, when it is not efficient, when it doesn't scale, at 
the end of the day, you'll have to pay for it

Being pragmatic about it like Swift and the issues related to 
scaling disappear "automagically", because you no longer depend 
on a Death Aura that could trigger at any time 'when allocating 
with new or via gc-dependent language features *cough* AA *cough* 
dynamic array *cough* exceptions *cough* asserts', blocking your 
whole world
Apr 20
parent reply russhy <russhy gmail.com> writes:
And no, no   could save us

```D
 safe  system  pure  nogc  noreturn  help  nothrow void 
doSomethingForMePlease()
{
    writeln("is this where we want to go?");
}

```
Apr 20
next sibling parent reply russhy <russhy gmail.com> writes:
C++ could have went with a GC, they decided to go against and 
encourage the use of smart pointers

That was smart, actually
Apr 20
next sibling parent reply russhy <russhy gmail.com> writes:
On Tuesday, 20 April 2021 at 16:45:38 UTC, russhy wrote:
 C++ could have went with a GC, they decided to go against and 
 encourage the use of smart pointers

 That was smart, actually
Well not that smart, but smarter then enforcing a GC into the language, because the std, even if trash, doesn't depend on anything, and gives you the option to supply an IAllocator almost all the time, zig does that too, and it is very nice
Apr 20
parent evilrat <evilrat666 gmail.com> writes:
On Tuesday, 20 April 2021 at 17:08:17 UTC, russhy wrote:
 On Tuesday, 20 April 2021 at 16:45:38 UTC, russhy wrote:
 C++ could have went with a GC, they decided to go against and 
 encourage the use of smart pointers

 That was smart, actually
Well not that smart, but smarter then enforcing a GC into the language, because the std, even if trash, doesn't depend on anything, and gives you the option to supply an IAllocator almost all the time, zig does that too, and it is very nice
GC isn't real, it can't hurt you.
Apr 20
prev sibling parent reply Paulo Pinto <pjmlp progtools.org> writes:
On Tuesday, 20 April 2021 at 16:45:38 UTC, russhy wrote:
 C++ could have went with a GC, they decided to go against and 
 encourage the use of smart pointers

 That was smart, actually
Kind of, there are C++/CLI, C++/CX, C++ Builder and what many keep forgeting when talking about game developers and tracing GC, Unreal C++. Also in regards to Objective-C and Swift, Objective-C did went with a tracing GC, the pivot into RC as compiler assisted help for Cocoa retain/release patterns, only happend due to C's memory model borking the whole idea. https://developer.apple.com/library/archive/documentation/Cocoa/Conceptual/GarbageCollection/Introduction.html Swift naturally needed to use the same model, otherwise a translation layer like .NET RCW for COM would be needed had they gone with tracing GC.
Apr 20
next sibling parent reply Ola Fosheim =?UTF-8?B?R3LDuHN0YWQ=?= <ola.fosheim.grostad gmail.com> writes:
On Wednesday, 21 April 2021 at 06:37:21 UTC, Paulo Pinto wrote:
 On Tuesday, 20 April 2021 at 16:45:38 UTC, russhy wrote:
 C++ could have went with a GC, they decided to go against and 
 encourage the use of smart pointers

 That was smart, actually
Kind of, there are C++/CLI, C++/CX, C++ Builder and what many keep forgeting when talking about game developers and tracing GC, Unreal C++.
Yes, but C++ has had the Boehm collector since the early 90s, which is comparable to D's current default collector. There is also C++11 N2670 ("Garbage Collection and Reachability-Based Leak Detection") that has no compiler support, but actually is in the language. Garbage collection simply isn't widespread in C++ as the main allocation strategy, but it is in D. The demographics are different.
Apr 21
parent reply Paulo Pinto <pjmlp progtools.org> writes:
On Wednesday, 21 April 2021 at 08:09:17 UTC, Ola Fosheim Grøstad 
wrote:
 On Wednesday, 21 April 2021 at 06:37:21 UTC, Paulo Pinto wrote:
 On Tuesday, 20 April 2021 at 16:45:38 UTC, russhy wrote:
 C++ could have went with a GC, they decided to go against and 
 encourage the use of smart pointers

 That was smart, actually
Kind of, there are C++/CLI, C++/CX, C++ Builder and what many keep forgeting when talking about game developers and tracing GC, Unreal C++.
Yes, but C++ has had the Boehm collector since the early 90s, which is comparable to D's current default collector. There is also C++11 N2670 ("Garbage Collection and Reachability-Based Leak Detection") that has no compiler support, but actually is in the language. Garbage collection simply isn't widespread in C++ as the main allocation strategy, but it is in D. The demographics are different.
None of the examples I gave use the pre-historic Boehm collector. Also no one cares about C++11 N2670, because the above mentioned examples already had their own solutions, and aren't going to rewrite them, because it was a compromise not capable to do what those dialects were already offering, so much that C++11 N2670 is voted for removal in ISO C++23.
Apr 21
parent reply Ola Fosheim =?UTF-8?B?R3LDuHN0YWQ=?= <ola.fosheim.grostad gmail.com> writes:
On Wednesday, 21 April 2021 at 09:23:06 UTC, Paulo Pinto wrote:
 None of the examples I gave use the pre-historic Boehm 
 collector.
That doesn't change the fact that D's current default collector is comparable to Boehm. I don't know anything about C++/CX, but wikipedia says: «A WinRT object is reference counted and thus handles similarly to ordinary C++ objects enclosed in shared_ptrs. An object will be deleted when there are no remaining references that lead to it. There is no garbage collection involved.» https://en.wikipedia.org/wiki/C%2B%2B/CX
Apr 21
parent reply Paulo Pinto <pjmlp progtools.org> writes:
On Wednesday, 21 April 2021 at 09:47:32 UTC, Ola Fosheim Grøstad 
wrote:
 On Wednesday, 21 April 2021 at 09:23:06 UTC, Paulo Pinto wrote:
 None of the examples I gave use the pre-historic Boehm 
 collector.
That doesn't change the fact that D's current default collector is comparable to Boehm. I don't know anything about C++/CX, but wikipedia says: «A WinRT object is reference counted and thus handles similarly to ordinary C++ objects enclosed in shared_ptrs. An object will be deleted when there are no remaining references that lead to it. There is no garbage collection involved.» https://en.wikipedia.org/wiki/C%2B%2B/CX
Reference counting is GC.
Apr 21
parent reply Ola Fosheim =?UTF-8?B?R3LDuHN0YWQ=?= <ola.fosheim.grostad gmail.com> writes:
On Wednesday, 21 April 2021 at 09:50:53 UTC, Paulo Pinto wrote:
 Reference counting is GC.
Not in the context of this thread.
Apr 21
parent Paulo Pinto <pjmlp progtools.org> writes:
On Wednesday, 21 April 2021 at 10:04:44 UTC, Ola Fosheim Grøstad 
wrote:
 On Wednesday, 21 April 2021 at 09:50:53 UTC, Paulo Pinto wrote:
 Reference counting is GC.
Not in the context of this thread.
I only care about computer science context.
Apr 21
prev sibling parent reply russhy <russhy gmail.com> writes:
 Kind of, there are C++/CLI, C++/CX, C++ Builder and what many 
 keep forgeting when talking about game developers and tracing 
 GC, Unreal C++.
It is so good that unreal developers are all working around the GC ;) Just like the unity peeps, everyone workaround the GC with ugly hacks and ugly code
Apr 21
next sibling parent Paulo Pinto <pjmlp progtools.org> writes:
On Wednesday, 21 April 2021 at 11:14:39 UTC, russhy wrote:
 Kind of, there are C++/CLI, C++/CX, C++ Builder and what many 
 keep forgeting when talking about game developers and tracing 
 GC, Unreal C++.
It is so good that unreal developers are all working around the GC ;) Just like the unity peeps, everyone workaround the GC with ugly hacks and ugly code
I bet D wouldn't mind to have 1% of the market share they enjoy across the games industry, AR/VR devices and independt movie industry, including not so successful movies like Mandalorian. But that is just me.
Apr 21
prev sibling parent Ola Fosheim =?UTF-8?B?R3LDuHN0YWQ=?= <ola.fosheim.grostad gmail.com> writes:
On Wednesday, 21 April 2021 at 11:14:39 UTC, russhy wrote:
 It is so good that unreal developers are all working around the 
 GC ;)

 Just like the unity peeps, everyone workaround the GC with ugly 
 hacks and ugly code
And that is a good reason to compartmentalize the GC so that it only affects one task on one thread if it kicks in. Hopefully one can write code that is segmented into many smaller tasks that bypass collection altogheter. And if you can't, then write a GC-less task. Anyway, dedicated specialized GCs are not relevant to the discussion. Chrome also has a GC, again, it is specialized and not relevant.
Apr 21
prev sibling next sibling parent reply Stefan Koch <uplink.coder googlemail.com> writes:
On Tuesday, 20 April 2021 at 16:44:01 UTC, russhy wrote:
 And no, no   could save us

 ```D
  safe  system  pure  nogc  noreturn  help  nothrow void 
 doSomethingForMePlease()
 {
    writeln("is this where we want to go?");
 }

 ```
Invalid safe and system contradict each other. Also noreturn is not an annotation it's a type. pure and nothrow are not annotations either they are keywords, though they arguably should be an annotations.
Apr 20
parent russhy <russhy gmail.com> writes:
On Tuesday, 20 April 2021 at 17:09:48 UTC, Stefan Koch wrote:
 On Tuesday, 20 April 2021 at 16:44:01 UTC, russhy wrote:
 And no, no   could save us

 ```D
  safe  system  pure  nogc  noreturn  help  nothrow void 
 doSomethingForMePlease()
 {
    writeln("is this where we want to go?");
 }

 ```
Invalid safe and system contradict each other. Also noreturn is not an annotation it's a type. pure and nothrow are not annotations either they are keywords, though they arguably should be an annotations.
That's the point of the joke, all looks the same, they adds, and things becomes confusing/visual noise
Apr 20
prev sibling parent reply Per =?UTF-8?B?Tm9yZGzDtnc=?= <per.nordlow gmail.com> writes:
On Tuesday, 20 April 2021 at 16:44:01 UTC, russhy wrote:
 ```D
  safe  system  pure  nogc  noreturn  help  nothrow void

 ```
IMO, it's the lack of attribute inference that's the problem not the (implicit) presence of attributes.
Apr 25
parent reply russhy <russhy gmail.com> writes:
On Sunday, 25 April 2021 at 10:39:01 UTC, Per Nordlöw wrote:
 On Tuesday, 20 April 2021 at 16:44:01 UTC, russhy wrote:
 ```D
  safe  system  pure  nogc  noreturn  help  nothrow void

 ```
IMO, it's the lack of attribute inference that's the problem not the (implicit) presence of attributes.
This is none of that, it's people bloating the language Language should stay simple, and people can come up with what ever library they want If people love bloat, they should keep it in their own libraries and let the language simple GC is perfect example of this, it should have been a library
Apr 25
parent reply evilrat <evilrat666 gmail.com> writes:
On Sunday, 25 April 2021 at 17:35:36 UTC, russhy wrote:
 On Sunday, 25 April 2021 at 10:39:01 UTC, Per Nordlöw wrote:
 On Tuesday, 20 April 2021 at 16:44:01 UTC, russhy wrote:
 ```D
  safe  system  pure  nogc  noreturn  help  nothrow void

 ```
IMO, it's the lack of attribute inference that's the problem not the (implicit) presence of attributes.
This is none of that, it's people bloating the language Language should stay simple, and people can come up with what ever library they want If people love bloat, they should keep it in their own libraries and let the language simple GC is perfect example of this, it should have been a library
We already have zig and rust, adding yet another fancy slick no GC landuage is dead end. Take it from D and there is no point to stay here. and stuff just not as that friendly like D and requires more boilerplate, but again that could be automated. So please stop your no-GC whine. People already heard you, more than once too.
Apr 25
parent reply russhy <russhy gmail.com> writes:
 We already have zig and rust, adding yet another fancy slick no 
 GC landuage is dead end.
Same defeatist mentality i keep reading here, this is not what D need
 So please stop your no-GC whine. People already heard you, more 
 than once too.
I will never stop fighting for D from the people who wants to ruin it with more GC
Apr 25
next sibling parent reply Imperatorn <johan_forsberg_86 hotmail.com> writes:
On Sunday, 25 April 2021 at 19:41:39 UTC, russhy wrote:
 We already have zig and rust, adding yet another fancy slick 
 no GC landuage is dead end.
Same defeatist mentality i keep reading here, this is not what D need
 So please stop your no-GC whine. People already heard you, 
 more than once too.
I will never stop fighting for D from the people who wants to ruin it with more GC
I don't think ppl are saying "want more gc" per se, just don't remove it. I think there's a difference.
Apr 25
parent reply russhy <russhy gmail.com> writes:
On Sunday, 25 April 2021 at 19:57:53 UTC, Imperatorn wrote:
 On Sunday, 25 April 2021 at 19:41:39 UTC, russhy wrote:
 We already have zig and rust, adding yet another fancy slick 
 no GC landuage is dead end.
Same defeatist mentality i keep reading here, this is not what D need
 So please stop your no-GC whine. People already heard you, 
 more than once too.
I will never stop fighting for D from the people who wants to ruin it with more GC
I don't think ppl are saying "want more gc" per se, just don't remove it. I think there's a difference.
it needs to be removed and put as a library so language features doesn't depend on the library i don't want to stick with core.stdc and stick with a language that only get new features for the people who rely on the GC
Apr 25
next sibling parent Imperatorn <johan_forsberg_86 hotmail.com> writes:
On Sunday, 25 April 2021 at 20:02:32 UTC, russhy wrote:
 On Sunday, 25 April 2021 at 19:57:53 UTC, Imperatorn wrote:
 On Sunday, 25 April 2021 at 19:41:39 UTC, russhy wrote:
 [...]
Same defeatist mentality i keep reading here, this is not what D need
 [...]
I will never stop fighting for D from the people who wants to ruin it with more GC
I don't think ppl are saying "want more gc" per se, just don't remove it. I think there's a difference.
it needs to be removed and put as a library so language features doesn't depend on the library i don't want to stick with core.stdc and stick with a language that only get new features for the people who rely on the GC
I kinda agree, but I think it would be quite some work to make that happen.
Apr 25
prev sibling next sibling parent Ola Fosheim =?UTF-8?B?R3LDuHN0YWQ=?= <ola.fosheim.grostad gmail.com> writes:
On Sunday, 25 April 2021 at 20:02:32 UTC, russhy wrote:
 it needs to be removed and put as a library

 so language features doesn't depend on the library
That has nothing to do with this thread. In order to have GC support you need compiler support, obviously.
Apr 25
prev sibling parent reply Dominikus Dittes Scherkl <dominikus scherkl.de> writes:
On Sunday, 25 April 2021 at 20:02:32 UTC, russhy wrote:
 it needs to be removed and put as a library

 so language features doesn't depend on the library
I can't even agree with that. Simply creating arrays and exceptions make prototyping so much faster and more convenient with a GC, I will never miss that again. And after profiling there are almost never more than a very few inner loops where removing the GC is a performance gain - so I turn it of in those few places and do the manual memory management (which at least is feasible if it is only about few objects) and have both: fast development time and fast execution time. Why would anyone ever want to change this? In fact: it doesn't matter if the GC is slow and imperfect. 90% of the code is executed so rarely that bad GC just has no measurable effect. And in the remaining 10% you can turn it off.
Apr 26
parent Ola Fosheim =?UTF-8?B?R3LDuHN0YWQ=?= <ola.fosheim.grostad gmail.com> writes:
On Monday, 26 April 2021 at 11:33:48 UTC, Dominikus Dittes 
Scherkl wrote:
 In fact: it doesn't matter if the GC is slow and imperfect. 90% 
 of the code is executed so rarely that bad GC just has no 
 measurable effect. And in the remaining 10% you can turn it off.
Well, it does matter if you have to halt 8-32 threads when scanning all memory that may contain pointers. If that is the only option then automatic reference counting with optimization is a better choice, but I think a mix of task-local GC og global RC (with optimization) is a reasonable trade-off.
Apr 26
prev sibling parent reply Paulo Pinto <pjmlp progtools.org> writes:
On Sunday, 25 April 2021 at 19:41:39 UTC, russhy wrote:
 We already have zig and rust, adding yet another fancy slick 
 no GC landuage is dead end.
Same defeatist mentality i keep reading here, this is not what D need
 So please stop your no-GC whine. People already heard you, 
 more than once too.
I will never stop fighting for D from the people who wants to ruin it with more GC
D is open source, you are free to take care of your special flavoured D.
Apr 25
next sibling parent reply evilrat <evilrat666 gmail.com> writes:
On Monday, 26 April 2021 at 06:35:25 UTC, Paulo Pinto wrote:
 On Sunday, 25 April 2021 at 19:41:39 UTC, russhy wrote:
 We already have zig and rust, adding yet another fancy slick 
 no GC landuage is dead end.
Same defeatist mentality i keep reading here, this is not what D need
 So please stop your no-GC whine. People already heard you, 
 more than once too.
I will never stop fighting for D from the people who wants to ruin it with more GC
D is open source, you are free to take care of your special flavoured D.
There is already Volt language, and Odin and Zig languages which is very D inspired and "simple" compared to D, there is a lot to choose from. But Take GC from D and you get C2 language (guess where it is now? oh I've heard they given up and started C3 language which is even better than C2, fantastic!), and there was even more "simple" C-- (C minus minus) language, but can you guess where it is now? Or maybe he want to repeat Python 2 vs 3 story? That was almost killed entire language. D just can't afford switching direction amid its course. But what if this really necessary? Ok, why not, just put it under a new name. But don't touch the original. That guy teaches us about how bad GC is and provides nonsensical examples of how brave developers avoid GC by all means because of just how evil it is, meanwhile Unity have been working just fine on mobile for 10+ years, and UE4 works just fine (CPU performance wise) on average 4 years old smartphone. I also like how he hijacked the thread and expects answers from Walter and Andrey who never showed up in the thread. He demands from them make something because he wanted it. That's definitely not going to work. If he is so serious about reducing GC dependency he could probably start patching phobos with no-GC functionality to be on par, that would be at least useful, but in the long run it will just add clutter, technical debt and bloat(omg!). To make phobos usable with nogc it would need some serious rethinking, research and planning. It is not just "remove GC" and done, this will require adding monads and stuff, pattern matching, and more. The result will probably end up look like Rust too.
Apr 26
parent reply russhy <russhy gmail.com> writes:
On Monday, 26 April 2021 at 09:22:12 UTC, evilrat wrote:
 On Monday, 26 April 2021 at 06:35:25 UTC, Paulo Pinto wrote:
 On Sunday, 25 April 2021 at 19:41:39 UTC, russhy wrote:
 We already have zig and rust, adding yet another fancy slick 
 no GC landuage is dead end.
Same defeatist mentality i keep reading here, this is not what D need
 So please stop your no-GC whine. People already heard you, 
 more than once too.
I will never stop fighting for D from the people who wants to ruin it with more GC
D is open source, you are free to take care of your special flavoured D.
There is already Volt language, and Odin and Zig languages which is very D inspired and "simple" compared to D, there is a lot to choose from. But Take GC from D and you get C2 language (guess where it is now? oh I've heard they given up and started C3 language which is even better than C2, fantastic!), and there was even more "simple" C-- (C minus minus) language, but can you guess where it is now? Or maybe he want to repeat Python 2 vs 3 story? That was almost killed entire language. D just can't afford switching direction amid its course. But what if this really necessary? Ok, why not, just put it under a new name. But don't touch the original. That guy teaches us about how bad GC is and provides nonsensical examples of how brave developers avoid GC by all means because of just how evil it is, meanwhile Unity have been working just fine on mobile for 10+ years, and UE4 works just fine (CPU performance wise) on average 4 years old smartphone. I also like how he hijacked the thread and expects answers from Walter and Andrey who never showed up in the thread. He demands from them make something because he wanted it. That's definitely not going to work. If he is so serious about reducing GC dependency he could probably start patching phobos with no-GC functionality to be on par, that would be at least useful, but in the long run it will just add clutter, technical debt and bloat(omg!). To make phobos usable with nogc it would need some serious rethinking, research and planning. It is not just "remove GC" and done, this will require adding monads and stuff, pattern matching, and more. The result will probably end up look like Rust too.
Again, this shows how little you know UE4 GC is fine if you make a hello world, ask every studios what they have to do to workaround the GC, they wish it didn't exist, and Epic is working on ditching the GC with their upcoming data oriented stack, just like Unity is working on ditching the GC So little do you know that it makes people believe GC is fine This is why we can't have nice things, and this is why people are coming up with new languages instead of embracing Dlang, you guys make bad press for D, you are not pragmatic enough and i never said ditch the GC, you do what ever you want, but the language shouldn't expect you to use a GC, it should expect you to provide what ever allocator is proper for the task
Apr 26
next sibling parent reply russhy <russhy gmail.com> writes:
Or maybe he want to repeat Python 2 vs 3 story? That was almost 
killed entire language.
Python3 is what saved Python Its problem were the same people as you, the people who refuses to understand what is wrong with the language Now python3 is experiencing a new youth, thanks to the people who decided it was time to start fresh for more decades of growing user adoption
Apr 26
parent reply russhy <russhy gmail.com> writes:
  meanwhile Unity have been working just fine on mobile for 10+ 
 years
LOL, wonder how it works fine on mobile? by avoiding the GC and doing manual memory management (object pooling -- aka custom allocators) Woawoawoa, who would have thought that Unity recomands to avoid the GC in order to gain stable perf on device constrained devices, woawoaw Same goes for Unreal What have you done with D, other than cli tools?
Apr 26
parent reply Paulo Pinto <pjmlp progtools.org> writes:
On Monday, 26 April 2021 at 13:51:29 UTC, russhy wrote:
  meanwhile Unity have been working just fine on mobile for 
 10+ years
LOL, wonder how it works fine on mobile? by avoiding the GC and doing manual memory management (object pooling -- aka custom allocators) Woawoawoa, who would have thought that Unity recomands to avoid the GC in order to gain stable perf on device constrained devices, woawoaw Same goes for Unreal What have you done with D, other than cli tools?
Android seems to be doing just fine with its 80% world wide market share. And ChromeOS isn't doing badly in US school market.
Apr 26
parent reply russhy <russhy gmail.com> writes:
On Monday, 26 April 2021 at 14:48:23 UTC, Paulo Pinto wrote:
 On Monday, 26 April 2021 at 13:51:29 UTC, russhy wrote:
  meanwhile Unity have been working just fine on mobile for 
 10+ years
LOL, wonder how it works fine on mobile? by avoiding the GC and doing manual memory management (object pooling -- aka custom allocators) Woawoawoa, who would have thought that Unity recomands to avoid the GC in order to gain stable perf on device constrained devices, woawoaw Same goes for Unreal What have you done with D, other than cli tools?
Android seems to be doing just fine with its 80% world wide market share. And ChromeOS isn't doing badly in US school market.
Yeah that is why nobody uses D for android apps And that is why nobody uses D for ChromeOS And that is why nobody uses D for gamedev and the list continues -- That is also why Android apps require 2x the amount of memory/cpu/battery than equivalent on iOS Sure GC is fine, if your quality standard is bellow 0
Apr 26
parent reply Paulo Pinto <pjmlp progtools.org> writes:
On Monday, 26 April 2021 at 15:29:22 UTC, russhy wrote:
 On Monday, 26 April 2021 at 14:48:23 UTC, Paulo Pinto wrote:
 On Monday, 26 April 2021 at 13:51:29 UTC, russhy wrote:
 [...]
Android seems to be doing just fine with its 80% world wide market share. And ChromeOS isn't doing badly in US school market.
Yeah that is why nobody uses D for android apps And that is why nobody uses D for ChromeOS And that is why nobody uses D for gamedev and the list continues -- That is also why Android apps require 2x the amount of memory/cpu/battery than equivalent on iOS Sure GC is fine, if your quality standard is bellow 0
They use Java, JavaScript and Unity, do you know what they have in common with D?
Apr 26
parent reply russhy <russhy gmail.com> writes:
On Tuesday, 27 April 2021 at 06:09:25 UTC, Paulo Pinto wrote:
 On Monday, 26 April 2021 at 15:29:22 UTC, russhy wrote:
 On Monday, 26 April 2021 at 14:48:23 UTC, Paulo Pinto wrote:
 On Monday, 26 April 2021 at 13:51:29 UTC, russhy wrote:
 [...]
Android seems to be doing just fine with its 80% world wide market share. And ChromeOS isn't doing badly in US school market.
Yeah that is why nobody uses D for android apps And that is why nobody uses D for ChromeOS And that is why nobody uses D for gamedev and the list continues -- That is also why Android apps require 2x the amount of memory/cpu/battery than equivalent on iOS Sure GC is fine, if your quality standard is bellow 0
They use Java, JavaScript and Unity, do you know what they have in common with D?
Yeah, they all use the GC and they they work hard to avoid it like the plague the GC, sure, they use C++ for scripting only
Apr 27
parent reply russhy <russhy gmail.com> writes:
And at least with Unreal, since it is using C++, you are not 
forced to stick with the GC all the time

With unity, they had to come up with a special language to 

are forced to stick with the GC no matter what


So yes i want D to be as pragmatic as C++



that leads


Oh and guess why android smart watches sucks compared to apple 
watch (perf/battery life)?, yes i know you know why
Apr 27
next sibling parent Mike Parker <aldacron gmail.com> writes:
On Tuesday, 27 April 2021 at 12:01:33 UTC, russhy wrote:

 So yes i want D to be as pragmatic as C++
D is a GC'ed language. Period. You're tilting at windmills.
Apr 27
prev sibling next sibling parent reply Imperatorn <johan_forsberg_86 hotmail.com> writes:
On Tuesday, 27 April 2021 at 12:01:33 UTC, russhy wrote:
 And at least with Unreal, since it is using C++, you are not 
 forced to stick with the GC all the time

 With unity, they had to come up with a special language to 

 you are forced to stick with the GC no matter what


 So yes i want D to be as pragmatic as C++
D is already very pragmatic imo. What is it you want to do in D that you can't, but can in C++?

 that leads
 Oh and guess why android smart watches sucks compared to apple 
 watch (perf/battery life)?, yes i know you know why
This has nothing to do with gc vs nogc
Apr 27
parent reply sclytrack <fake hotmail.com> writes:
On Tuesday, 27 April 2021 at 12:20:12 UTC, Imperatorn wrote:
 On Tuesday, 27 April 2021 at 12:01:33 UTC, russhy wrote:
"The Rustening at Microsoft has begun." When will DIP1000 no longer be a preview? When will live go live? DIP1000.md says copyright 2016 and it is 2021.
Apr 27
parent Paulo Pinto <pjmlp progtools.org> writes:
On Tuesday, 27 April 2021 at 13:00:39 UTC, sclytrack wrote:
 On Tuesday, 27 April 2021 at 12:20:12 UTC, Imperatorn wrote:
 On Tuesday, 27 April 2021 at 12:01:33 UTC, russhy wrote:
"The Rustening at Microsoft has begun." When will DIP1000 no longer be a preview? When will live go live? DIP1000.md says copyright 2016 and it is 2021.
Actually the security recomendation for new software at Microsoft is: 1 - .NET languages 2 - Rust 3 - C++ with Core Guidelines Notice who gets first place. https://msrc-blog.microsoft.com/2019/07/18/we-need-a-safer-systems-programming-language/
Apr 27
prev sibling next sibling parent Paulo Pinto <pjmlp progtools.org> writes:
On Tuesday, 27 April 2021 at 12:01:33 UTC, russhy wrote:
 And at least with Unreal, since it is using C++, you are not 
 forced to stick with the GC all the time

 With unity, they had to come up with a special language to 

 you are forced to stick with the GC no matter what


 So yes i want D to be as pragmatic as C++



 that leads


 Oh and guess why android smart watches sucks compared to apple 
 watch (perf/battery life)?, yes i know you know why
Can you please show us your in progress engine that beats the current use of Unity on Microsoft HoloLens?
Apr 27
prev sibling parent reply evilrat <evilrat666 gmail.com> writes:
On Tuesday, 27 April 2021 at 12:01:33 UTC, russhy wrote:
 And at least with Unreal, since it is using C++, you are not 
 forced to stick with the GC all the time

 With unity, they had to come up with a special language to 

 you are forced to stick with the GC no matter what
references).
 So yes i want D to be as pragmatic as C++



 that leads
I'd call it success. Oof. People who make games with Java can has malloc buffers via C directly, that also opens the door to malloc and other allocators, moreover it is even has pointers right in the language (in unsafe code). And just to be clear, object pools is the GC managed memory, this is simply an optimization technique and not GC avoidance, the memory is still under GC control, it's still will be collected by GC at some point, it is just delayed to some moment in time in future. I don't get it, in D you have basically SINGLE scenario when GC actually runs - memory allocation using GC. It just sits there, takes up just a bit of memory, but it doesn't waste your precious CPU ticks, it doesn't sucks power. And the most important thing - you are free to manage the memory what ever way you want! D even gives you the tools(-vgc flag) to know where exactly GC allocation can happen so you could optimize away that so much hated GC to zero. All this available right now without changing the language and waiting for implementation. So what's the problem with you?
Apr 27
next sibling parent reply SealabJaster <sealabjaster gmail.com> writes:
On Tuesday, 27 April 2021 at 13:29:43 UTC, evilrat wrote:
 So what's the problem with you?
Just commenting here as an observation, I think one of his main points is that there's a lack of a standard library based around allocators rather than the GC. While there's dub packages for this stuff, it's all very scattered and incompatible with one another. And most of the higher level libraries make use of the GC instead of supporting allocators (which is understandable, considering they were never moved out of std.experimental). I *think* what he's trying to say is that, while D allows you to avoid the GC and do whatever, the overall ecosystem for nogc is quite lacking and has no leadership or vision for something cohesive, and is just a hodgepodge of random hobby libraries. I personally wouldn't use D if it didn't have its GC, so I do feel that claims that "D is perfectly useable without the GC" while technically true, may not be practically true. If that makes sense. Especially if compared to nogc languages like C++ and Rust. All the "anti-bloat" and "pragmatic" stuff though I have no clue about. D's super pragmatic. Phobos may or may not be bloated, idk, I feel I don't even use a large portion of Phobos. Mostly just the metaprogramming, algorithm/ranges, and formatting+conversion stuff. Also a hint of std.experimental.logger My point is, even though this guy's very strong with his wording and I'd also say flat out incorrect with some of these statements, there's areas here that might be worth thinking about a bit more since D may have deficiencies there.
Apr 27
parent reply sighoya <sighoya gmail.com> writes:
On Tuesday, 27 April 2021 at 13:50:09 UTC, SealabJaster wrote:
 On Tuesday, 27 April 2021 at 13:29:43 UTC, evilrat wrote:
 So what's the problem with you?
Just commenting here as an observation, I think one of his main points is that there's a lack of a standard library based around allocators rather than the GC.
Without to be invited too much in the details here, I think you are right. But how should a stdlib look like which abstract over all allocators, would it be safe can it be safe and performant and generalizing? I mean RC, for instance, is inferior in what it can accept for a language/what it can manage safely compared to GC. So in return, some algorithms may only work for a GC. Sure, we can write other algorithms for other allocators and other manual memory strategies, but then we are arriving to the state space explosion- and incompatibility problem. I think it is hard to unify the world of different MM containers, as severally evidenced by C++. Though I would kind of like to be convinced if I'm wrong. Why not go the nim direction and detect acycles with static analysis. I know that this is cumbersome given some steps in the evolution of D at least from what I heard so far. Generally, I would like to see the compiler improving storing a huge amount of metadata in the resulting binary, e.g., is the argument of a function borrowed or cached somewhere without the interception of the user in the frontend. And generally, people moaning about the GC's non-determinism may prefer to track cycle detection for potential resources just in time with some negative runtime performance hit for the benefit of just in time deallocation.
Apr 27
parent reply Ola Fosheim =?UTF-8?B?R3LDuHN0YWQ=?= <ola.fosheim.grostad gmail.com> writes:
On Tuesday, 27 April 2021 at 15:23:30 UTC, sighoya wrote:
 Without to be invited too much in the details here, I think you 
 are right. But how should a stdlib look like which abstract 
 over all allocators, would it be safe can it be safe and 
 performant and generalizing?

 I mean RC, for instance, is inferior in what it can accept for 
 a language/what it can manage safely compared to GC.

 So in return, some algorithms may only work for a GC.
This can be solved by not allowing destructors/finalizers on GC objects. Then a modelling error would only lead to leaks. If you do that then you can let libraries be written for RC. Then when a GC is available you convert strong and weak RC-pointers to non-RC pointers if the RC-pointer pointed to a class with no destructors/finalizers. But since people won't give up on destructors/finalizers for GC, we can't do this. The alternatives are likely to be bug ridden... So, people who want libraries to be memory management agnostic actually have to successfully champion that destructors/finalizers are removed from the GC for all programs. Get consensus for that, then move on to getting rid of the GC from libraries. First thing first.
Apr 27
parent sighoya <sighoya gmail.com> writes:
On Tuesday, 27 April 2021 at 19:51:55 UTC, Ola Fosheim Grøstad 
wrote:

 Then when a GC is available you convert strong and weak 
 RC-pointers to non-RC pointers if the RC-pointer pointed to a 
 class with no destructors/finalizers.
This kind of direction isn't the problem, but the other way around is. You can't easily transform GC code to RC code which is much more needed than the other way around given the amount of libraries written. The model of Weak/Strong references is in my opinion either not fast or unsafe.
Apr 28
prev sibling next sibling parent reply russhy <russhy gmail.com> writes:
On Tuesday, 27 April 2021 at 13:29:43 UTC, evilrat wrote:
 On Tuesday, 27 April 2021 at 12:01:33 UTC, russhy wrote:
 And at least with Unreal, since it is using C++, you are not 
 forced to stick with the GC all the time

 With unity, they had to come up with a special language to 

 you are forced to stick with the GC no matter what
references).
 So yes i want D to be as pragmatic as C++



 where that leads
that I'd call it success. Oof. People who make games with Java can has malloc buffers via directly, that also opens the door to malloc and other allocators, moreover it is even has pointers right in the language (in unsafe code). And just to be clear, object pools is the GC managed memory, this is simply an optimization technique and not GC avoidance, the memory is still under GC control, it's still will be collected by GC at some point, it is just delayed to some moment in time in future. I don't get it, in D you have basically SINGLE scenario when GC actually runs - memory allocation using GC. It just sits there, takes up just a bit of memory, but it doesn't waste your precious CPU ticks, it doesn't sucks power. And the most important thing - you are free to manage the memory what ever way you want! D even gives you the tools(-vgc flag) to know where exactly GC allocation can happen so you could optimize away that so much hated GC to zero. All this available right now without changing the language and waiting for implementation. So what's the problem with you?
libgdx also is a pain in the ass to work with because you have to constantly fight with java and the GC, they had to rewrite all the data structures (collections etc because they allocate on foreach) that is why libgdx is dead, java is not suitable for gamedev -- concerning microsoft, that is why they are working on their new rust like language with full C++ interop, rip D, https://github.com/microsoft/verona/ -- you all misread me, and you all miss the point, i'm not asking to make D a no-gc language only i am asking we should aim to be a memory agnostic language, where one can plugin a GC transparently and do what ever he wants, and at the same time transition to a full manually managed scheme with allocators transparently
Apr 27
next sibling parent Ola Fosheim =?UTF-8?B?R3LDuHN0YWQ=?= <ola.fosheim.grostad gmail.com> writes:
On Tuesday, 27 April 2021 at 14:59:22 UTC, russhy wrote:
 i am asking we should aim to be a memory agnostic language, 
 where one can plugin a GC transparently and do what ever he 
 wants, and at the same time transition to a full manually 
 managed scheme with allocators transparently
That would be nice, wouldn't it? But there is no such design on the table for D. You have to write your framework differently in order to support reference counting and garbage collection if it does something non-trivial. You have to write frameworks differently for RAII and non-deterministic destruction... So in practice you have to settle on one main memory management scheme, and let other management schemes be optional. Library authors are not going to do a good job of testing their libraries for multiple memory management scheme, even if they thought they wrote the code to support both. Sure the standard library can default to reference counting, but 3rd party libraries probably won't. This has nothing to do with moving to task-local GC or not, tough.
Apr 27
prev sibling next sibling parent Paulo Pinto <pjmlp progtools.org> writes:
On Tuesday, 27 April 2021 at 14:59:22 UTC, russhy wrote:
 On Tuesday, 27 April 2021 at 13:29:43 UTC, evilrat wrote:
 On Tuesday, 27 April 2021 at 12:01:33 UTC, russhy wrote:
 And at least with Unreal, since it is using C++, you are not 
 forced to stick with the GC all the time

 With unity, they had to come up with a special language to 

 you are forced to stick with the GC no matter what
references).
 So yes i want D to be as pragmatic as C++



 where that leads
that I'd call it success. Oof. People who make games with Java can has malloc buffers almost directly, that also opens the door to malloc and other allocators, moreover it is even has pointers right in the language (in unsafe code). And just to be clear, object pools is the GC managed memory, this is simply an optimization technique and not GC avoidance, the memory is still under GC control, it's still will be collected by GC at some point, it is just delayed to some moment in time in future. I don't get it, in D you have basically SINGLE scenario when GC actually runs - memory allocation using GC. It just sits there, takes up just a bit of memory, but it doesn't waste your precious CPU ticks, it doesn't sucks power. And the most important thing - you are free to manage the memory what ever way you want! D even gives you the tools(-vgc flag) to know where exactly GC allocation can happen so you could optimize away that so much hated GC to zero. All this available right now without changing the language and waiting for implementation. So what's the problem with you?
libgdx also is a pain in the ass to work with because you have to constantly fight with java and the GC, they had to rewrite all the data structures (collections etc because they allocate on foreach) that is why libgdx is dead, java is not suitable for gamedev
LibGDX is pretty much alive, https://libgdx.com, I guess you keep referring to the old site. Yes it probably has been shadowed by the facts that the original author kind of left the project after being burned with the Xamarin acquisition and shutdown from the original RoboVM project. And the tiny detail that nowadays Unreal and Unity are mostly free beer for indies, alongside their GC implementations, graphical tools, the preferred teaching tool at game universities around the globe, with first party support from Microsoft, Apple, Google, Sony and Nintendo on their OS, VR/AR and gaming platforms. As for Verona, it is Microsoft Research language and it is mostly paperware in 2021, did you forgot to read the link?
 This project is at a very early stage, parts of the type 
 checker are still to be implemented, and there are very few 
 language features implemented yet. This will change, but will 
 take time.
Apr 28
prev sibling parent sighoya <sighoya gmail.com> writes:
On Tuesday, 27 April 2021 at 14:59:22 UTC, russhy wrote:

 i am asking we should aim to be a memory agnostic language, 
 where one can plugin a GC transparently and do what ever he 
 wants, and at the same time transition to a full manually 
 managed scheme with allocators transparently
The problem is that you solely consider manual or managed resources on their own, but resources alias other resources and other resources alias the considered resource, the connection is the problem. Not only does the GC manage memory for you at runtime, it also does this in a way to guarantee memory safety, speaking differently, the GC is some kind of runtime lifetime manager, although not a deterministic lifetime manager. Anyway, this is a feature Rust completely lacks. There are ways to reformulate the solution to cyclic data structures differently, but mostly with some additional memory or performance hit. And just to say, no one moans when Rust didn't allow deleting resources when lifetimes say no, but the GC shouldn't say no? Solving the problem in Rust is similar to solving the problem in D, just choose another memory model for the specific problem. Could libraries more engage in providing such solutions, I think yes, but generalizing algorithms to offer you the most performant and safe code is hard and leads probably to a state space explosion. Just look at the many ways you can create containers in Rust, you have Owned, Rc, Pin, Cell, Pin<...<...>> and whatever.
Apr 28
prev sibling parent Ola Fosheim =?UTF-8?B?R3LDuHN0YWQ=?= <ola.fosheim.grostad gmail.com> writes:
On Tuesday, 27 April 2021 at 13:29:43 UTC, evilrat wrote:
 And the most important thing - you are free to manage the 
 memory what ever way you want!
That's kinda irrelevant. You can say that for basically any language with a C-bridge. Doesn't mean it is cost efficient. If it isn't cost efficient, then it isn't competitive. If it isn't competitive then it isn't interesting. barriers and is therefore going to freeze or significantly slow down execution for any reasonable collection scheme during collection. (I don't consider fork() reasonable.) is irrelevant for D. Can we please focus this discussion on getting a competitive memory management scheme? Reverting to C is not a competitive option.
Apr 27
prev sibling parent reply Paulo Pinto <pjmlp progtools.org> writes:
On Monday, 26 April 2021 at 13:44:36 UTC, russhy wrote:
 On Monday, 26 April 2021 at 09:22:12 UTC, evilrat wrote:
 [...]
Again, this shows how little you know UE4 GC is fine if you make a hello world, ask every studios what they have to do to workaround the GC, they wish it didn't exist, and Epic is working on ditching the GC with their upcoming data oriented stack, just like Unity is working on [...]
From "Unity Future .NET Development Status"
 But we have also a longer term idea in the future to "combine" 
 Burst+IL2CPP effort and to push for the best .NET AOT 
 experience for Unity apps. This AOT solution could be 
 considered as a Tiered level 4 compilation compatible with 
 CoreCLR. But before going there, we will have quite some work 
 ahead, as highlighted by  JoshPeterson in the original post 
 above.
https://forum.unity.com/threads/unity-future-net-development-status.1092205/#post-7035031
Apr 26
parent reply russhy <russhy gmail.com> writes:
On Monday, 26 April 2021 at 14:42:22 UTC, Paulo Pinto wrote:
 On Monday, 26 April 2021 at 13:44:36 UTC, russhy wrote:
 On Monday, 26 April 2021 at 09:22:12 UTC, evilrat wrote:
 [...]
Again, this shows how little you know UE4 GC is fine if you make a hello world, ask every studios what they have to do to workaround the GC, they wish it didn't exist, and Epic is working on ditching the GC with their upcoming data oriented stack, just like Unity is working on [...]
From "Unity Future .NET Development Status"
 But we have also a longer term idea in the future to "combine" 
 Burst+IL2CPP effort and to push for the best .NET AOT 
 experience for Unity apps. This AOT solution could be 
 considered as a Tiered level 4 compilation compatible with 
 CoreCLR. But before going there, we will have quite some work 
 ahead, as highlighted by  JoshPeterson in the original post 
 above.
https://forum.unity.com/threads/unity-future-net-development-status.1092205/#post-7035031
Unity DOTS doesn't use the GC, AT ALL You guys never made a game or a game engine and you are telling me GC is fine Sure, sure, GC will save us, but it needs to pause the world first
Apr 26
next sibling parent reply Adam D. Ruppe <destructionator gmail.com> writes:
On Monday, 26 April 2021 at 15:30:48 UTC, russhy wrote:
 You guys never made a game or a game engine and you are telling 
 me GC is fine
Which games have you made? I made a buggy version of Minesweeper once. You can play it online actually http://webassembly.arsdnet.net/minesweeper
Apr 26
next sibling parent reply evilrat <evilrat666 gmail.com> writes:
On Monday, 26 April 2021 at 15:38:48 UTC, Adam D. Ruppe wrote:
 On Monday, 26 April 2021 at 15:30:48 UTC, russhy wrote:
 You guys never made a game or a game engine and you are 
 telling me GC is fine
Which games have you made? I made a buggy version of Minesweeper once. You can play it online actually http://webassembly.arsdnet.net/minesweeper
Now we are talking! I have asteroids game that is actually written in D using Unity. https://forum.dlang.org/post/lwxodemvzgyxkmanpptg forum.dlang.org
Apr 26
parent Adam D. Ruppe <destructionator gmail.com> writes:
On Monday, 26 April 2021 at 16:35:08 UTC, evilrat wrote:
 I have asteroids game that is actually written in D using Unity.

 https://forum.dlang.org/post/lwxodemvzgyxkmanpptg forum.dlang.org
whoa it actually ran on my linux box! that's kinda cool. I did a little asteroids type thing too (also available online http://webassembly.arsdnet.net/asteroids ). I started a first person version of it too many years ago but I never finished it. That'd probably be kinda fun to revisit some day and finish off. idk if I'd make that work on the webassembly though but of course it would on normal windows and linux.
Apr 27
prev sibling parent reply russhy <russhy gmail.com> writes:
On Monday, 26 April 2021 at 15:38:48 UTC, Adam D. Ruppe wrote:
 On Monday, 26 April 2021 at 15:30:48 UTC, russhy wrote:
 You guys never made a game or a game engine and you are 
 telling me GC is fine
Which games have you made? I made a buggy version of Minesweeper once. You can play it online actually http://webassembly.arsdnet.net/minesweeper
I'm working on a 3D game engine yeah minesweeper can have a 5 second GC pause, users won't notice
Apr 26
next sibling parent bachmeier <no spam.net> writes:
On Monday, 26 April 2021 at 17:34:41 UTC, russhy wrote:
 On Monday, 26 April 2021 at 15:38:48 UTC, Adam D. Ruppe wrote:
 On Monday, 26 April 2021 at 15:30:48 UTC, russhy wrote:
 You guys never made a game or a game engine and you are 
 telling me GC is fine
Which games have you made? I made a buggy version of Minesweeper once. You can play it online actually http://webassembly.arsdnet.net/minesweeper
I'm working on a 3D game engine yeah minesweeper can have a 5 second GC pause, users won't notice
If you want to be precise, this is a matter of implementation of GC. There are *some games* for which *current GC implementations* result in unacceptable performance issues. Many will do just fine. There's also no reason to pretend manual memory management, reference counting, or garbage collection is a silver bullet. Allocation/freeing of memory always results in a performance hit no matter what name you apply. As [stated in this blog post](https://www.sebastiansylvan.com/post/on-gc-in-games-response-to-jeff-and-casey/):
 Jeff and Casey’s ranting is not actually about the GC itself, 
 but about promiscuous allocation behavior, and I fully agree 
 with that, but I think it’s a mistake to conflate the two. GC 
 doesn’t imply that you should heap allocate at the drop of a hat
I'm not arguing that the GC will work for all games because it won't. You give the impression of having a fundamentalist position though that "real games" (not Minesweeper) cannot have a GC and that GC is obviously going to be slow (uncontrollable 5 second pauses). That's not a helpful starting point.
Apr 26
prev sibling next sibling parent evilrat <evilrat666 gmail.com> writes:
On Monday, 26 April 2021 at 17:34:41 UTC, russhy wrote:
 I'm working on a 3D game engine
Why bother making your engine if you don't have a team and project for it? There is already stuff like godot-d, it works but still somewhat cumbersome to use. Still should be a good choice for most non shooter games. The only bad thing is that the editor itself has UX of a potato (just like pretty much any open source product) and it is said that 3d is barely optimized so we have to wait for Godot 4 release. https://code.dlang.org/packages/godot-d
Apr 26
prev sibling parent martinm <martinmannes23312 gmail.com> writes:
On Monday, 26 April 2021 at 17:34:41 UTC, russhy wrote:
 On Monday, 26 April 2021 at 15:38:48 UTC, Adam D. Ruppe wrote:
 On Monday, 26 April 2021 at 15:30:48 UTC, russhy wrote:
 You guys never made a game or a game engine and you are 
 telling me GC is fine
Which games have you made? I made a buggy version of Minesweeper once. You can play it online actually http://webassembly.arsdnet.net/minesweeper
I'm working on a 3D game engine yeah minesweeper can have a 5 second GC pause, users won't notice
I'm interested. Will your 3D engine also have LUA scripting ?
Apr 27
prev sibling parent Paulo Pinto <pjmlp progtools.org> writes:
On Monday, 26 April 2021 at 15:30:48 UTC, russhy wrote:
 On Monday, 26 April 2021 at 14:42:22 UTC, Paulo Pinto wrote:
 On Monday, 26 April 2021 at 13:44:36 UTC, russhy wrote:
 [...]
From "Unity Future .NET Development Status"
 [...]
https://forum.unity.com/threads/unity-future-net-development-status.1092205/#post-7035031
Unity DOTS doesn't use the GC, AT ALL You guys never made a game or a game engine and you are telling me GC is fine Sure, sure, GC will save us, but it needs to pause the world first
Apr 26
prev sibling parent reply russhy <russhy gmail.com> writes:
On Monday, 26 April 2021 at 06:35:25 UTC, Paulo Pinto wrote:
 On Sunday, 25 April 2021 at 19:41:39 UTC, russhy wrote:
 We already have zig and rust, adding yet another fancy slick 
 no GC landuage is dead end.
Same defeatist mentality i keep reading here, this is not what D need
 So please stop your no-GC whine. People already heard you, 
 more than once too.
I will never stop fighting for D from the people who wants to ruin it with more GC
D is open source, you are free to take care of your special flavoured D.
say this to the people who want to ruin D with more GC, they are free to make their own fork caleld DJava
Apr 26
parent reply 12345swordy <alexanderheistermann gmail.com> writes:
On Monday, 26 April 2021 at 13:40:18 UTC, russhy wrote:
 On Monday, 26 April 2021 at 06:35:25 UTC, Paulo Pinto wrote:
 On Sunday, 25 April 2021 at 19:41:39 UTC, russhy wrote:
 We already have zig and rust, adding yet another fancy slick 
 no GC landuage is dead end.
Same defeatist mentality i keep reading here, this is not what D need
 So please stop your no-GC whine. People already heard you, 
 more than once too.
I will never stop fighting for D from the people who wants to ruin it with more GC
D is open source, you are free to take care of your special flavoured D.
say this to the people who want to ruin D with more GC, they are free to make their own fork caleld DJava
This is just pure GC phobia at this point of time. -Alex
Apr 26
parent reply russhy <russhy gmail.com> writes:
On Monday, 26 April 2021 at 13:43:21 UTC, 12345swordy wrote:
 On Monday, 26 April 2021 at 13:40:18 UTC, russhy wrote:
 On Monday, 26 April 2021 at 06:35:25 UTC, Paulo Pinto wrote:
 On Sunday, 25 April 2021 at 19:41:39 UTC, russhy wrote:
 We already have zig and rust, adding yet another fancy 
 slick no GC landuage is dead end.
Same defeatist mentality i keep reading here, this is not what D need
 So please stop your no-GC whine. People already heard you, 
 more than once too.
I will never stop fighting for D from the people who wants to ruin it with more GC
D is open source, you are free to take care of your special flavoured D.
say this to the people who want to ruin D with more GC, they are free to make their own fork caleld DJava
This is just pure GC phobia at this point of time. -Alex
Not, i never said GC is useless, i said the language shouldn't expect a GC to exists, it should ask you to provide what ever allocation scheme you need for the task
Apr 26
parent 12345swordy <alexanderheistermann gmail.com> writes:
On Monday, 26 April 2021 at 13:54:47 UTC, russhy wrote:
 On Monday, 26 April 2021 at 13:43:21 UTC, 12345swordy wrote:
 On Monday, 26 April 2021 at 13:40:18 UTC, russhy wrote:
 On Monday, 26 April 2021 at 06:35:25 UTC, Paulo Pinto wrote:
 On Sunday, 25 April 2021 at 19:41:39 UTC, russhy wrote:
 We already have zig and rust, adding yet another fancy 
 slick no GC landuage is dead end.
Same defeatist mentality i keep reading here, this is not what D need
 So please stop your no-GC whine. People already heard you, 
 more than once too.
I will never stop fighting for D from the people who wants to ruin it with more GC
D is open source, you are free to take care of your special flavoured D.
say this to the people who want to ruin D with more GC, they are free to make their own fork caleld DJava
This is just pure GC phobia at this point of time. -Alex
Not, i never said GC is useless, i said the language shouldn't expect a GC to exists, it should ask you to provide what ever allocation scheme you need for the task
That is just pure nonsense. Having the gc built into the language have noticeable benefits. -Alex
Apr 26
prev sibling next sibling parent reply Ola Fosheim =?UTF-8?B?R3LDuHN0YWQ=?= <ola.fosheim.grostad gmail.com> writes:
On Tuesday, 20 April 2021 at 16:28:46 UTC, russhy wrote:
 GC is not the right model if you don't have the same ressources 
 as Microsoft / Google / Oracle to invest massively on GC R&D, 
 there is no way D can comepte with the latest Java's sub 1ms 
 GC, no way
Well, it would be 0ms, if it runs when the task is idle. If the task is short lived then it would be like an arena-allocator (faster than malloc).
 IMHO, Apple made the right decision to go with a RC with Swift, 
 like they did with Obj-C
The people who were unhappy with D having a GC has probably left for Rust at this point. So it seems like the majority wants to have a GC.
 D's future is with memory ownership / reference counting
If it keeps moving at this pace then it will never happen... and the language semantics for borrowing isn't there.
 We need to transition to RC instead of GC, the sooner, the 
 better
Yes, if it had happened 4 years ago, but it is kinda too late. If there had been traction in the community for making everything RC then things wouldn't move so slowly with memory management as it does now. Borrowing won't happen either, for it to happen there should've been a gamma-release by now. It will take years to get it to work properly after the first gamma-release. GC-based tasks should make converting existing code reasonable in most cases. Except for heavily user-level multithreaded code. It can also be done as a prototype in short order. Just adapt the existing GC code, even though that might be a bit heavy for production use.
Apr 20
parent reply russhy <russhy gmail.com> writes:
Well, it would be 0ms, if it runs when the task is idle. If the 
task is short lived then it would be like an arena-allocator 
(faster than malloc).
Then just use an arena allocator, why everyone wants to make things complicated for everyone, and as a default It's just like the Thread, or even Fibers, can't even be used without the GC, that is a very very very poor and short sighted mindset
The people who were unhappy with D having a GC has probably left 
for Rust at this point. So it seems like the majority wants to 
have a GC.
Reason why language stagnates, noone left to take it to the next level Worse, the ones who stayed are taking D to the wrong direction by focusing on the GC
If it keeps moving at this pace then it will never happen... and 
the language semantics for borrowing isn't there.
Argument that i share, we need the foundation people and walter/atila etc to show up in these discussions, but they never do, so no interesting debates happen, reason why language stagnates
Yes, if it had happened 4 years ago, but it is kinda too late. 
If there had been traction in the community for making 
everything RC then things wouldn't move so slowly with memory 
management as it does now. Borrowing won't happen either, for it 
to happen there should've been a gamma-release by now. It will 
take years to get it to work properly after the first 
gamma-release.
That is a very short term mindset, another reason why language stagnates, lack of vision and lack of proper discussion to make pragmatic and future proof changes/deprecations/decisions Whenever that discussion happen, it's always "it's too late", "it'll never happen", "it's the way it is", "just embrace the bad, stagnating, non-scalable GC" The main issue is the lack of will and courage from the team to ackowledge the poor state of the GC and they play hide&seek when it comes to discussing/debating about it
Apr 20
parent reply Ola Fosheim Grostad <ola.fosheim.grostad gmail.com> writes:
On Tuesday, 20 April 2021 at 21:59:30 UTC, russhy wrote:
 That is a very short term mindset, another reason why language 
 stagnates, lack of vision and lack of proper discussion to make 
 pragmatic and future proof changes/deprecations/decisions

 Whenever that discussion happen, it's always "it's too late", 
 "it'll never happen", "it's the way it is"
It is too late for D to attract C++ developers. I am ok with C++20 and dont think it is realistic for D to play catch up. D needs to find its own vision, or it will be displaced.
Apr 20
parent reply russhy <russhy gmail.com> writes:
On Tuesday, 20 April 2021 at 22:32:08 UTC, Ola Fosheim Grostad 
wrote:
 On Tuesday, 20 April 2021 at 21:59:30 UTC, russhy wrote:
 That is a very short term mindset, another reason why language 
 stagnates, lack of vision and lack of proper discussion to 
 make pragmatic and future proof changes/deprecations/decisions

 Whenever that discussion happen, it's always "it's too late", 
 "it'll never happen", "it's the way it is"
It is too late for D to attract C++ developers. I am ok with C++20 and dont think it is realistic for D to play catch up.
What RC has to do with C++? What using a pragmatic approach and IAllocator oriented apis has to do with C++? I'm not talking about C++, at all
 I am ok with C++20 and dont think it is realistic for D to play 
 catch up.
Defeatist mindset, that is what i am talking about when i say the people who stayed are taking D to the wrong direction And i never said it needs to catch up with C++, sticking to GC means it can't be a compelling alternative to the people with C/C++/Rust and soon Zig background purposes because Go already fit the role perfectly fine, because they did what D failed to do
 So it's 2014. If Go does not solve this GC latency problem 
 somehow then Go isn't going to be successful. That was clear.
 Other new languages were facing the same problem. Languages 
 like Rust went a different way but we are going to talk about 
 the path that Go took.
https://blog.golang.org/ismmkeynote Is this allocating memory? is this using arena GC? is this gonna end up blocking all my threads? how long can we expect a pause to be? 20ms? 1ms? Actor model isn't bound to GC uses, so your wish of a vision for D has nothing to do with the way memory is managed Solving real world issues is what drives adoption, but at some point your solution will have to work with D's features, and these are using a poor's man GC that'll stop their world, and won't scale well Foundations have to work well, and to be pragmatic, so you aren't bound to a specific scenario, that is the most future proof solution because it allows anyone with ideas on how to solve real world problems, that is what C is not displaced because of that, it doesn't tell you what to do, and how to do, it gives you the tools so you can write portable code, efficient and better software I personally doesn't give a damn about all of this since i stick to ``core.stdc`` But i care about D, and this vision of D being a managed language is not doing good for D's future, managed language come and go because they made strong choices that they are unable to revert, C/C++ still strong today, why? i guess -i don't know right?- I went way too offtopic, i should have created a separate from the beginning.. --- And i agree with Andrei this place needs a voting system, with proper moderating tools, so i'd know if what i said speaks to people or if i should just stop because i am becoming annoyingly rude for no real reasons
Apr 20
parent Ola Fosheim Grostad <ola.fosheim.grostad gmail.com> writes:
On Wednesday, 21 April 2021 at 00:47:13 UTC, russhy wrote:
 C is not displaced because of that, it doesn't tell you what to 
 do, and how to do, it gives you the tools so you can write 
 portable code, efficient and better software
ISO C is being replaced with ISO C++, that trend won't stop. Walter does not want to have many pointer types, that makes a library based allocator strategy a mess. My proposal is simpler, if you don't want GC, don't use a GC-Task.
Apr 20
prev sibling next sibling parent reply TheGag96 <thegag96 gmail.com> writes:
On Tuesday, 20 April 2021 at 16:28:46 UTC, russhy wrote:
 We need to transition to RC instead of GC, the sooner, the 
 better
Maybe I'm wrong, but wouldn't we be just going from one form of memory management people find slow to another? And a kind we know is *particularly* slow (even if more predictable)? It seems to me that the really anti-GC crowd (or the portion of it that I know of - the Handmade / game dev group) doesn't want GC nor RC, but instead something way more C-like, with custom allocators and such. I think that's what languages like Zig that sprang up out of nowhere are suddenly taking off and why there's still anticipation for Jai nearly 7 years later. I do kind of agree that maybe a D3 is what's needed in order to have a clean rethinking and uncrufting of the language. I've been feeling that despite D's amazing features and upsides, something just isn't clicking with people. Since I became an avid D fan many years ago, most programmers I talk to have never heard of it, and the situation has not gotten better over time.
Apr 20
parent russhy <russhy gmail.com> writes:
On Wednesday, 21 April 2021 at 01:00:59 UTC, TheGag96 wrote:
 On Tuesday, 20 April 2021 at 16:28:46 UTC, russhy wrote:
 We need to transition to RC instead of GC, the sooner, the 
 better
Maybe I'm wrong, but wouldn't we be just going from one form of memory management people find slow to another? And a kind we know is *particularly* slow (even if more predictable)? It seems to me that the really anti-GC crowd (or the portion of it that I know of - the Handmade / game dev group) doesn't want GC nor RC, but instead something way more C-like, with custom allocators and such. I think that's what languages like Zig that sprang up out of nowhere are suddenly taking off and why there's still anticipation for Jai nearly 7 years later. I do kind of agree that maybe a D3 is what's needed in order to have a clean rethinking and uncrufting of the language. I've been feeling that despite D's amazing features and upsides, something just isn't clicking with people. Since I became an avid D fan many years ago, most programmers I talk to have never heard of it, and the situation has not gotten better over time.
I mixed things with the Swift analogy i used earlier my bad, i meant the IAllocator driven APIs, need to allocate? one want GC in their program? fine provide the GCAllocator, but don't enforce it to everyone And i agree with you, that is the perfect opportunity for a D3 vision, and that's where the sooner the better make sense, because just like you said, there is a need for a modern C *alternative*
  I've been feeling that despite D's amazing features and 
 upsides, something just isn't clicking with people.
The experience i have with this was always the GC
Apr 20
prev sibling parent reply 12345swordy <alexanderheistermann gmail.com> writes:
On Tuesday, 20 April 2021 at 16:28:46 UTC, russhy wrote:
 GC is not the right model if you don't have the same ressources 
 as Microsoft / Google / Oracle to invest massively on GC R&D, 
 there is no way D can comepte with the latest Java's sub 1ms 
 GC, no way

 IMHO, Apple made the right decision to go with a RC with Swift, 
 like they did with Obj-C

 D's future is with memory ownership / reference counting

 The more we stick to the GC, the more we'll have to play 
 catchup with the competition

 Even GO's GC is starting to become a negative amongst certain 
 users 
 https://blog.discord.com/why-discord-is-switching-from-go-to-rust-a190bbca2b1f


 We need to transition to RC instead of GC, the sooner, the 
 better

 I know people like the GC, i do too, but in its current state 
 it is absolute garbage when you compare to the competition

 Again, the more we fill the STD library with GC code, the 
 faster we'll get shadowed by the competition
U can take the gc away from me from my dead cold hands. -Alex
Apr 21
parent reply Imperatorn <johan_forsberg_86 hotmail.com> writes:
On Wednesday, 21 April 2021 at 21:47:10 UTC, 12345swordy wrote:
 On Tuesday, 20 April 2021 at 16:28:46 UTC, russhy wrote:
 [...]
U can take the gc away from me from my dead cold hands. -Alex
The GC will remain, but could be improved.
Apr 25
parent reply russhy <russhy gmail.com> writes:
On Sunday, 25 April 2021 at 09:48:15 UTC, Imperatorn wrote:
 On Wednesday, 21 April 2021 at 21:47:10 UTC, 12345swordy wrote:
 On Tuesday, 20 April 2021 at 16:28:46 UTC, russhy wrote:
 [...]
U can take the gc away from me from my dead cold hands. -Alex
The GC will remain, but could be improved.
That is a very very very very very bad decision That is one of the reason i decide to stay away from std and stick to core.stdc, and that is what i recommend everytime i mention D to people That is also one of the reason i limit D for my new projects and keep an eye for new languages that focuses on allocators first Stay the hell out of std, and stay the hell out of the GC, if you want to get started with D Mistakes mistakes mistakes, that is what people do, bloat bloat bloat, they is what people do And as expected, the top level people remains silent, they let some people destroy this beautiful language that is D Ignoring decade of complains about the GC, and saying after decades "we need to improve the GC", as if nobody made the complain Blind, refuse to listen to feedback, that's what D foundation Lack of public roadmap is the evidence of everything Leadership? where? C'mon Walter, Atila, Andrei, let us know what do you think about the GC story? You are responsible of it, c'mon react! You guys are chasing Java, Go ate your cake with better GC Now you figured you'd also chase C++, but Rust ate your cake too Now you figured you should stick to chasing Java, with a shitty GC that doesn't scale Without even tooling to analyses heap memory sanely, something at least Java provides out of the box "the gc will remain", but not D
Apr 25
parent Imperatorn <johan_forsberg_86 hotmail.com> writes:
On Sunday, 25 April 2021 at 17:33:06 UTC, russhy wrote:
 On Sunday, 25 April 2021 at 09:48:15 UTC, Imperatorn wrote:
 [...]
That is a very very very very very bad decision That is one of the reason i decide to stay away from std and stick to core.stdc, and that is what i recommend everytime i mention D to people [...]
Hmm, some partly valid points, but I think the strength D has is its plasticity. Let's put it like this, what should the "GC-lovers" do without the GC? How do you please everyone? The only solution I see is provide choice, which I think D does.
Apr 25
prev sibling next sibling parent reply jmh530 <john.michael.hall gmail.com> writes:
On Tuesday, 20 April 2021 at 09:52:07 UTC, Ola Fosheim Grøstad 
wrote:
 [snip]
 It seems to me that the obvious way to retain the easy of use 
 that garbage collection provides without impeding performance 
 is to limit the memory to scan, and preferably do the scanning 
 when nobody is using the memory.

 The actor model seems to be a good fit. Or call it a task, if 
 you wish. If each actor/task has it's own GC pool then there is 
 less memory to scan, and you can do the scanning when the 
 actor/task is waiting on I/O or scheduling. So you would get 
 less intrusive scanning pauses. It would also fit well with 
 async-await/futures.

 [snip]
Are you familiar with this: https://github.com/hsutter/gcpp How similar are these ideas?
Apr 20
parent Ola Fosheim Grostad <ola.fosheim.grostad gmail.com> writes:
On Tuesday, 20 April 2021 at 17:52:33 UTC, jmh530 wrote:
 Are you familiar with this:
 https://github.com/hsutter/gcpp

 How similar are these ideas?
I've read about it, but it seems to be just a local collector? It isn't similar as we want to trace stacks and don't want to rely on conventions. We want the type system to prevent bad situations from happening.
Apr 20
prev sibling next sibling parent Jossy <lmablenewman gmail.com> writes:
On Tuesday, 20 April 2021 at 09:52:07 UTC, Ola Fosheim Grøstad 
wrote:
 As computer memory grows, naive scan and sweep garbage 
 collection becomes more and more a burden.

 [...]
Hi I had the same request. I can say that preserving the ease of use that garbage collection provides without sacrificing performance can be done with the software that I installed on this site https://www.worktime.com/
Apr 27
prev sibling next sibling parent reply sighoya <sighoya gmail.com> writes:
On Tuesday, 20 April 2021 at 09:52:07 UTC, Ola Fosheim Grøstad 
wrote:
 Is this a direction D is able to move in or is a new language 
 needed?
I think this sounds good. There is already a language taking the same/similar direction: Pony: https://tutorial.ponylang.io/appendices/garbage-collection.html Any(one) experience with it?
Apr 27
next sibling parent Ola Fosheim =?UTF-8?B?R3LDuHN0YWQ=?= <ola.fosheim.grostad gmail.com> writes:
On Tuesday, 27 April 2021 at 21:18:30 UTC, sighoya wrote:
 Pony: 
 https://tutorial.ponylang.io/appendices/garbage-collection.html

 Any(one) experience with it?
I have no real experience with it, but I read quite a bit about it when it first came. I think the typing system for references is interesting. Basicially keeps track at compile time of whether a pointer has been given out or not and restricts capabilities for the reference based on that.
Apr 27
prev sibling parent reply Tejas <notrealemail gmail.com> writes:
On Tuesday, 27 April 2021 at 21:18:30 UTC, sighoya wrote:
 On Tuesday, 20 April 2021 at 09:52:07 UTC, Ola Fosheim Grøstad 
 wrote:
 Is this a direction D is able to move in or is a new language 
 needed?
I think this sounds good. There is already a language taking the same/similar direction: Pony: https://tutorial.ponylang.io/appendices/garbage-collection.html Any(one) experience with it?
Someone made a data stream processor with it that had nanosecond level latency requirements. Seems like a pretty good language even in practical usage. https://youtu.be/GigBhej1gfI However I noticed that the company he leadsnis nownlooking to hire rust programmers so I can't really say what is the result of using this language long-term.
May 03
parent Ola Fosheim =?UTF-8?B?R3LDuHN0YWQ=?= <ola.fosheim.grostad gmail.com> writes:
On Monday, 3 May 2021 at 18:17:05 UTC, Tejas wrote:
 Someone made a data  stream processor with it that had 
 nanosecond level latency requirements. Seems like a pretty good 
 language even in practical usage.

 https://youtu.be/GigBhej1gfI
Thanks for the link, Sean T Allen seemed to be very honest about strengths and weaknesses. I like that.
 However I noticed that the company he leadsnis nownlooking to 
 hire rust programmers so I can't really say what is the result 
 of using this language long-term.
I think that would apply to most small languages; most suitable for hobbyists or personal usage, more risky for long term projects that are deployed.
May 03
prev sibling parent reply James Lu <jamtlu gmail.com> writes:
On Tuesday, 20 April 2021 at 09:52:07 UTC, Ola Fosheim Grøstad 
wrote:
 As computer memory grows, naive scan and sweep garbage 
 collection becomes more and more a burden.

 Also, languages have not really come up with a satisfactory way 
 to simplify multi-threaded programming, except to split the 
 workload into many single-threaded tasks that are run in 
 parallel.

 It seems to me that the obvious way to retain the easy of use 
 that garbage collection provides without impeding performance 
 is to limit the memory to scan, and preferably do the scanning 
 when nobody is using the memory.
So region-based memory management with per-region GC?
Apr 28
parent Ola Fosheim =?UTF-8?B?R3LDuHN0YWQ=?= <ola.fosheim.grostad gmail.com> writes:
On Thursday, 29 April 2021 at 01:24:27 UTC, James Lu wrote:
 So region-based memory management with per-region GC?
You could say that, although it is more based on the context of a task which can suspend.
Apr 29