April 20

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

@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

April 20

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?

April 20

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.

>
  1. 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.

April 20

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.

April 20

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.

April 20

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.

April 20
>

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

April 20

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.

April 21

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

Worst, it can't be a compelling alternative to Java/C# for cloud 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

April 21

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.

1 2 3 4 5 6 7 8 9 10