On Friday, 27 November 2020 at 20:41:33 UTC, Guillaume Piolat wrote:
> really), I'm saying that the traits that make people switch to a new language are desirable properties of the _library they want to use_, more than the language.

Yes, or the service it runs on. Which is why I think D ought to encourage separating  framework from app. Let the framework do the multithreading and let the app author write simple single threaded tasks. So basically the framework deals with shared and app authors can mostly ignore that... That would be a good reason to have single threaded GC, which also would enable fast 100% precise collection and correct destruction and RAII. I think we could even get the destructor order right.

However, ARC is more generally useful... For me.

> Soft disagree. This sounds to me like a high-debt solution.
> If you make a game engine for example, cost of making N games is O(N), but cost of having a new platform is O(1). If added value flow to the game engine properly, you _will_ end up having support for all platforms needed.

Godot does not even support Metal or Direct X?

For web I actually only want really efficient debuggable wasm. The browser is the framework and apps should load and run in 1 second. Flutter is a bit bloated, but probably less bloated than unity/godot... And better UI support... But generally speaking... Frameworks are more a hindrance for what I want to achieve.

Anyway, my point was more: if your goal is to build a framework, then you would not do it to promote a specific language. So I dont think the D community can decide this to be a focus.

We can only focus on the enabling language features, getting rid of the irritatiting pain points.

(Why is typing on ipads so... Nggh?)

On Friday, 27 November 2020 at 21:08:28 UTC, Ola Fosheim Grostad wrote:
>
> Anyway, my point was more: if your goal is to build a framework, then you would not do it to promote a specific language. So I dont think the D community can decide this to be a focus.

"framework" word really is the point of conflict.
It is supposed to be a bad thing, you should prefer "libraries"!

That's what people say, but in reality people want a cohesive, framework-like experience, with all kinds of problems already solved and tutorial'ed before they get aware of the issue.

"library" experience is not cohesive enough and will even feel ugly to some.
Your library really is domain-specific after all.

That's what I discovered making Dplug, who has a few users. Promoting D was certainly not a goal, rather it was "using D because it's practical".


> (Why is typing on ipads so... Nggh?)

Well you definitely have some grit there :)

On Friday, 27 November 2020 at 22:02:43 UTC, Guillaume Piolat wrote:
> "framework" word really is the point of conflict.
> It is supposed to be a bad thing, you should prefer "libraries"!
>
> That's what people say, but in reality people want a cohesive, framework-like experience, with all kinds of problems already solved and tutorial'ed before they get aware of the issue.

Focused frameworks are good if they are written to coexist with others. I guess a framework has more of a runtime/service feel to it than a library? I guess service might be a useful term. It signals that you have a clean separation/encapsulation, not too fragmented interface.

The library approach might be flexible, but harder to learn as you get more parts, less encapsulation and basically end up spending too much time reading docs/tutorials. I rember the first time I opened a window on X-windows. 800 lines. Waaaayyyy too flexible.

> That's what I discovered making Dplug, who has a few users. Promoting D was certainly not a goal, rather it was "using D because it's practical".

Yes, good libraries and frameworks usually distill patterns discovered in developing concrete applications.  Which is why, I guess, standard libraries often feel uhm... Inadequate, as they have been conjured from ideas that appeared elegant on paper.  But those ideas often turn into idiomatic religion... STL code tend to be clumsy for instance... Writing your own libs for C++ leads to much better looking code. At some point... Create your own idioms. Life is too short.

On Friday, 27 November 2020 at 22:24:05 UTC, Ola Fosheim Grostad wrote:
> On Friday, 27 November 2020 at 22:02:43 UTC, Guillaume Piolat wrote:
>> [...]
>
> Focused frameworks are good if they are written to coexist with others. I guess a framework has more of a runtime/service feel to it than a library? I guess service might be a useful term. It signals that you have a clean separation/encapsulation, not too fragmented interface.
>
> The library approach might be flexible, but harder to learn as you get more parts, less encapsulation and basically end up spending too much time reading docs/tutorials. I rember the first time I opened a window on X-windows. 800 lines. Waaaayyyy too flexible.
>
>> [...]
>
> Yes, good libraries and frameworks usually distill patterns discovered in developing concrete applications.  Which is why, I guess, standard libraries often feel uhm... Inadequate, as they have been conjured from ideas that appeared elegant on paper.  But those ideas often turn into idiomatic religion... STL code tend to be clumsy for instance... Writing your own libs for C++ leads to much better looking code. At some point... Create your own idioms. Life is too short.

So here are plenty of examples using Go in WASM with a 2D games framework.

https://ebiten.org/examples/

https://medium.com/a-journey-with-go/go-image-rendering-in-2d-video-games-with-ebiten-912cc2360c4f

Enough juice to do Flash style games.

On Tuesday, 1 December 2020 at 08:46:06 UTC, Paulo Pinto wrote:
> On Friday, 27 November 2020 at 22:24:05 UTC, Ola Fosheim Grostad wrote:
>> On Friday, 27 November 2020 at 22:02:43 UTC, Guillaume Piolat wrote:
>>> [...]

Here's an interesting paper from MSR about doing precise ARC.  Basically it seems like a handful of compiler optimization passes to eliminate most RC operations at compile time.

https://www.microsoft.com/en-us/research/uploads/prod/2020/11/perceus-tr-v1.pdf

On Wednesday, 9 December 2020 at 19:02:50 UTC, Ben Jones wrote:
> On Tuesday, 1 December 2020 at 08:46:06 UTC, Paulo Pinto wrote:
>> On Friday, 27 November 2020 at 22:24:05 UTC, Ola Fosheim Grostad wrote:
>>> On Friday, 27 November 2020 at 22:02:43 UTC, Guillaume Piolat wrote:
>>>> [...]
>
> Here's an interesting paper from MSR about doing precise ARC.  Basically it seems like a handful of compiler optimization passes to eliminate most RC operations at compile time.
>
> https://www.microsoft.com/en-us/research/uploads/prod/2020/11/perceus-tr-v1.pdf

Thanks fo sharing, I will certainly read this later when I have more time. Xmas?:)

On Wednesday, 9 December 2020 at 19:02:50 UTC, Ben Jones wrote:
> On Tuesday, 1 December 2020 at 08:46:06 UTC, Paulo Pinto wrote:
>> On Friday, 27 November 2020 at 22:24:05 UTC, Ola Fosheim Grostad wrote:
>>> On Friday, 27 November 2020 at 22:02:43 UTC, Guillaume Piolat wrote:
>>>> [...]
>
> Here's an interesting paper from MSR about doing precise ARC.  Basically it seems like a handful of compiler optimization passes to eliminate most RC operations at compile time.
>
> https://www.microsoft.com/en-us/research/uploads/prod/2020/11/perceus-tr-v1.pdf

Thanks, quite interesting read.