On Wednesday, 6 July 2022 at 15:43:25 UTC, ryuukk_ wrote:
On Wednesday, 6 July 2022 at 14:30:07 UTC, Paulo Pinto wrote:
On Tuesday, 5 July 2022 at 12:34:57 UTC, ryuukk_ wrote:
On Monday, 4 July 2022 at 05:30:10 UTC, Andrej Mitrovic wrote:
[...]
GC is one of D's strength because it is optional, not making
core APIs bing-your-own-memory-allocation-strategy through
nogc or allocators, is making it no longer optional, which is
no longer a strength imo
You don't want GC when you do microcontroller development, so
as a result core APIs (most of them) becomes useless, moving
forward that should make the story better for everyone
Which becomes a strength again
Feel free to consider it a strength, when in reality it is a
flaw against established market players.
https://www.microej.com/
https://www.wildernesslabs.co/
https://www.ptc.com/en/products/developer-tools/perc
https://www.aicas.com/wp/products-services/jamaicavm/
https://www.astrobe.com/
People also use nodejs and npm, what is your point?
If you invest in the future you must take the pragmatic
approach and give options
Those are not Oracle's products, companies took the JVM for
what it is as a foundation and built their products
They haven't picked the default Oracle JDK and the default
concurrent GC
D should enable similar stories with what it has and can
provide, read on the challenges TinyGO faced, if D provides the
tools for companies to experiment with it, with a proper set of
efficient and minimal Core APIs, that alone makes it a proper
and more efficient alternative solution
My point is that GC hate is not a fixed problem in D, and the
vision does little to fix it.
Meanwhile the language communities that embraced GC in embedded
deployment, are at least 20 years ahead in production deployments
versus D, where no GC keeps being a reason to rejoice, like the
the comment I replied to.
The future was when Andrei book came out.
