std.functional.memoize : thread local or __gshared memoization?

[Ola Fosheim Grostad via Digitalmars-d]

On Thursday, 25 May 2017 at 20:43:36 UTC, Jonathan M Davis wrote:
> complication to the language. Certainly, from what I know of 
> Rust, it's far more complicated because of that sort of thing, 
> and glancing over that link on Pony, it looks like it's getting 
> a fair bit of complication as well in order to deal with the 
> problem.

I think Pony uses a GC (also to collect dead threads/actors).

But I have found that trying to understand their model to be a 
good exercise for thinking about where problems can arise and 
what it takes to resolve it through a typesystem.

> stuff with regards to threads to shared, which is great, but 
> dealing with the stuff that involves sharing across threads 
> then requires that the programmer be much more careful than 
> would be the case if the type system were actually helping you 
> beyond preventing you from doing stuff that isn't thread safe 
> to a shared object without casting it to thread-local first.

Yes, that transition to/from shared is problematic. There are 
ways to deal with it, proving concurrency patterns to be correct, 
but it takes even more machinery than Pony/Rust.

> I don't know what the right answer is. Rust seems to get both 
> praise and complaints about its approach - as do we for ours. 
> But both approaches are safer than what you get with C/C++.

Depends on what you do in C++. If you only share though a 
ready-made framework, then you probably can do quite well in 
terms of safety. With a small performance cost.

If you want max performance in the general case then I think all 
these languages will have safety troubles. Because you need 
proper full-blown verification then...