On Tuesday, 27 April 2021 at 12:20:12 UTC, Imperatorn 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.

On Tuesday, 27 April 2021 at 12:01:33 UTC, russhy wrote:

Can you please show us your in progress engine that beats the current use of Unity on Microsoft HoloLens?

On Monday, 26 April 2021 at 16:35:08 UTC, evilrat wrote:

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.

On Tuesday, 27 April 2021 at 13:00:39 UTC, sclytrack wrote:

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/

On Tuesday, 27 April 2021 at 12:01:33 UTC, russhy wrote:

They don't. HPC# is a subset of C# without objects (no references).

If it leads to be #1 platform for cross platform development that I'd call it success.

Oof. People who make games with Java can has malloc buffers via C bridge(libgdx if you want example), C# can even call C 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?

On Tuesday, 27 April 2021 at 13:29:43 UTC, evilrat wrote:

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.

On Tuesday, 27 April 2021 at 13:29:43 UTC, evilrat wrote:

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

it solves issues C# peeps at unity have, and makes everyone happy

On Tuesday, 27 April 2021 at 13:50:09 UTC, SealabJaster 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.

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.

On Tuesday, 20 April 2021 at 09:52:07 UTC, Ola Fosheim Grøstad wrote:

On Monday, 26 April 2021 at 17:34:41 UTC, russhy wrote:

I'm interested.
Will your 3D engine also have LUA scripting ?