June 05, 2021

On Friday, 4 June 2021 at 21:35:43 UTC, IGotD- wrote:

>

On Friday, 4 June 2021 at 19:56:06 UTC, sighoya wrote:

>

This uniformization sounds too good to be true. I think most people think that, but it's simply not true. malloc/free is incompatible to garbage collection.

This is true and even druntime has a malloc/free option for the GC. However, its implementation is really bad. Also the implementation of the current GC has a lot of room for improvements. It is still not appropriate for many embedded systems as it requires another layer that steals CPU time and code memory.

Speaking of embedded,

https://learn.adafruit.com/welcome-to-circuitpython

https://blog.arduino.cc/2019/08/23/tinygo-on-arduino

https://www.microsoft.com/en-us/makecode/resources

http://www.ulisp.com/

https://developer.android.com/training/wearables/principles

https://www.microej.com/product/vee/

Meanwhile kids, the future generation of developers, keeps adopting the hardware and programming languages listed above, completly oblivious there is a programming language where all discussion threads turn into GC vs no-GC no matter what was the original subject.

June 05, 2021

On Saturday, 5 June 2021 at 08:58:47 UTC, Paulo Pinto wrote:

>

Meanwhile kids, the future generation of developers, keeps adopting the hardware and programming languages listed above,

D isn't useful for teaching kids programming. Waaaay too complicated. Most Arduino users, who build useful stuff, use C++.

But it is not a good strategy for D to become more like C++, too late. It would've been a good strategy 6 years ago to align D semantics with C++ and have full interop, but too late now.

D needs a feature-set that makes it attractive for people wanting to do high profile interactive stuff, like games, graphics editors, sound editors, high performance services. With useful optional GC and easy multithreading.

The current GC strategy is a dead end. No GC makes the language too much of a C++ with no real edge. D needs to offer something other languages do not, to offset the cost of learning the language complexities.

June 05, 2021

On Saturday, 5 June 2021 at 08:51:07 UTC, Ola Fosheim Grøstad wrote:

>

On Friday, 4 June 2021 at 18:34:32 UTC, Imperatorn wrote:

>

[...]

This is the announce forum, so it is kinda misplaced, but we are all contributing to this so... :)

[...]

I get your point, but I still think GC will remain mainly because of the area D is trying to cover.

June 05, 2021

On Saturday, 5 June 2021 at 09:47:11 UTC, Imperatorn wrote:

>

I get your point, but I still think GC will remain mainly because of the area D is trying to cover.

You mean the wait-for-everything-to-stop-scan-everything approach will remain?

What is the area that D is trying to cover though?

Somebody should write a memo on that.

June 05, 2021

On Friday, 4 June 2021 at 19:31:57 UTC, IGotD- wrote:

>

On Friday, 4 June 2021 at 18:34:32 UTC, Imperatorn wrote:

>

You might be surprised, but it's actually not up to you what topic fits or not.

I said GC-phobia is irrational, I did not say any criticism of it is.
Obviously GC is good for some things and not good at all for other things.

What is irrational is saying it has absolutely no place at all.

I don't think it is a phobia but it is a question of choice. We can clearly observe how different the demands are for different programmers in this forum. I enjoy GC for the appropriate programs, however there are SW where GC is a problem and cannot be used. Because of this Phobos must take the lowest common denominator approach (malloc/free) in order to be able to accommodate all the different needs.

D is one these Swiss army knife languages that can be used for everything, including low level software and everything in between. What D should strive for is to give programmers a choice and put up as few barriers as possible. It's certainly challenging to make a library and language fitting everyone needs but D is at least one of the best foundation of achieving that goal.

I agree with the description of a swiss army knife. Like if some comany/brand said they're removing the little saw, and there are many ppl who bought the knife mainly to be able to do some quick n dirty sawing, they would choose another company/brand.

June 07, 2021

On Saturday, 5 June 2021 at 09:58:23 UTC, Ola Fosheim Grøstad wrote:

>

You mean the wait-for-everything-to-stop-scan-everything approach will remain?

What is the area that D is trying to cover though?

Somebody should write a memo on that.

My use case of writing GUI apps for desktop - presence of GC does not matter for me at all. In fact its great for me. Hopefully D will not stop covering these use cases.

I know all the web-apps folks who wants to serve 100000000000000 requests per second will not like GC, I guess.

June 07, 2021

On Monday, 7 June 2021 at 18:37:54 UTC, sai wrote:

>

Hopefully D will not stop covering these use cases.

I know all the web-apps folks who wants to serve 100000000000000 requests per second will not like GC, I guess.

Absolutely not, D must continue with automatic memory management and I think about everybody agree with that.

The discussion is about how D can support different types of memory management and how to approach that, this is where the opinions are very different.

June 07, 2021

On Saturday, 5 June 2021 at 08:58:47 UTC, Paulo Pinto wrote:

>

On Friday, 4 June 2021 at 21:35:43 UTC, IGotD- wrote:

>

On Friday, 4 June 2021 at 19:56:06 UTC, sighoya wrote:

>

This uniformization sounds too good to be true. I think most people think that, but it's simply not true. malloc/free is incompatible to garbage collection.

This is true and even druntime has a malloc/free option for the GC. However, its implementation is really bad. Also the implementation of the current GC has a lot of room for improvements. It is still not appropriate for many embedded systems as it requires another layer that steals CPU time and code memory.

Speaking of embedded,

https://learn.adafruit.com/welcome-to-circuitpython

https://blog.arduino.cc/2019/08/23/tinygo-on-arduino

https://www.microsoft.com/en-us/makecode/resources

http://www.ulisp.com/

https://developer.android.com/training/wearables/principles

https://www.microej.com/product/vee/

Meanwhile kids, the future generation of developers, keeps adopting the hardware and programming languages listed above, completly oblivious there is a programming language where all discussion threads turn into GC vs no-GC no matter what was the original subject.

There is also https://micropython.org/

It would not be my choice of language for medical but uPython is used in a small number of embedded medical devices and has been ported to several flavours of STM32.

This is a space where D could make a difference, although unfortunately the language has some dark corner cases and friction that put some people off to the point where they don't see any benefit moving to D.

June 08, 2021

On Monday, 7 June 2021 at 23:04:12 UTC, Norm wrote:

>

On Saturday, 5 June 2021 at 08:58:47 UTC, Paulo Pinto wrote:

>

On Friday, 4 June 2021 at 21:35:43 UTC, IGotD- wrote:

>

On Friday, 4 June 2021 at 19:56:06 UTC, sighoya wrote:

>

This uniformization sounds too good to be true. I think most people think that, but it's simply not true. malloc/free is incompatible to garbage collection.

This is true and even druntime has a malloc/free option for the GC. However, its implementation is really bad. Also the implementation of the current GC has a lot of room for improvements. It is still not appropriate for many embedded systems as it requires another layer that steals CPU time and code memory.

Speaking of embedded,

https://learn.adafruit.com/welcome-to-circuitpython

https://blog.arduino.cc/2019/08/23/tinygo-on-arduino

https://www.microsoft.com/en-us/makecode/resources

http://www.ulisp.com/

https://developer.android.com/training/wearables/principles

https://www.microej.com/product/vee/

Meanwhile kids, the future generation of developers, keeps adopting the hardware and programming languages listed above, completly oblivious there is a programming language where all discussion threads turn into GC vs no-GC no matter what was the original subject.

There is also https://micropython.org/

I just skipped MicroPython, because Circuit Python seems to have more uptake even though it is based on it.

>

It would not be my choice of language for medical but uPython is used in a small number of embedded medical devices and has been ported to several flavours of STM32.

This is a space where D could make a difference, although unfortunately the language has some dark corner cases and friction that put some people off to the point where they don't see any benefit moving to D.

Exactly, and the whole GC vs no-GC take the language nowhere in that regard.

June 08, 2021

On Monday, 7 June 2021 at 18:37:54 UTC, sai wrote:

>

My use case of writing GUI apps for desktop - presence of GC does not matter for me at all. In fact its great for me. Hopefully D will not stop covering these use cases.

Great, I am interested in highly interactive apps (games, sound editors, graphics editors, audio plugins, etc).

Maybe we could create a focus group and collect experiences, approaches, weak spots, strong spots?

Right now I think many feel left in the dark when they come with an idea for an app as there is little guidance of how to build a bigger app.

I sense this by watching the learn-forum.