www.digitalmars.com         C & C++   DMDScript  

digitalmars.D - Is D really that bad?

reply Imperatorn <johan_forsberg_86 hotmail.com> writes:
Hi guys,

Just wanted to remind you that, D maybe isn't that bad.

We're very good at bashing our own language, but we should also 
remember sometimes what it has given us.

I have spent the last months going through other languages, and I 
can say, the grass is always not so much greener on the other 
side.

Yes, there are more mature languages.
Yes, there are languages with better ecosystems.

But, just as an example - Zig - which is getting attention, is 
according to the community itself (including its creator) not in 
1.0 until about 2025.

And still people use it, and might even think it's better than D.

Some information from their community (not my words)
It does **not** have a standardized package manager and build 
system.
It does **not** have an official registry of packages.
It **is** unstable.
It should **not** be used in production (actively advised 
against).
It changes so often that you can not rely on code to work even in 
1 month from now.
etc

And still, people still think Zig is better for some reason.

Yes, D has it's flaws, true. But it's far from unfixable? Or is 
that what people believe?

Forget about Jai, Odin, Beef and all those languages.

Go - Welcome rheumatism 👴
Rust - Welcome brain tumor from not even being able to prototype 
something in less than 2 years 😩
C++ - Welcome to hell 🔥
...

The only real language out there that is close to what D is/could 
be is Nim and I respect it.
But, its syntax is not that kind to those who loved the curly 
braces.

All I'm saying is - maybe it's best if we just fix D?

There is some valid criticism, like the risk for attribute soup 
etc. But maybe it's fixable?

Remember what D gives you in terms of UFCS, CTFE, 
metaprogramming, performance, package manager, prototyping, 
inline assembly, 3 compilers for different use cases etc.

Is D really that bad?
Oct 28 2022
next sibling parent reply IGotD- <nise nise.com> writes:
On Friday, 28 October 2022 at 09:51:04 UTC, Imperatorn wrote:

 Yes, D has it's flaws, true. But it's far from unfixable? Or is 
 that what people believe?

 Is D really that bad?


D is a good language but it has some obvious flaws that are 
easily recognizable and these can be fixed. The problem is the 
management and the total tone deafness/insight who refuse to 
recognize these often because of self manufactured dogmas. This 
is really frustrating as if the odds and ends could be fixed in 
the language it could bring it to a very competitive state. It's 
like falling over right before the finishing line. The only way 
out of this is if D is forked.
Oct 28 2022
next sibling parent Imperatorn <johan_forsberg_86 hotmail.com> writes:
On Friday, 28 October 2022 at 10:20:38 UTC, IGotD- wrote:

 On Friday, 28 October 2022 at 09:51:04 UTC, Imperatorn wrote:

 Yes, D has it's flaws, true. But it's far from unfixable? Or 
 is that what people believe?

 Is D really that bad?


 D is a good language but it has some obvious flaws that are 
 easily recognizable and these can be fixed. The problem is the 
 management and the total tone deafness/insight who refuse to 
 recognize these often because of self manufactured dogmas. This 
 is really frustrating as if the odds and ends could be fixed in 
 the language it could bring it to a very competitive state. 
 It's like falling over right before the finishing line. The 
 only way out of this is if D is forked.


I hope we can find a solution without forking ❤️
Oct 28 2022
prev sibling parent reply Walter Bright <newshound2 digitalmars.com> writes:
On 10/28/2022 3:20 AM, IGotD- wrote:

 D is a good language but it has some obvious flaws that are easily
recognizable 
 and these can be fixed. The problem is the management and the total tone 
 deafness/insight who refuse to recognize these often because of self 
 manufactured dogmas. This is really frustrating as if the odds and ends could
be 
 fixed in the language it could bring it to a very competitive state. It's like 
 falling over right before the finishing line. The only way out of this is if D 
 is forked.


You can fork it if you like. Feel free!

Meanwhile, last week I spent fixing some gaps in the XMM semantics (relational 
operators are now supported).

Before that, I went through every DIP1000 bugzilla issue, and submitted PRs for 
the problems.

Before that, I went through (again) the list of outstanding issues with ImportC 
and fixed the top problems.
Oct 28 2022
next sibling parent Imperatorn <johan_forsberg_86 hotmail.com> writes:
On Saturday, 29 October 2022 at 02:02:33 UTC, Walter Bright wrote:

 On 10/28/2022 3:20 AM, IGotD- wrote:

 [...]


 You can fork it if you like. Feel free!

 Meanwhile, last week I spent fixing some gaps in the XMM 
 semantics (relational operators are now supported).

 Before that, I went through every DIP1000 bugzilla issue, and 
 submitted PRs for the problems.

 Before that, I went through (again) the list of outstanding 
 issues with ImportC and fixed the top problems.


Thank you!
Oct 29 2022
prev sibling parent Timon Gehr <timon.gehr gmx.ch> writes:
On 10/29/22 04:02, Walter Bright wrote:

 On 10/28/2022 3:20 AM, IGotD- wrote:

 D is a good language but it has some obvious flaws that are easily 
 recognizable and these can be fixed. The problem is the management and 
 the total tone deafness/insight who refuse to recognize these often 
 because of self manufactured dogmas. This is really frustrating as if 
 the odds and ends could be fixed in the language it could bring it to 
 a very competitive state. It's like falling over right before the 
 finishing line. The only way out of this is if D is forked.


 
 You can fork it if you like. Feel free!
 ...


It is pretty standard procedure for contributing to D to fork the 
official repositories.

DMD alone has been forked over 600 times on github. I guess coordinating 
DMD development is just not so easy and we don't really have people with 
the requisite skills and motivation.


 Meanwhile, last week I spent fixing some gaps in the XMM semantics 
 (relational operators are now supported).
 
 Before that, I went through every DIP1000 bugzilla issue, and submitted 
 PRs for the problems.
 
 Before that, I went through (again) the list of outstanding issues with 
 ImportC and fixed the top problems.


Thank you! I wish I had more spare time. (And push access to DMD master ;] )
Oct 31 2022
prev sibling next sibling parent reply AnimusPEXUS <animuspexus protonmail.com> writes:
On Friday, 28 October 2022 at 09:51:04 UTC, Imperatorn wrote:

 Hi guys,
 Is D really that bad?


D isn't bad. D is good. it's just needs many bugfixing and more 
stability (without which it's complicated to even advertise it to 
use it for prod) and also it needs more stable and maintained 
tools (frameworks) for many things, like bindings for wayland and 
better wasm/wasi support. and more interesting things, like 
docker/kubernetes does for Go.

Also, I'm trying here to figure out how to write wasm runtime 
support (yes, I know about adr's one), and I think there should 
be better documentation/api generator/browser, like 
golang's/python's godoc/pydoc servers.
Oct 28 2022
next sibling parent Imperatorn <johan_forsberg_86 hotmail.com> writes:
On Friday, 28 October 2022 at 10:23:16 UTC, AnimusPEXUS wrote:

 On Friday, 28 October 2022 at 09:51:04 UTC, Imperatorn wrote:

 Hi guys,
 Is D really that bad?


 D isn't bad. D is good. it's just needs many bugfixing and more 
 stability (without which it's complicated to even advertise it 
 to use it for prod) and also it needs more stable and 
 maintained tools (frameworks) for many things, like bindings 
 for wayland and better wasm/wasi support. and more interesting 
 things, like docker/kubernetes does for Go.

 Also, I'm trying here to figure out how to write wasm runtime 
 support (yes, I know about adr's one), and I think there should 
 be better documentation/api generator/browser, like 
 golang's/python's godoc/pydoc servers.


I agree, but I think this could be fixed. We must have hope! 😎
Oct 28 2022
prev sibling parent Imperatorn <johan_forsberg_86 hotmail.com> writes:
On Friday, 28 October 2022 at 10:23:16 UTC, AnimusPEXUS wrote:

 On Friday, 28 October 2022 at 09:51:04 UTC, Imperatorn wrote:

 Hi guys,
 Is D really that bad?


 D isn't bad. D is good. it's just needs many bugfixing and more 
 stability (without which it's complicated to even advertise it 
 to use it for prod) and also it needs more stable and 
 maintained tools (frameworks) for many things, like bindings 
 for wayland and better wasm/wasi support. and more interesting 
 things, like docker/kubernetes does for Go.

 Also, I'm trying here to figure out how to write wasm runtime 
 support (yes, I know about adr's one), and I think there should 
 be better documentation/api generator/browser, like 
 golang's/python's godoc/pydoc servers.


What about this?

https://wiki.dlang.org/Generating_WebAssembly_with_LDC
Oct 29 2022
prev sibling next sibling parent reply zjh <fqbqrr 163.com> writes:
On Friday, 28 October 2022 at 09:51:04 UTC, Imperatorn wrote:

 Hi guys,
 ...


  It's not that bad, but there are `too few` people. `D` needs 
fresh blood, new ideas, organization, orientation, position, and 
reconstruction.
Need a priority `todo` list.
Oct 28 2022
next sibling parent zjh <fqbqrr 163.com> writes:
On Friday, 28 October 2022 at 11:25:32 UTC, zjh wrote:


 Need a priority `todo` list.



I often meet the `ceiling` on C++, so I have to rely on `macro` 
to help me.
`D`, It is clear that the community is `small`.and if bifurcated, 
it will go die.
It is impossible to develop a `language` that only `10` people 
use.

What `D` needs most is `rational positioning`, attracting `target 
talents` to join `D` and develop `D`.
Oct 28 2022
prev sibling next sibling parent Imperatorn <johan_forsberg_86 hotmail.com> writes:
On Friday, 28 October 2022 at 11:25:32 UTC, zjh wrote:

 On Friday, 28 October 2022 at 09:51:04 UTC, Imperatorn wrote:

 Hi guys,
 ...


  It's not that bad, but there are `too few` people. `D` needs 
 fresh blood, new ideas, organization, orientation, position, 
 and reconstruction.
 Need a priority `todo` list.


Agreed. Let's try to bring more people to D? Maybe we need more 
"hype" like Zig or whatever? No idea. But they languages are 
really hyped for no special reason, other than "it's a new cool 
thing".
Oct 28 2022
prev sibling parent reply zoujiaqing <zoujiaqing gmail.com> writes:
On Friday, 28 October 2022 at 11:25:32 UTC, zjh wrote:

 On Friday, 28 October 2022 at 09:51:04 UTC, Imperatorn wrote:

 Hi guys,
 ...


  It's not that bad, but there are `too few` people. `D` needs 
 fresh blood, new ideas, organization, orientation, position, 
 and reconstruction.
 Need a priority `todo` list.


D need OKR.

1. Better package manager (like .Net).
2. New memory management, Must be memory safe.(Swift & Rust).
3. Powerful problem analysis tool (like rust-analysis, golang 
pprof).
4. High performance concurrent objects are encapsulated in the 
standard library.
5. UI Framework (like MAUI).
6. Networking library (eventcore and hunt?).
7. Game engine.
Nov 01 2022
next sibling parent zjh <fqbqrr 163.com> writes:
On Tuesday, 1 November 2022 at 10:10:12 UTC, zoujiaqing wrote:


 1. Better package manager (like .Net).
 2. New memory management, Must be memory safe.(Swift & Rust).
 3. Powerful problem analysis tool (like rust-analysis, golang 
 pprof).
 4. High performance concurrent objects are encapsulated in the 
 standard library.
 5. UI Framework (like MAUI).
 6. Networking library (eventcore and hunt?).
 7. Game engine.


总之,`D`需要人.
Nov 01 2022
prev sibling next sibling parent zjh <fqbqrr 163.com> writes:
On Tuesday, 1 November 2022 at 10:10:12 UTC, zoujiaqing wrote:


 D need OKR.


搜索了下,目标关键成果.
不就是,`最优先`事项吗?就是一个排序,取最大的,都要搞一个名词概念.太搞笑了.
Nov 01 2022
prev sibling next sibling parent reply zjh <fqbqrr 163.com> writes:
On Tuesday, 1 November 2022 at 10:10:12 UTC, zoujiaqing wrote:


 D need OKR.

 1. Better package manager (like .Net).
 2. New memory management, Must be memory safe.(Swift & Rust).
 3. Powerful problem analysis tool (like rust-analysis, golang 
 pprof).
 4. High performance concurrent objects are encapsulated in the 
 standard library.
 5. UI Framework (like MAUI).
 6. Networking library (eventcore and hunt?).
 7. Game engine.


还是定位的问题,`D`定位在哪?要`聚焦`!这才是根本问题.
Nov 01 2022
parent Walter Bright <newshound2 digitalmars.com> writes:
On 11/1/2022 3:22 AM, zjh wrote:

 还是定位的问题,`D`定位在哪?要`聚焦`!这才是根本问题.


We prefer English be used on the forums.
Nov 05 2022
prev sibling parent reply Imperatorn <johan_forsberg_86 hotmail.com> writes:
On Tuesday, 1 November 2022 at 10:10:12 UTC, zoujiaqing wrote:

 On Friday, 28 October 2022 at 11:25:32 UTC, zjh wrote:

 On Friday, 28 October 2022 at 09:51:04 UTC, Imperatorn wrote:

 Hi guys,
 ...


  It's not that bad, but there are `too few` people. `D` needs 
 fresh blood, new ideas, organization, orientation, position, 
 and reconstruction.
 Need a priority `todo` list.


 D need OKR.

 1. Better package manager (like .Net).
 2. New memory management, Must be memory safe.(Swift & Rust).
 3. Powerful problem analysis tool (like rust-analysis, golang 
 pprof).
 4. High performance concurrent objects are encapsulated in the 
 standard library.
 5. UI Framework (like MAUI).
 6. Networking library (eventcore and hunt?).
 7. Game engine.


1. Package manager can be fixed, it's ok (I use nuget daily, ofc 
it's better but dub is ok).
2. Memory management is soon there (we have a bunch of this, 
live, safe, dip1000, custom allocators, gc, etc etc).
3. If you mean static analysis, then yes, that would be nice.
4. ?
5. We have a bunch, dlangui, dwt, gtk-d (works well), qt etc. We 
don't need more
6. We have
7. There are many, dagon for example, check 
https://wiki.dlang.org/Game_Development_and_Multimedia_Libraries
Nov 01 2022
next sibling parent reply Imperatorn <johan_forsberg_86 hotmail.com> writes:
On Tuesday, 1 November 2022 at 10:48:59 UTC, Imperatorn wrote:

 On Tuesday, 1 November 2022 at 10:10:12 UTC, zoujiaqing wrote:

 [...]


 1. Package manager can be fixed, it's ok (I use nuget daily, 
 ofc it's better but dub is ok).
 2. Memory management is soon there (we have a bunch of this, 
 live, safe, dip1000, custom allocators, gc, etc etc).
 3. If you mean static analysis, then yes, that would be nice.
 4. ?
 5. We have a bunch, dlangui, dwt, gtk-d (works well), qt etc. 
 We don't need more
 6. We have
 7. There are many, dagon for example, check 
 https://wiki.dlang.org/Game_Development_and_Multimedia_Libraries


I'm 97.7331% sure we don't need more of anything, just actual 
people writing things.

Just do it 💗
Nov 01 2022
parent reply Ola Fosheim =?UTF-8?B?R3LDuHN0YWQ=?= <ola.fosheim.grostad gmail.com> writes:
On Tuesday, 1 November 2022 at 10:52:35 UTC, Imperatorn wrote:

 I'm 97.7331% sure we don't need more of anything, just actual 
 people writing things.


If you want D to trend as you stated, then you most certainly 
need to fix things like alias not working properly and other 
"bugs", make language features work without GC, add a solid 
competitive memory management solution that isn't the current GC. 
You probably also need to clean up syntax and add things that 
people take for granted from modern languages such convenient 
tuple syntax and similar features that are now becoming 
mainstream in other languages that also try to compete with C++.
Nov 01 2022
parent reply Imperatorn <johan_forsberg_86 hotmail.com> writes:
On Tuesday, 1 November 2022 at 11:10:27 UTC, Ola Fosheim Grøstad 
wrote:

 On Tuesday, 1 November 2022 at 10:52:35 UTC, Imperatorn wrote:

 I'm 97.7331% sure we don't need more of anything, just actual 
 people writing things.


 If you want D to trend as you stated, then you most certainly 
 need to fix things like alias not working properly and other 
 "bugs", make language features work without GC, add a solid 
 competitive memory management solution that isn't the current 
 GC. You probably also need to clean up syntax and add things 
 that people take for granted from modern languages such 
 convenient tuple syntax and similar features that are now 
 becoming mainstream in other languages that also try to compete 
 with C++.


I'm 2.2669% sure that would make D trend
Nov 01 2022
parent reply Ola Fosheim =?UTF-8?B?R3LDuHN0YWQ=?= <ola.fosheim.grostad gmail.com> writes:
On Tuesday, 1 November 2022 at 12:08:46 UTC, Imperatorn wrote:

 I'm 2.2669% sure that would make D trend


That's the bare minimum for an alternative system level language 
in 2022+.
Nov 01 2022
next sibling parent reply Imperatorn <johan_forsberg_86 hotmail.com> writes:
On Tuesday, 1 November 2022 at 12:49:01 UTC, Ola Fosheim Grøstad 
wrote:

 On Tuesday, 1 November 2022 at 12:08:46 UTC, Imperatorn wrote:

 I'm 2.2669% sure that would make D trend


 That's the bare minimum for an alternative system level 
 language in 2022+.


So, with all this knowledge we have now.

How do we move forward?

Maybe even more important: WHO will move forward?

I'm not trying to create friction, but I get the sense that not 
everyone complaining wants to contribute to solving the problem 
they are complaining about.

D is a community project after all. If we want it to thrive we 
must all contribute, even just a little.
Nov 01 2022
parent reply Ola Fosheim =?UTF-8?B?R3LDuHN0YWQ=?= <ola.fosheim.grostad gmail.com> writes:
On Tuesday, 1 November 2022 at 13:08:30 UTC, Imperatorn wrote:

 I'm not trying to create friction, but I get the sense that not 
 everyone complaining wants to contribute to solving the problem 
 they are complaining about.


It is a matter of process and leadership. If you really care 
about this then the best option is to create a comprehensive 
design document where you go through everything that has to be 
"fixed" to get to a competitive position and adjust it to 
Walter's vision for the language, get him on board and then take 
it to the D foundation.


 D is a community project after all. If we want it to thrive we 
 must all contribute, even just a little.


You need to have a plan and fix the process before you try to fix 
other things. If you don't have a plan and don't have a process 
that backs up that plan then you just get to fix inconveniences 
(which I am sure people who already has adopted the language 
appreciate) but you don't get to position yourself in the market.

Asking people to do "something" or "more" without a realistic 
plan and a process does not make much sense to me.
Nov 01 2022
parent reply Paul Backus <snarwin gmail.com> writes:
On Tuesday, 1 November 2022 at 13:23:53 UTC, Ola Fosheim Grøstad 
wrote:

 On Tuesday, 1 November 2022 at 13:08:30 UTC, Imperatorn wrote:

 D is a community project after all. If we want it to thrive we 
 must all contribute, even just a little.


 You need to have a plan and fix the process before you try to 
 fix other things. If you don't have a plan and don't have a 
 process that backs up that plan then you just get to fix 
 inconveniences (which I am sure people who already has adopted 
 the language appreciate) but you don't get to position yourself 
 in the market.

 Asking people to do "something" or "more" without a realistic 
 plan and a process does not make much sense to me.


If you (or anyone else) would like to propose improvements to D's 
process, you can email Mike Parker and request an opportunity to 
discuss them at one of the D foundation's monthly meetings.

You may also wish to join forces with Mathias Lang, the author of 
the governance proposal discussed by the D foundation last year. 
[1]

[1] 
https://forum.dlang.org/post/rdqskizblbcdtahlxxsm forum.dlang.org
Nov 01 2022
next sibling parent reply M.M. <matus email.cz> writes:
On Tuesday, 1 November 2022 at 13:38:13 UTC, Paul Backus wrote:

 On Tuesday, 1 November 2022 at 13:23:53 UTC, Ola Fosheim 
 Grøstad wrote:

 On Tuesday, 1 November 2022 at 13:08:30 UTC, Imperatorn wrote:

 D is a community project after all. If we want it to thrive 
 we must all contribute, even just a little.


 You need to have a plan and fix the process before you try to 
 fix other things. If you don't have a plan and don't have a 
 process that backs up that plan then you just get to fix 
 inconveniences (which I am sure people who already has adopted 
 the language appreciate) but you don't get to position 
 yourself in the market.

 Asking people to do "something" or "more" without a realistic 
 plan and a process does not make much sense to me.


 If you (or anyone else) would like to propose improvements to 
 D's process, you can email Mike Parker and request an 
 opportunity to discuss them at one of the D foundation's 
 monthly meetings.

 You may also wish to join forces with Mathias Lang, the author 
 of the governance proposal discussed by the D foundation last 
 year. [1]

 [1] 
 https://forum.dlang.org/post/rdqskizblbcdtahlxxsm forum.dlang.org


There has been a lot of changes about all the management behind 
dlang development (e.g., the high-level vision document(s); the 
monthly board meetings; the reporting of those; making the 
hardware infrastructure more robust and less dependent on 
individuals; etc). I would call this a positive change, and 
certainly aligned with the many calls for better management, and 
would think the movement is right.
Nov 01 2022
parent reply Imperatorn <johan_forsberg_86 hotmail.com> writes:
On Tuesday, 1 November 2022 at 13:54:03 UTC, M.M. wrote:

 On Tuesday, 1 November 2022 at 13:38:13 UTC, Paul Backus wrote:

 [...]


 There has been a lot of changes about all the management behind 
 dlang development (e.g., the high-level vision document(s); the 
 monthly board meetings; the reporting of those; making the 
 hardware infrastructure more robust and less dependent on 
 individuals; etc). I would call this a positive change, and 
 certainly aligned with the many calls for better management, 
 and would think the movement is right.


I think so too. Things are on the right track. We just need more 
time.
Nov 01 2022
parent bachmeier <no spam.net> writes:
On Tuesday, 1 November 2022 at 14:48:37 UTC, Imperatorn wrote:

 On Tuesday, 1 November 2022 at 13:54:03 UTC, M.M. wrote:

 On Tuesday, 1 November 2022 at 13:38:13 UTC, Paul Backus wrote:

 [...]


 There has been a lot of changes about all the management 
 behind dlang development (e.g., the high-level vision 
 document(s); the monthly board meetings; the reporting of 
 those; making the hardware infrastructure more robust and less 
 dependent on individuals; etc). I would call this a positive 
 change, and certainly aligned with the many calls for better 
 management, and would think the movement is right.


 I think so too. Things are on the right track. We just need 
 more time.


More time for what? We've had a good language for years.
Nov 01 2022
prev sibling parent Ola Fosheim =?UTF-8?B?R3LDuHN0YWQ=?= <ola.fosheim.grostad gmail.com> writes:
On Tuesday, 1 November 2022 at 13:38:13 UTC, Paul Backus wrote:

 If you (or anyone else) would like to propose improvements to 
 D's process, you can email Mike Parker and request an 
 opportunity to discuss them at one of the D foundation's 
 monthly meetings.


It will have to be someone else (my spare time is currently 
exhausted).

It is really a matter of putting work into crafting a well 
thought out document that covers everything Walter would like to 
see happening. As long as one person has de facto veto power that 
is how it has to be, and it takes more work than a few hours.

Walter has stated quite clearly that he cares more about existing 
users than the users that D isn't capturing. People who use the 
language regularly have much less incentive to see changes as 
they already feel D is the best option. It is quite challenging 
to come up with a solution that would be market-oriented and also 
don't cause any friction with existing users.

I don't even know if Walter would have any interest in such a 
process.


 You may also wish to join forces with Mathias Lang, the author 
 of the governance proposal discussed by the D foundation last 
 year. [1]


I am not really sure if D is ready for a process like Python.
Nov 01 2022
prev sibling parent reply Bioinfornatics <bioinfornatics fedoraproject.org> writes:
On Tuesday, 1 November 2022 at 12:49:01 UTC, Ola Fosheim Grøstad 
wrote:

 On Tuesday, 1 November 2022 at 12:08:46 UTC, Imperatorn wrote:

 I'm 2.2669% sure that would make D trend


 That's the bare minimum for an alternative system level 
 language in 2022+.


Here is the problem D was designed originaly to be an application 
language (general purpose) as C++.
To be fast as C++ without its difficulty.

That is why D own a GC from the beginning ...

I do not understand why they are so many user that want to 
transform Dlang to transform it while they are C, Go, Rust, Swift 
...

I follow D since is v1 where the community was divided between 
two main library Phobos and tango.

Now, to me D have to normalize/standardize its syntax.

1. Choose its defaults as, mutable or immutable |  gc or  nogc | 
async, await vs fiber etc...
2. Release a v3
3. Follow the spirit of general propose language by adding more 
features into the standard library
+ Java do the cofee
+ Python is battery included
And so on ...
4. Promote some killer libraries (Gsoc is a good way to see those 
libraries as it is cuurently done). But they need to survive to 
this events, be maintained or added to the the std library.
What is the state of d dataframe? Mir ? D ai ? D web framework 
back and front included through wasm ?

To me, the community have to create those libraries instead to 
complain in order to transform an application language to a 
system language.
Nov 01 2022
next sibling parent Ola Fosheim =?UTF-8?B?R3LDuHN0YWQ=?= <ola.fosheim.grostad gmail.com> writes:
On Tuesday, 1 November 2022 at 21:48:35 UTC, Bioinfornatics wrote:

 Here is the problem D was designed originaly to be an 
 application language (general purpose) as C++.


C++ is system level, maybe most use D as an application level 
language, but Walter has been clear on D being system level. This 
thread seems to be about what it would take to make D trend (I 
presume in system level projects).

There is nothing wrong with catering to those that are happy D 
users today, but that wont make it trend in system level contexts.
Nov 01 2022
prev sibling next sibling parent Imperatorn <johan_forsberg_86 hotmail.com> writes:
On Tuesday, 1 November 2022 at 21:48:35 UTC, Bioinfornatics wrote:

 On Tuesday, 1 November 2022 at 12:49:01 UTC, Ola Fosheim 
 Grøstad wrote:

 [...]


 Here is the problem D was designed originaly to be an 
 application language (general purpose) as C++.
 To be fast as C++ without its difficulty.

 [...]


I agree with most of this
Nov 01 2022
prev sibling parent data pulverizer <data.pulverizer gmail.com> writes:
On Tuesday, 1 November 2022 at 21:48:35 UTC, Bioinfornatics wrote:

 4. Promote some killer libraries (Gsoc is a good way to see 
 those libraries as it is cuurently done). But they need to 
 survive to this events, be maintained or added to the the std 
 library.
 What is the state of d dataframe? Mir ? D ai ? D web framework 
 back and front included through wasm ?

 To me, the community have to create those libraries instead to 
 complain in order to transform an application language to a 
 system language.


My suspicion is that if we want inroads to scientific computing, 
D needs to create packages that provide seamless utility with 
current solutions. People are not going to learn D just to use 
yet another AI, dataframe, or linear algebra library or framework.

If an analyst is working in R or Python, you have to go to them, 
meaning that at first you speak their language. So a high quality 
alternative to a current tool that does something their's does 
not, perhaps it performs better or is easier to use and so forth 
with a backend in D.

In terms of getting "enthusiast" programmers to write D code, 
you'll need to persuade someone using Rcpp/cpp11 or even the new 
extendr (for Rust) that they are better off writing D code using 
something like embedr or whatever. This is where people will need 
to be persuaded why they should switch to D. Things like:

1. Performance - super-important in scientific computing. Can D 
stand up to C++ in those terms? Easy and well documented access 
to popular HPC frameworks.
2. Memory safety - if they already have Rust why should they use 
D? How memory safe is D?
3. Ecosystem - what does D's language ecosystem have to offer? 
This one is not a deal breaker but is still very important.
4. What's so special about D and why should they use it?

If this was 5-6 years ago, I'd have said that the barrier was 
much easier to penetrate, but now things have become much more 
competitive, and there are fewer low-hanging fruit. There are 
still opportunities out there but efforts need to be properly 
focused. I suspect it needs to be an ongoing affair rather than a 
summer project. It's not necessarily about expending a huge 
amount of resource, just finding the right focus to wedge the 
door open and then progressively capitalising.
Nov 01 2022
prev sibling parent zoujiaqing <zoujiaqing gmail.com> writes:
On Tuesday, 1 November 2022 at 10:48:59 UTC, Imperatorn wrote:

 On Tuesday, 1 November 2022 at 10:10:12 UTC, zoujiaqing wrote:

 On Friday, 28 October 2022 at 11:25:32 UTC, zjh wrote:

 On Friday, 28 October 2022 at 09:51:04 UTC, Imperatorn wrote:

 Hi guys,
 ...


  It's not that bad, but there are `too few` people. `D` needs 
 fresh blood, new ideas, organization, orientation, position, 
 and reconstruction.
 Need a priority `todo` list.


 D need OKR.

 1. Better package manager (like .Net).
 2. New memory management, Must be memory safe.(Swift & Rust).
 3. Powerful problem analysis tool (like rust-analysis, golang 
 pprof).
 4. High performance concurrent objects are encapsulated in the 
 standard library.
 5. UI Framework (like MAUI).
 6. Networking library (eventcore and hunt?).
 7. Game engine.


 1. Package manager can be fixed, it's ok (I use nuget daily, 
 ofc it's better but dub is ok).
 2. Memory management is soon there (we have a bunch of this, 
 live, safe, dip1000, custom allocators, gc, etc etc).
 3. If you mean static analysis, then yes, that would be nice.
 4. ?
 5. We have a bunch, dlangui, dwt, gtk-d (works well), qt etc. 
 We don't need more
 6. We have
 7. There are many, dagon for example, check 
 https://wiki.dlang.org/Game_Development_and_Multimedia_Libraries


1.
2. Zig is good idea?
3. OK.
4. stand library support for concurrent containers, such as 
lock-free queues.
5. These UI frameworks are pretty rudimentary compared to MAUI / 
Flutter / SwiftUI nad more.
6. Performance leaderboards have no implementation in D at all.
7. Waiting ..
6.
Nov 02 2022
prev sibling next sibling parent reply Ola Fosheim =?UTF-8?B?R3LDuHN0YWQ=?= <ola.fosheim.grostad gmail.com> writes:
On Friday, 28 October 2022 at 09:51:04 UTC, Imperatorn wrote:

 And still, people still think Zig is better for some reason.


I don't think it makes much sense to talk about better or worse 
without a use case. Zig seems to aim for embedded like settings, 
but I don't like the language design regardless, as of today. But 
that could change.



 Yes, D has it's flaws, true. But it's far from unfixable? Or is 
 that what people believe?


You cannot predict the future, but if you go 10 years back and 
identify things that ought to be fixed (in the sense that it 
would make the language more broadly appealing) and find that 
those issues are still there, then there must be something making 
it difficult to address. Could be the current compiler code base, 
could be other things.

Keeping the same process makes it improbable that there will be a 
significant change, for good or bad.


 Forget about Jai, Odin, Beef and all those languages.


Why forget about Jai? If it gains traction in a specific domain 
like games, why not use it?

(There are also plenty of others in the works: Carbon, Circle, 
C++2.0, V etc)
Oct 28 2022
parent reply Imperatorn <johan_forsberg_86 hotmail.com> writes:
On Friday, 28 October 2022 at 11:28:17 UTC, Ola Fosheim Grøstad 
wrote:

 On Friday, 28 October 2022 at 09:51:04 UTC, Imperatorn wrote:

 And still, people still think Zig is better for some reason.


 I don't think it makes much sense to talk about better or worse 
 without a use case. Zig seems to aim for embedded like 
 settings, but I don't like the language design regardless, as 
 of today. But that could change.



 Yes, D has it's flaws, true. But it's far from unfixable? Or 
 is that what people believe?


 You cannot predict the future, but if you go 10 years back and 
 identify things that ought to be fixed (in the sense that it 
 would make the language more broadly appealing) and find that 
 those issues are still there, then there must be something 
 making it difficult to address. Could be the current compiler 
 code base, could be other things.

 Keeping the same process makes it improbable that there will be 
 a significant change, for good or bad.


 Forget about Jai, Odin, Beef and all those languages.


 Why forget about Jai? If it gains traction in a specific domain 
 like games, why not use it?

 (There are also plenty of others in the works: Carbon, Circle, 
 C++2.0, V etc)


I see what you're saying. But you miss my point a bit. I know 
about all those languages and I have talked with the communities 
and got a peek inside. It's not really that appealing.

I seriously think we should try and "fix" D instead of chasing 
everything else.
Focus on expressiveness, plasticity and stability. We don't have 
to be best at *everything*, but we can be decent. Also I think, 
if we just fixed up some things, D would be pretty competitive 
(well, more than it is now), and become at least top 20 again. I 
don't think it has to be top 10. Top 25 is enough for more 
adoption.
Oct 28 2022
parent reply Ola Fosheim =?UTF-8?B?R3LDuHN0YWQ=?= <ola.fosheim.grostad gmail.com> writes:
On Friday, 28 October 2022 at 16:00:19 UTC, Imperatorn wrote:

 I seriously think we should try and "fix" D instead of chasing 
 everything else.
 Focus on expressiveness, plasticity and stability. We don't 
 have to be best at *everything*, but we can be decent.


Well, I am happy that there is a focus on no-gc support now, but 
I wonder if it will reach a competitive stage where language 
features dont rely on a GC. I dont sense any urgency in how this 
is approached, so maybe it wont happen.  Until then many looking 
for a system level programming alternative will choose another 
language. But then again maybe that low level market is getting 
saturated now and it would be better for D to become more high 
level...

Either way, defining a key type of application development that D 
should be best for is needed to define missing/incomplete 
features.

Without such a definition I think it will be difficult to agree 
on what to «fix» outside of obvious bugs.
Oct 28 2022
parent Imperatorn <johan_forsberg_86 hotmail.com> writes:
On Friday, 28 October 2022 at 20:59:58 UTC, Ola Fosheim Grøstad 
wrote:

 On Friday, 28 October 2022 at 16:00:19 UTC, Imperatorn wrote:

 I seriously think we should try and "fix" D instead of chasing 
 everything else.
 Focus on expressiveness, plasticity and stability. We don't 
 have to be best at *everything*, but we can be decent.


 Well, I am happy that there is a focus on no-gc support now, 
 but I wonder if it will reach a competitive stage where 
 language features dont rely on a GC. I dont sense any urgency 
 in how this is approached, so maybe it wont happen.  Until then 
 many looking for a system level programming alternative will 
 choose another language. But then again maybe that low level 
 market is getting saturated now and it would be better for D to 
 become more high level...

 Either way, defining a key type of application development that 
 D should be best for is needed to define missing/incomplete 
 features.

 Without such a definition I think it will be difficult to agree 
 on what to «fix» outside of obvious bugs.


Yeah, that's good. Also making phobos more "strict".

We'll see what happens. We shouldn't loose hope at least. Let's 
make our fair share of PRs, DIPs and bug reporting and I think we 
will be in quite good shape before 2025 :)
Oct 28 2022
prev sibling next sibling parent reply Guillaume Piolat <first.last spam.org> writes:
On Friday, 28 October 2022 at 09:51:04 UTC, Imperatorn wrote:

 Is D really that bad?


Do not take the forums sentiment as ground truth.

If you release a software, whatever its quality, the online 
forums are always way more critical and acerb that the general 
population of users. This has become more obvious in the last 
decade. Auburn Sounds recently released one the best compressor 
in the world (https://www.auburnsounds.com/products/Lens.html, 
sorry for SEO), and you can get it for free, so I was expecting 
_less_ criticism. Exactly the reverse happened, the better it is, 
the more any perceived flaw is painted as huge and 
"show-stopper". It attracts more criticism, like Bjarne said, in 
a way being good force users to use it and learn it.
Oct 28 2022
next sibling parent reply Andrej Mitrovic <andrej.mitrovich gmail.com> writes:
On Friday, 28 October 2022 at 11:39:12 UTC, Guillaume Piolat 
wrote:

 On Friday, 28 October 2022 at 09:51:04 UTC, Imperatorn wrote:

 Is D really that bad?


 Auburn Sounds recently released one the best compressor in the 
 world (https://www.auburnsounds.com/products/Lens.html, sorry 
 for SEO)


Sounds pretty good from the samples! Any reviews yet, or is it 
too new and we'll have to wait a bit? I'd love to read about it.
Oct 28 2022
parent Guillaume Piolat <first.last spam.org> writes:
On Friday, 28 October 2022 at 11:54:14 UTC, Andrej Mitrovic wrote:

 Sounds pretty good from the samples! Any reviews yet, or is it 
 too new and we'll have to wait a bit? I'd love to read about it.


Checkout its gearspace.com thread. There was so much new releases 
in September that no influencer or journalist had the time to try 
it. So it gets listed with PR copypasta, without actual trial. 
This is very common for this field, it is completely dominated by 
marketing. Actual reviews exist in italian and ukrainian AFAIK.
Oct 28 2022
prev sibling parent reply cc <cc nevernet.com> writes:
On Friday, 28 October 2022 at 11:39:12 UTC, Guillaume Piolat 
wrote:

 the better it is, the more any perceived flaw is painted as 
 huge and "show-stopper".


This is a truth I have encountered numerous times in game design. 
  The more rich and rewarding your feature set and environment 
are, the more it generates a sense of "well, if only it was 
BETTER, THEN it would be just what I wanted!"  The more 
restricted something is, the more content one remains with what 
has been accomplished within the bounds of the design.

And to respond to the OP, D is definitely good enough that I 
don't want to switch to anything else for this purpose when I 
don't have to!  And by good enough, I mean great.  I definitely 

ended up becoming for claiming the gaming industry (or at least 
squeezing alongside C++, which will sadly never leave us).  It's 
just a joy to program in, the metaprogramming capabilities are 
fantastic.  I don't know how to really quantify whether D does 
them "better" than other languages, but it always feels *cleaner* 
to me.  I am not a language design expert, I am just a humble 
tiller of the soil that is allotted to me.  But IMO D lets you 
write things that end up looking beautiful.  I put together a 
quick RPC module to call functions on client objects from their 
server representations in a multiplayer game engine.  All 
parameters matched for implicit conversions, marshaled, bundled 
and prepared for network sending.  Hard compiler errors on any 
mismatches.  Any method I want replicable, All I need to do is 
just drop a UDA onto it.  No complicated lookup tables or list of 
mangles or serialization definition documents.  No need to add 
any code or create stubs anywhere else in the project.  It all 
"just works".  The entire RPC module?  194 lines of code.  Brings 

gives me a headache.  C++?  Migraine.  And I do not care for Rust.


On Friday, 28 October 2022 at 13:23:42 UTC, Adam D Ruppe wrote:

 in fact

 d rox


This.  Although I do agree that allocators should be tuned up and 
taken out of experimental.  I would personally love to see 
alternative memory management strategies made to feel more "at 
home" as base language features, instead of tricks with structs 
and templates.  Just my pipedream.
Nov 01 2022
parent reply Imperatorn <johan_forsberg_86 hotmail.com> writes:
On Wednesday, 2 November 2022 at 03:10:47 UTC, cc wrote:

 On Friday, 28 October 2022 at 11:39:12 UTC, Guillaume Piolat 
 wrote:

 the better it is, the more any perceived flaw is painted as 
 huge and "show-stopper".


 This is a truth I have encountered numerous times in game 
 design.  The more rich and rewarding your feature set and 
 environment are, the more it generates a sense of "well, if 
 only it was BETTER, THEN it would be just what I wanted!"  The 
 more restricted something is, the more content one remains with 
 what has been accomplished within the bounds of the design.

 And to respond to the OP, D is definitely good enough that I 
 don't want to switch to anything else for this purpose when I 
 don't have to!  And by good enough, I mean great.  I definitely 

 ended up becoming for claiming the gaming industry (or at least 
 squeezing alongside C++, which will sadly never leave us).  
 It's just a joy to program in, the metaprogramming capabilities 
 are fantastic.  I don't know how to really quantify whether D 
 does them "better" than other languages, but it always feels 
 *cleaner* to me.  I am not a language design expert, I am just 
 a humble tiller of the soil that is allotted to me.  But IMO D 
 lets you write things that end up looking beautiful.  I put 
 together a quick RPC module to call functions on client objects 
 from their server representations in a multiplayer game engine. 
  All parameters matched for implicit conversions, marshaled, 
 bundled and prepared for network sending.  Hard compiler errors 
 on any mismatches.  Any method I want replicable, All I need to 
 do is just drop a UDA onto it.  No complicated lookup tables or 
 list of mangles or serialization definition documents.  No need 
 to add any code or create stubs anywhere else in the project.  
 It all "just works".  The entire RPC module?  194 lines of 
 code.  Brings a tear to my eye.  The thought of building the 

 do not care for Rust.


 On Friday, 28 October 2022 at 13:23:42 UTC, Adam D Ruppe wrote:

 in fact

 d rox


 This.  Although I do agree that allocators should be tuned up 
 and taken out of experimental.  I would personally love to see 
 alternative memory management strategies made to feel more "at 
 home" as base language features, instead of tricks with structs 
 and templates.  Just my pipedream.




the codebase by 20% without even trying. That's a huge win to me.

As everyone knows, the less code you must write, the fewer bugs 
you will have.

The expressiveness of D combined with its power is what does it 
for me. Being able to utilize CTFE and generate code at compile 
time is like magic sometimes. With D I never really feel that the 
language is what's holding me back, but rather my knowledge. I 

language.

The reason for making this thread was to get people the slow down 
and think about what it is they really want and need in a 
language. Because it is literally impossible for Zig (for 
example) to be better than D right now (sorry for picking on Zig, 
I could have chosen any other language). Impossible. Just take a 
look at some of the things I wrote in my initial post.

But *still* some people would choose it instead of D. I am 98.76% 
sure that's only because of hype/popularity than anything else. 
Which is really weird. Are we developers really not more 
sophisticated than that? We just chase the next shiny thing? 
Maybe, I honestly don't know. But I'm starting to think that 
might be it.

For example, if D in secret was rebranded to Olympus and given a 
new logo, maybe people would praise it as the best thing since 
sliced bread. "Have you heard of Olympus?" Omg it rocks!

But, D boulders.
Nov 02 2022
parent Imperatorn <johan_forsberg_86 hotmail.com> writes:
On Wednesday, 2 November 2022 at 09:11:43 UTC, Imperatorn wrote:

 On Wednesday, 2 November 2022 at 03:10:47 UTC, cc wrote:

 [...]




 reduced the codebase by 20% without even trying. That's a huge 
 win to me.

 [...]


Damn, I knew it already existed 😤

https://github.com/rottytooth/Olympus
Nov 02 2022
prev sibling next sibling parent reply Adam D Ruppe <destructionator gmail.com> writes:
On Friday, 28 October 2022 at 09:51:04 UTC, Imperatorn wrote:

 Is D really that bad?


quite the contrary

in fact

d rox
Oct 28 2022
next sibling parent reply Dukc <ajieskola gmail.com> writes:
On Friday, 28 October 2022 at 13:23:42 UTC, Adam D Ruppe wrote:

 On Friday, 28 October 2022 at 09:51:04 UTC, Imperatorn wrote:

 Is D really that bad?


 quite the contrary

 in fact

 d rox


in fact

D [boulderz](https://github.com/serpent-os/boulder)
Oct 28 2022
parent Imperatorn <johan_forsberg_86 hotmail.com> writes:
On Friday, 28 October 2022 at 14:10:04 UTC, Dukc wrote:

 On Friday, 28 October 2022 at 13:23:42 UTC, Adam D Ruppe wrote:

 On Friday, 28 October 2022 at 09:51:04 UTC, Imperatorn wrote:

 Is D really that bad?


 quite the contrary

 in fact

 d rox


 in fact

 D [boulderz](https://github.com/serpent-os/boulder)


Omg it boulders in real life now? 🥰
Oct 28 2022
prev sibling parent reply Imperatorn <johan_forsberg_86 hotmail.com> writes:
On Friday, 28 October 2022 at 13:23:42 UTC, Adam D Ruppe wrote:

 On Friday, 28 October 2022 at 09:51:04 UTC, Imperatorn wrote:

 Is D really that bad?


 quite the contrary

 in fact

 d rox


D rok
/Sean Connery
Oct 28 2022
parent reply Hipreme <msnmancini hotmail.com> writes:
Well, I have like 5 years + experience in programming. What I can 
say about D is that it is a really nice language. It does not 
feel that experimental as some people make it feels, but I guess 
there is just one point to make.

Although I had never done a project with a scope similar to 
Hipreme Engine before, I must say that it was frustrating finding 
compiler bugs, my other coding experiences being Javascript, Lua, 
C/C++ and Java. D was the first language that I was being able to 
find bugs that were not caused really by my logic, but the 
compiler itself. Obviously, when comparing D to languages such as 
C or Javascript, D is a lot more complex, it has many other 
features that most of the languages I've just mentioned here 
doesn't even have.

What I would say that D accepts many coding styles, this can 
bring unexpected bugs and that is a problem that hopefully will 
be solved as the time passes. I do believe that using these other 
languages using bleeding edge features will always make you find 
a compilation bug too.

At least I have been contributing on my own way to D's ecosystem 
as my project has been started in 2019 (it had an hiatus period), 
and it is still ongoing. As most people say: just use the 
language. I have impressed many people at interviews and made 
them interested in this language, so I believe this is a matter 
of time until it becomes really stable for every coding style.
Oct 28 2022
next sibling parent reply Imperatorn <johan_forsberg_86 hotmail.com> writes:
On Friday, 28 October 2022 at 16:22:52 UTC, Hipreme wrote:

 Well, I have like 5 years + experience in programming. What I 
 can say about D is that it is a really nice language. It does 
 not feel that experimental as some people make it feels, but I 
 guess there is just one point to make.

 [...]


Yes, I think since D is so moldable and allows for so much you 
sometimes get bugs.

But my bottom line is, I think we should fix those things instead 
of chasing other languages. 🍀
Oct 28 2022
parent reply Walter Bright <newshound2 digitalmars.com> writes:
On 10/28/2022 9:27 AM, Imperatorn wrote:

 But my bottom line is, I think we should fix those things instead of chasing 
 other languages. 🍀


People suggest that, and ask why doesn't D have sumtypes and pattern matching.
Oct 29 2022
parent Imperatorn <johan_forsberg_86 hotmail.com> writes:
On Saturday, 29 October 2022 at 09:11:56 UTC, Walter Bright wrote:

 On 10/28/2022 9:27 AM, Imperatorn wrote:

 But my bottom line is, I think we should fix those things 
 instead of chasing other languages. 🍀


 People suggest that, and ask why doesn't D have sumtypes and 
 pattern matching.


True 😂
Oct 29 2022
prev sibling parent jmh530 <john.michael.hall gmail.com> writes:
On Friday, 28 October 2022 at 16:22:52 UTC, Hipreme wrote:

 [snip]
 Although I had never done a project with a scope similar to 
 Hipreme Engine before, I must say that it was frustrating 
 finding compiler bugs, my other coding experiences being 
 Javascript, Lua, C/C++ and Java. D was the first language that 
 I was being able to find bugs that were not caused really by my 
 logic, but the compiler itself. Obviously, when comparing D to 
 languages such as C or Javascript, D is a lot more complex, it 
 has many other features that most of the languages I've just 
 mentioned here doesn't even have.
 [snip]


Please report any bugs to https://issues.dlang.org/
Oct 28 2022
prev sibling next sibling parent reply ryuukk_ <ryuukk.dev gmail.com> writes:
When people say we have pattern matching and they use a template 
to prove their point, it doesn't attract people, it drive them 
away

When you still have to call enums like this 
``MySuperLongInnerScope.MySuperLongEnum.MySuperLongValueA``, and 
people tell you, just us ``with``, it drive people away

When you have a GC that is slower than GO's GC and people tell 
you, it's the best and you should not care about allocations and 
allocators stays in experimental for YEARS, then it drive people 
away

When people tell you D is super fast at compiling code, but then 
you try the most popular D library (VibeD) it tanks your compile 
speed, it drive people away


It's the little things that stacks up, it's not longer 2004, 
there are ton of languages nowadays, so the excuses you had 
before are no longer valid

D needs a spring cleaning, then people will start to recognize D 
for what it is, one of the greatest language!

For that to remain true, it needs to clean itself up and to catch 
up with other languages
Oct 28 2022
parent reply Adam D Ruppe <destructionator gmail.com> writes:
On Friday, 28 October 2022 at 13:43:54 UTC, ryuukk_ wrote:

 When people say we have pattern matching and they use a 
 template to prove their point, it doesn't attract people, it 
 drive them away


What would it take to drive you away?

Apparently none of these things are actually deal breakers, even 
to you.
Oct 28 2022
parent reply ryuukk_ <ryuukk.dev gmail.com> writes:
On Friday, 28 October 2022 at 14:03:52 UTC, Adam D Ruppe wrote:

 On Friday, 28 October 2022 at 13:43:54 UTC, ryuukk_ wrote:

 When people say we have pattern matching and they use a 
 template to prove their point, it doesn't attract people, it 
 drive them away


 What would it take to drive you away?

 Apparently none of these things are actually deal breakers, 
 even to you.


It does drive me away, hence why i dab with zig a little, even 
thought i hate its ergonomics, it has the features that matter to 
me as builtin language feature

You should try more languages and expand your knowledge, people 
are coming up with great ideas, hence why i try to push them 
here, contrary to most people here, i want D to grow, and it 
starts by acknowledging your shortcomings
Oct 28 2022
next sibling parent "H. S. Teoh" <hsteoh qfbox.info> writes:
On Fri, Oct 28, 2022 at 02:09:29PM +0000, ryuukk_ via Digitalmars-d wrote:

 On Friday, 28 October 2022 at 14:03:52 UTC, Adam D Ruppe wrote:


[...]

 What would it take to drive you away?
 
 Apparently none of these things are actually deal breakers, even to
 you.


 
 It does drive me away, [...]
 [...] i want D to grow, [...]


No contradiction here.  None at all.  Move along, nothing to see here.

;-)


T

-- 
Turning your clock 15 minutes ahead won't cure lateness---you're just making
time go faster!
Oct 28 2022
prev sibling parent reply Walter Bright <newshound2 digitalmars.com> writes:
On 10/28/2022 7:09 AM, ryuukk_ wrote:

 i dab with zig a little, even thought i hate 
 its ergonomics, it has the features that matter to me as builtin language
feature


zig doesn't have a gc. D's gc is optional.


 i want D to grow, and it starts by acknowledging your shortcomings



 a GC that is slower than GO's GC


And I acknowledge that. It will never be as fast as GO's GC. The reason is a 
technical one. GO is a GC-only language, which means it is optimized for the
GC. 
All GO allocations are allocated on the GC heap, although it does do escape 
analysis to figure out what can be allocated on the stack instead. (Java does 
this as well.)

With such heavy GC allocation, a reasonable tradeoff is to insert "write gates" 
on every write through a pointer. This informs the GC that the allocation is 
"dirty" and so can be moved to more recently used places. These write gates
slow 
the code down, but they speed up the GC even more, and so they are worth while.

The GO GC can also take advantage of always knowing exactly where all the GC 
pointers are, because there are only GC pointers. This enables a moving GC, 
which "compacts" fragmented memory.

When GC is optional, or used rather rarely, as in D, the write gate technique
is 
a net loser. The GC is sped up at the cost of slowing everything else down. And 
since there are all kinds of pointers in D, one no longer can use a moving GC 
allocator, because it cannot know exactly where 100% of the GC pointers are.

If there was a way around these two issues, we would have found it by now. But 
by adding write gates, and making GC pointers the only pointers, D won't be 
systems programming language anymore.

So why does D have a GC at all?

1. It enables a killer feature - CTFE that can allocate memory. C++ doesn't do 
that. Zig doesn't do that.

2. Choice is nice. For example, I prefer to use the GC for initialization work, 
and the inner loop gets manual allocation. I get the best of both.
Oct 28 2022
next sibling parent reply Araq <rumpf_a web.de> writes:
On Saturday, 29 October 2022 at 04:46:21 UTC, Walter Bright wrote:

 If there was a way around these two issues, we would have found 
 it by now.


It's very easy to "work around these two issues" but you cannot 
see it because of DOS's NEAR and FAR pointers. If that sounds 
totally absurd, it's because it is.


 1. It enables a killer feature - CTFE that can allocate memory. 
 C++ doesn't do that. Zig doesn't do that.


And Nim does that easily too without butchering the type system. 
There simply is no reason to conflate managed with unmanaged 
pointers.
Oct 28 2022
next sibling parent Imperatorn <johan_forsberg_86 hotmail.com> writes:
On Saturday, 29 October 2022 at 06:28:02 UTC, Araq wrote:

 On Saturday, 29 October 2022 at 04:46:21 UTC, Walter Bright 
 wrote:

 If there was a way around these two issues, we would have 
 found it by now.


 It's very easy to "work around these two issues" but you cannot 
 see it because of DOS's NEAR and FAR pointers. If that sounds 
 totally absurd, it's because it is.


 1. It enables a killer feature - CTFE that can allocate 
 memory. C++ doesn't do that. Zig doesn't do that.


 And Nim does that easily too without butchering the type 
 system. There simply is no reason to conflate managed with 
 unmanaged pointers.


I agree Nim does some things a lot better, I do.
On the other hand D has a better community than Nim.

In the end, everything is a trade off.
Oct 29 2022
prev sibling parent Walter Bright <newshound2 digitalmars.com> writes:
Ok, I'll byte. Present an actual design that will work with D.
Oct 29 2022
prev sibling next sibling parent Bruce Carneal <bcarneal gmail.com> writes:
On Saturday, 29 October 2022 at 04:46:21 UTC, Walter Bright wrote:

 On 10/28/2022 7:09 AM, ryuukk_ wrote:


...

 i want D to grow, and it starts by acknowledging your 
 shortcomings


 a GC that is slower than GO's GC

 And I acknowledge that. It will never be as fast as GO's GC. 
 The reason is a technical one. GO is a GC-only language, which 
 means it is optimized for the GC. All GO allocations are 
 allocated on the GC heap...



 With such heavy GC allocation, a reasonable tradeoff is to 
 insert "write gates" on every write through a pointer. This 
 informs the GC that the allocation is "dirty" and so can be 
 moved ...


...

 The GO GC can also take advantage of always knowing exactly 
 where all the GC pointers are, because there are only GC 
 pointers. This enables a moving GC, which "compacts" fragmented 
 memory.


 From https://go.dev/blog/ismmkeynote "Getting to Go: The Journey 
of Go's garbage collector" I gather that the initial goal of 
general compacting was abandoned and that the purpose of the 
write barriers is to maintain tri-color invariants 
(white/black/gray) when the GC is active.

Perhaps I've misunderstood something?
Oct 28 2022
prev sibling next sibling parent reply Piotr Duda <duda.piotr gmail.com> writes:
On Saturday, 29 October 2022 at 04:46:21 UTC, Walter Bright wrote:

 With such heavy GC allocation, a reasonable tradeoff is to 
 insert "write gates" on every write through a pointer. This 
 informs the GC that the allocation is "dirty" and so can be 
 moved to more recently used places. These write gates slow the 
 code down, but they speed up the GC even more, and so they are 
 worth while.


If by "write gates" You mean additional code generated for every 
write, then you don't need it, You can use GetWriteWatch (on 
windows) or mprotect and signal handling (on linux, and probably 
other posix compliant OSes) to get list of modified pages on GC 
heap.


 The GO GC can also take advantage of always knowing exactly 
 where all the GC pointers are, because there are only GC 
 pointers. This enables a moving GC, which "compacts" fragmented 
 memory.


You don't need to know where **all** GC pointers are (in the 
sense that you know if something is pointer or not), if You don't 
know if something is pointer or not (because for example it's 
part of union) just pin pointed object to prevent it from being 
moved.


 When GC is optional, or used rather rarely, as in D, the write 
 gate technique is a net loser. The GC is sped up at the cost of 
 slowing everything else down. And since there are all kinds of 
 pointers in D, one no longer can use a moving GC allocator, 
 because it cannot know exactly where 100% of the GC pointers 
 are.

 If there was a way around these two issues, we would have found 
 it by now. But by adding write gates, and making GC pointers 
 the only pointers, D won't be systems programming language 
 anymore.


So since there is no need to add write gates and making GC 
pointers the only pointers, it should be possible.
Oct 29 2022
parent Walter Bright <newshound2 digitalmars.com> writes:
On 10/29/2022 1:12 AM, Piotr Duda wrote:

 If by "write gates" You mean additional code generated for every write, then
you 
 don't need it, You can use GetWriteWatch (on windows) or mprotect and signal 
 handling (on linux, and probably other posix compliant OSes) to get list of 
 modified pages on GC heap.


I once tried an implementation that would set the virtual page to read-only,
and 
then capture the seg fault when it was written to. This turned out to be quite
a 
bit slower.

Hey, I have no problem with being wrong. I welcome a design for a better GC.

Go ahead, make my day :-)
Oct 29 2022
prev sibling next sibling parent reply rikki cattermole <rikki cattermole.co.nz> writes:
I have long argued that we should support it as an opt-in flag.

Because right now, if someone wants to experiment with these more 
powerful GC designs that can't. So there is no evidence that they 
couldn't benefit D.

At the very least it could generate some very interesting research 
papers if we find the right person to try it out. Especially for GC 
heavy applications like web services (vibe.d).
Oct 29 2022
next sibling parent Walter Bright <newshound2 digitalmars.com> writes:
On 10/29/2022 1:28 AM, rikki cattermole wrote:

 I have long argued that we should support it as an opt-in flag.
 
 Because right now, if someone wants to experiment with these more powerful GC 
 designs that can't. So there is no evidence that they couldn't benefit D.
 
 At the very least it could generate some very interesting research papers if
we 
 find the right person to try it out. Especially for GC heavy applications like 
 web services (vibe.d).


I'd love to see one of you do this.
Oct 29 2022
prev sibling parent reply Imperatorn <johan_forsberg_86 hotmail.com> writes:
On Saturday, 29 October 2022 at 08:28:22 UTC, rikki cattermole 
wrote:

 I have long argued that we should support it as an opt-in flag.

 Because right now, if someone wants to experiment with these 
 more powerful GC designs that can't. So there is no evidence 
 that they couldn't benefit D.

 At the very least it could generate some very interesting 
 research papers if we find the right person to try it out. 
 Especially for GC heavy applications like web services (vibe.d).


For anyone reading this, if you want to be a hero and remembered 
for all eternity, improve the D GC.
Oct 29 2022
parent reply Walter Bright <newshound2 digitalmars.com> writes:
On 10/29/2022 2:18 AM, Imperatorn wrote:

 For anyone reading this, if you want to be a hero and remembered for all 
 eternity, improve the D GC.


It's literally impossible for me to stop anyone who wants to improve the GC. 
It's all open source, and Boost licensed. It's even designed to be pluggable.

Make a better one, and we'll incorporate it.

I'll be happy to be shown to be wrong about it.
Oct 29 2022
next sibling parent rikki cattermole <rikki cattermole.co.nz> writes:
On 29/10/2022 10:42 PM, Walter Bright wrote:

 On 10/29/2022 2:18 AM, Imperatorn wrote:

 For anyone reading this, if you want to be a hero and remembered for 
 all eternity, improve the D GC.


 
 It's literally impossible for me to stop anyone who wants to improve the 
 GC. It's all open source, and Boost licensed. It's even designed to be 
 pluggable.
 
 Make a better one, and we'll incorporate it.
 
 I'll be happy to be shown to be wrong about it.


There is even a low hanging feature that would potentially improve the 
current one on Windows, snapshot support!

(shame I never did find where it needed modifying)
Oct 29 2022
prev sibling next sibling parent reply IGotD- <nise nise.com> writes:
On Saturday, 29 October 2022 at 09:42:32 UTC, Walter Bright wrote:

 It's literally impossible for me to stop anyone who wants to 
 improve the GC. It's all open source, and Boost licensed. It's 
 even designed to be pluggable.


No they can't because D doesn't have a built in managed pointer 
type and they are limited to a subset of GC algorithms (even 
limited among the tracing GC ones).

It is possible to use a library custom GC type but then 
runtime/phobos don't use these so replacing the GC in the entire 
program isn't possible.

Many have tried to explain this numerous times but you just 
ignore this obvious fact.
Oct 29 2022
next sibling parent reply Imperatorn <johan_forsberg_86 hotmail.com> writes:
On Saturday, 29 October 2022 at 10:04:01 UTC, IGotD- wrote:

 On Saturday, 29 October 2022 at 09:42:32 UTC, Walter Bright 
 wrote:

 It's literally impossible for me to stop anyone who wants to 
 improve the GC. It's all open source, and Boost licensed. It's 
 even designed to be pluggable.


 No they can't because D doesn't have a built in managed pointer 
 type and they are limited to a subset of GC algorithms (even 
 limited among the tracing GC ones).

 It is possible to use a library custom GC type but then 
 runtime/phobos don't use these so replacing the GC in the 
 entire program isn't possible.

 Many have tried to explain this numerous times but you just 
 ignore this obvious fact.


What would be some theoretical ways to improve?

For example, adding a custom gc type, are we talking months or 
work? Years? What would it look like? Sorry for being ignorant on 
this
Oct 29 2022
parent reply Sergey <kornburn yandex.ru> writes:
On Saturday, 29 October 2022 at 10:17:13 UTC, Imperatorn wrote:

 What would be some theoretical ways to improve?

 For example, adding a custom gc type, are we talking months or 
 work? Years? What would it look like? Sorry for being ignorant 
 on this


The post currently is unavailable, but maybe some google cache or 
time-machine could find it: 
https://news.ycombinator.com/item?id=14592457
Oct 29 2022
parent reply Stefan Hertenberger <SHertenberger Web.de> writes:
On Saturday, 29 October 2022 at 16:02:34 UTC, Sergey wrote:

 On Saturday, 29 October 2022 at 10:17:13 UTC, Imperatorn wrote:

 What would be some theoretical ways to improve?

 For example, adding a custom gc type, are we talking months or 
 work? Years? What would it look like? Sorry for being ignorant 
 on this


 The post currently is unavailable, but maybe some google cache 
 or time-machine could find it: 
 https://news.ycombinator.com/item?id=14592457


[Inside D's 
GC](https://web.archive.org/web/20180622071748/https://olshansky.me//gc/runtime/dlang/2017/06/14/inside-d-gc.html)
Oct 29 2022
parent Sergey <kornburn yandex.ru> writes:
On Saturday, 29 October 2022 at 17:19:11 UTC, Stefan Hertenberger 
wrote:

 On Saturday, 29 October 2022 at 16:02:34 UTC, Sergey wrote:

 [Inside D's 
 GC](https://web.archive.org/web/20180622071748/https://olshansky.me//gc/runtime/dlang/2017/06/14/inside-d-gc.html)


Thank you!

Does anyone know how many bullet-points already implemented from 
the list?
Oct 30 2022
prev sibling next sibling parent reply Walter Bright <newshound2 digitalmars.com> writes:
On 10/29/2022 3:04 AM, IGotD- wrote:

 No they can't because D doesn't have a built in managed pointer type and they 
 are limited to a subset of GC algorithms (even limited among the tracing GC
ones).
 
 It is possible to use a library custom GC type but then runtime/phobos don't
use 
 these so replacing the GC in the entire program isn't possible.
 
 Many have tried to explain this numerous times but you just ignore this
obvious 
 fact.


I didn't ignore it.

I've pointed out the problems with two hierarchies of pointers many times. I 
lived with it for years in the DOS world. It's a mess, and was only used on DOS 
out of desperation.

I know about C++/CLI. No thanks.
Oct 29 2022
next sibling parent reply IGotD- <nise nise.com> writes:
On Saturday, 29 October 2022 at 10:35:21 UTC, Walter Bright wrote:

 I didn't ignore it.

 I've pointed out the problems with two hierarchies of pointers 
 many times. I lived with it for years in the DOS world. It's a 
 mess, and was only used on DOS out of desperation.

 I know about C++/CLI. No thanks.


Your analogy with bizarre addressing modes and HW limitation of 
early x86 processors doesn't make any sense. Also, the design 
with far/near pointers in those compilers is questionable and 
further fuels the point that pointers need to be opaque and the 
compiler should deal with such mess.

None the less the argument with far/near to totally irrelevant 
today has nothing to do with the managed/raw pointer separation. 
You fail to understand that this limits the usage of the D 
language and thusly fails to become a general purpose system 
language that can suit different needs. This is one of the 
problems with the D project that you limit further evolution of 
the language using obvious flawed arguments. The results of that 
is clear, that D doesn't in increase in popularity.
Oct 29 2022
next sibling parent reply Imperatorn <johan_forsberg_86 hotmail.com> writes:
On Saturday, 29 October 2022 at 11:39:14 UTC, IGotD- wrote:

 On Saturday, 29 October 2022 at 10:35:21 UTC, Walter Bright 
 wrote:

 [...]


 Your analogy with bizarre addressing modes and HW limitation of 
 early x86 processors doesn't make any sense. Also, the design 
 with far/near pointers in those compilers is questionable and 
 further fuels the point that pointers need to be opaque and the 
 compiler should deal with such mess.

 [...]


What solution do you propose?
Oct 29 2022
parent reply IGotD- <nise nise.com> writes:
On Saturday, 29 October 2022 at 11:59:24 UTC, Imperatorn wrote:

 Your analogy with bizarre addressing modes and HW limitation 
 of early x86 processors doesn't make any sense. Also, the 
 design with far/near pointers in those compilers is 
 questionable and further fuels the point that pointers need to 
 be opaque and the compiler should deal with such mess.

 [...]


 What solution do you propose?


For D or ancient C compilers?
Oct 29 2022
parent reply Imperatorn <johan_forsberg_86 hotmail.com> writes:
On Saturday, 29 October 2022 at 12:05:40 UTC, IGotD- wrote:

 On Saturday, 29 October 2022 at 11:59:24 UTC, Imperatorn wrote:

 Your analogy with bizarre addressing modes and HW limitation 
 of early x86 processors doesn't make any sense. Also, the 
 design with far/near pointers in those compilers is 
 questionable and further fuels the point that pointers need 
 to be opaque and the compiler should deal with such mess.

 [...]


 What solution do you propose?


 For D or ancient C compilers?


For D
Oct 29 2022
parent IGotD- <nise nise.com> writes:
On Saturday, 29 October 2022 at 12:37:52 UTC, Imperatorn wrote:

 On Saturday, 29 October 2022 at 12:05:40 UTC, IGotD- wrote:

 For D or ancient C compilers?


 For D


I suggest a "built in" raw pointer type and a managed pointer 
type. The raw pointer type should not be used in safe D 
programming because safe D relies on garbage collection. The 
entire druntime/phobos should be changed in order to use the 
managed pointers instead for any raw pointers (unless special 
cases). The functionality of the managed pointer type should be 
able to be completely customized in order to support all sorts of 
different GC algorithms.
Oct 29 2022
prev sibling parent reply Walter Bright <newshound2 digitalmars.com> writes:
On 10/29/2022 4:39 AM, IGotD- wrote:

 None the less the argument with far/near to totally irrelevant today has
nothing 
 to do with the managed/raw pointer separation.


I looked (briefly) at some online C++/CLI code. The __gc annotation looks just 
like __near/__far, and is applied in the same places.
Oct 29 2022
parent reply Paulo Pinto <pjmlp progtools.org> writes:
On Saturday, 29 October 2022 at 20:03:46 UTC, Walter Bright wrote:

 On 10/29/2022 4:39 AM, IGotD- wrote:

 None the less the argument with far/near to totally irrelevant 
 today has nothing to do with the managed/raw pointer 
 separation.


 I looked (briefly) at some online C++/CLI code. The __gc 
 annotation looks just like __near/__far, and is applied in the 
 same places.


Again mixing languages,

__gc is from Managed C++, .NET 1.0

C++/CLI, .NET 2.0 onwards, uses ^ for reference types and gcnew 
for GC heap.
Oct 29 2022
parent reply Walter Bright <newshound2 digitalmars.com> writes:
On 10/29/2022 1:11 PM, Paulo Pinto wrote:

 Again mixing languages,
 
 __gc is from Managed C++, .NET 1.0
 
 C++/CLI, .NET 2.0 onwards, uses ^ for reference types and gcnew for GC heap.


What's the difference between __gc* and ^ ?
Oct 29 2022
parent reply Paulo Pinto <pjmlp progtools.org> writes:
On Sunday, 30 October 2022 at 01:51:46 UTC, Walter Bright wrote:

 On 10/29/2022 1:11 PM, Paulo Pinto wrote:

 Again mixing languages,
 
 __gc is from Managed C++, .NET 1.0
 
 C++/CLI, .NET 2.0 onwards, uses ^ for reference types and 
 gcnew for GC heap.


 What's the difference between __gc* and ^ ?


Between Managed C++ and C++/CLI, none.

The latter replaces the former, Managed C++ died with .NET 2.0 
release.

If we also bring C++/CX into the picture, ^ is a tracing GC 
pointer to .NET types in C++/CLI, while on C++/CX it is compiler 
native support for COM types with the compiler doing 
AddRef/Release calls on its own.

In modern native frameworks, WRL, WIL and C++/WinRT, the ^ get 
replaced by library smart pointer classes.
Oct 29 2022
parent Walter Bright <newshound2 digitalmars.com> writes:
On 10/29/2022 11:48 PM, Paulo Pinto wrote:

 On Sunday, 30 October 2022 at 01:51:46 UTC, Walter Bright wrote:

 On 10/29/2022 1:11 PM, Paulo Pinto wrote:

 Again mixing languages,

 __gc is from Managed C++, .NET 1.0

 C++/CLI, .NET 2.0 onwards, uses ^ for reference types and gcnew for GC heap.


 What's the difference between __gc* and ^ ?


 
 Between Managed C++ and C++/CLI, none.
 
 The latter replaces the former, Managed C++ died with .NET 2.0 release.
 
 If we also bring C++/CX into the picture, ^ is a tracing GC pointer to .NET 
 types in C++/CLI, while on C++/CX it is compiler native support for COM types 
 with the compiler doing AddRef/Release calls on its own.
 
 In modern native frameworks, WRL, WIL and C++/WinRT, the ^ get replaced by 
 library smart pointer classes.


Thank you for the explanation. It's a syntactical change, not a semantic one.
Oct 30 2022
prev sibling parent reply Adam D Ruppe <destructionator gmail.com> writes:
On Saturday, 29 October 2022 at 10:35:21 UTC, Walter Bright wrote:

 I've pointed out the problems with two hierarchies of pointers 
 many times.


D already has several kinds of pointers. T*, const(T)*, 
shared(T)*. I don't see how unmanaged(T*) is any different.

In fact, I sketched up some thoughts i might put in the blog 
monday but the short of it is you could:

* -ptrcheck=[none|barrier] argument to the compiler, similar to 
how -checkaction and -boundscheck can be modified.

* all pointer writes assumed to be barriered except ones marked 
raw/unmanaged/whatever, which is a qualifier similar to const and 
shared

* the raw pointer would essentially be struct raw(T) { T it; 
alias it this; void opAssign(T rhs) { barrier(); it = rhs; } }

* possible optimizations would be eliding the barrier in cases 
like `a = a[1 .. $]` because you know - thanks to the bounds 
check - that this refers to the same memory block anyway and is 
thus irrelevant to the GC wrt marking. I guess it can be trouble 
if it wants to move tings in the middle of the slice operation 
though.


I'm not convinced this is impossible.

(btw im also not convinced it is necessary, i think D's gc is 
good enough as it is.)
Oct 29 2022
parent reply Walter Bright <newshound2 digitalmars.com> writes:
On 10/29/2022 5:18 AM, Adam D Ruppe wrote:

 On Saturday, 29 October 2022 at 10:35:21 UTC, Walter Bright wrote:

 I've pointed out the problems with two hierarchies of pointers many times.


 
 D already has several kinds of pointers. T*, const(T)*, shared(T)*. I don't
see 
 how unmanaged(T*) is any different.


Consider:

      strcpy(char* p, const(char)* q)

Now consider managed:

      strcpy(char* p, const(char)* q)
      strcpy(char* p, managed(const(char)*) q)
      strcpy(managed(char*) p, const(char)* q)
      strcpy(managed(char*) p, managed(const(char)*) q)

It's quite different.



 In fact, I sketched up some thoughts i might put in the blog monday but the 
 short of it is you could:
 
 * -ptrcheck=[none|barrier] argument to the compiler, similar to how
-checkaction 
 and -boundscheck can be modified.
 
 * all pointer writes assumed to be barriered except ones marked 
 raw/unmanaged/whatever, which is a qualifier similar to const and shared
 
 * the raw pointer would essentially be struct raw(T) { T it; alias it this;
void 
 opAssign(T rhs) { barrier(); it = rhs; } }
 
 * possible optimizations would be eliding the barrier in cases like `a = a[1
.. 
 $]` because you know - thanks to the bounds check - that this refers to the
same 
 memory block anyway and is thus irrelevant to the GC wrt marking. I guess it
can 
 be trouble if it wants to move tings in the middle of the slice operation
though.
 
 
 I'm not convinced this is impossible.


It's not impossible. It's more like what is the cost/benefit.



 (btw im also not convinced it is necessary, i think D's gc is good enough as
it 
 is.)


So do I. Isn't it ironic that people complain about D because it has a GC, and 
complain about D because the GC does not slow down non-GC code? I'm terrible at 
marketing.
Oct 29 2022
next sibling parent reply IGotD- <nise nise.com> writes:
On Saturday, 29 October 2022 at 19:55:31 UTC, Walter Bright wrote:

 Consider:

      strcpy(char* p, const(char)* q)

 Now consider managed:

      strcpy(char* p, const(char)* q)
      strcpy(char* p, managed(const(char)*) q)
      strcpy(managed(char*) p, const(char)* q)
      strcpy(managed(char*) p, managed(const(char)*) q)

 It's quite different.


You are aware that you can always obtain a raw pointer from 
managed pointer right? Which be useful for FFI functions.
Oct 29 2022
parent reply Walter Bright <newshound2 digitalmars.com> writes:
On 10/29/2022 1:26 PM, IGotD- wrote:

 You are aware that you can always obtain a raw pointer from managed pointer 
 right? Which be useful for FFI functions.


Yes, and you can also always obtain a far pointer from a near one. But there's 
always a cost, otherwise there'd be no point to having near pointers.

If C++/CLI nailed it, why has C++ in general not adopted it? Why has nobody 
create a C compiler, but with GC? What is the point of Rust if GC is the answer?
Oct 29 2022
parent reply 12345swordy <alexanderheistermann gmail.com> writes:
On Sunday, 30 October 2022 at 02:02:33 UTC, Walter Bright wrote:

 On 10/29/2022 1:26 PM, IGotD- wrote:

 You are aware that you can always obtain a raw pointer from 
 managed pointer right? Which be useful for FFI functions.


 Yes, and you can also always obtain a far pointer from a near 
 one. But there's always a cost, otherwise there'd be no point 
 to having near pointers.

 If C++/CLI nailed it, why has C++ in general not adopted it? 
 Why has nobody create a C compiler, but with GC? What is the 
 point of Rust if GC is the answer?


C++/CLI is used manually to create a gateway to the .net 
framework from c++ and back. That and the fact the implementation 
is windows only so that greatly hinders the adoption of the 
language.

- Alex
Oct 29 2022
parent reply Walter Bright <newshound2 digitalmars.com> writes:
On 10/29/2022 7:14 PM, 12345swordy wrote:

 C++/CLI is used manually to create a gateway to the .net framework from c++
and 
 back. That and the fact the implementation is windows only so that greatly 
 hinders the adoption of the language.


I do understand that. But if it was a winner, why have none of the other C++ 
compilers adopted it? Why isn't in the C++ Standard? Why isn't it in the C
Standard?
Oct 29 2022
next sibling parent reply Paulo Pinto <pjmlp progtools.org> writes:
On Sunday, 30 October 2022 at 05:55:44 UTC, Walter Bright wrote:

 On 10/29/2022 7:14 PM, 12345swordy wrote:

 C++/CLI is used manually to create a gateway to the .net 
 framework from c++ and back. That and the fact the 
 implementation is windows only so that greatly hinders the 
 adoption of the language.


 I do understand that. But if it was a winner, why have none of 
 the other C++ compilers adopted it? Why isn't in the C++ 
 Standard? Why isn't it in the C Standard?


It is a standard,

https://www.ecma-international.org/publications-and-standards/standards/ecma-372/

As for why it isn't in ISO C++, for the same reason most GCC and 
clang extensions aren't in ISO.

No one has bothered to endure the work and the voting process to 
make it part of ISO, including Microsoft that published it via 
ECMA.

As for why no other has adopted it, it really only makes sense 
for bytecode based stacks, and there is no competition to CLR for 
low-level languages.

WebAssembly is the one that came closest, and they still don't 
have a GC story to talk about.
Oct 29 2022
parent reply Walter Bright <newshound2 digitalmars.com> writes:
On 10/29/2022 11:41 PM, Paulo Pinto wrote:

 No one has bothered to endure the work and the voting process to make it part
of 
 ISO, including Microsoft that published it via ECMA.
 
 As for why no other has adopted it, it really only makes sense for bytecode 
 based stacks, and there is no competition to CLR for low-level languages.


Not a good sign for D needing to adopt managed pointers.
Oct 30 2022
next sibling parent reply Ola Fosheim =?UTF-8?B?R3LDuHN0YWQ=?= <ola.fosheim.grostad gmail.com> writes:
On Sunday, 30 October 2022 at 07:16:27 UTC, Walter Bright wrote:

 On 10/29/2022 11:41 PM, Paulo Pinto wrote:

 No one has bothered to endure the work and the voting process 
 to make it part of ISO, including Microsoft that published it 
 via ECMA.
 
 As for why no other has adopted it, it really only makes sense 
 for bytecode based stacks, and there is no competition to CLR 
 for low-level languages.


 Not a good sign for D needing to adopt managed pointers.


There is no demand for having a GC in c++ either. The GC support 
in std is being removed in C++23, and very few projects use the 
boehm collector (which is very close to the D one).

Cabon will also not have a GC (maybe ref count optimizations). 
Likewise Rust.

So there is no indication that there is a significant demand for 
GC among system level programmers/corporations that depend on 
system level code bases. Not even as an option.

And even the Microsoft example is basically about interop, not 
system level programming.

But you are right that it is attractive for anything that happens 
at compile time. However, if you want GC to be attractive at 
runtime then you need a new strategy at the language design level 
where threads dont have a negative impact on each other. Even 
then it will be an uphill battle as will need to create a demand 
for it (you would need to change existing practice).

(Swift and Go are usually not considered system level.)
Oct 30 2022
next sibling parent reply Paulo Pinto <pjmlp progtools.org> writes:
On Sunday, 30 October 2022 at 07:52:09 UTC, Ola Fosheim Grøstad 
wrote:

 On Sunday, 30 October 2022 at 07:16:27 UTC, Walter Bright wrote:

 On 10/29/2022 11:41 PM, Paulo Pinto wrote:

 No one has bothered to endure the work and the voting process 
 to make it part of ISO, including Microsoft that published it 
 via ECMA.
 
 As for why no other has adopted it, it really only makes 
 sense for bytecode based stacks, and there is no competition 
 to CLR for low-level languages.


 Not a good sign for D needing to adopt managed pointers.


 There is no demand for having a GC in c++ either. The GC 
 support in std is being removed in C++23, and very few projects 
 use the boehm collector (which is very close to the D one).


If you bothered to read the rational, the main reason are the 
companies that care about GC in C++, like Epic and Microsoft, 
didn't adopt the C++11  API.

Every, single AAA game studio using Unreal has demand for having 
GC in C++, just like every Windows application written in WPF.

So it is a pity that it is gone, but if the companies that care 
about don't want it, better clean up the standard.

Yet another good example how stuff gets into the standard, by 
having enough votes, but not from the companies that actually 
care about the feature in production code.


 Cabon will also not have a GC (maybe ref count optimizations).


It remains to be seen if Carbon will ever happen


 Likewise Rust.

 So there is no indication that there is a significant demand 
 for GC among system level programmers/corporations that depend 
 on system level code bases. Not even as an option.

 And even the Microsoft example is basically about interop, not 
 system level programming.

 But you are right that it is attractive for anything that 
 happens at compile time. However, if you want GC to be 
 attractive at runtime then you need a new strategy at the 
 language design level where threads dont have a negative impact 
 on each other. Even then it will be an uphill battle as will 
 need to create a demand for it (you would need to change 
 existing practice).


Most of that demand comes from cargo cult against any kind of 
automatic memory management.

In some embedded circles, progress has stopped in C89, should we 
also measure computing world lack of progress by those folks?


 (Swift and Go are usually not considered system level.)


Swift is definitly a system level, Apple is quite clear about it 
on documentation and WWDC keynotes, and on iOS 16 it already 
surpaced C++ usage.

It is one of the reasons why Apple has stop caring about C++ 
beyond C++17, and stepped away from clang contributions, focusing 
on LLVM infrastructure.

Also the main system programming language on Apple systems is 
Objective-C, with reference counting, and officially deprecated 
as of WWDC 2022 during the state of platforms keynote.
Oct 30 2022
parent reply Ola Fosheim =?UTF-8?B?R3LDuHN0YWQ=?= <ola.fosheim.grostad gmail.com> writes:
On Sunday, 30 October 2022 at 08:17:56 UTC, Paulo Pinto wrote:

 If you bothered to read the rational, the main reason are the 
 companies that care about GC in C++, like Epic and Microsoft, 
 didn't adopt the C++11  API.


That is not countering what I wrote: nobody uses it, there is no 
demand for a C++ GC.


 Every, single AAA game studio using Unreal has demand for 
 having GC in C++,


On the application level, not on the language level. This is no 
different from browsers providing a GC.

Most projects that can use a GC use a regular high level language 
with C interop.

btw, going all system level is generally too expensive unless 
your program is going to run on many machines. People make these 
calculations all the time. If you only run you application on one 
machine it is almost always cheaper to buy beefier hardware and 
write most of the code in a high level format. Even if that means 
Python + C module. That does not make Python system level.


 Most of that demand comes from cargo cult against any kind of 
 automatic memory management.


So the market is wrong? Or maybe they just do the most rational 
thing, use a high level language with C interop.


 (Swift and Go are usually not considered system level.)


 Swift is definitly a system level, Apple is quite clear about 
 it on documentation and WWDC keynotes, and on iOS 16 it already 
 surpaced C++ usage.

 It is one of the reasons why Apple has stop caring about C++ 
 beyond C++17, and stepped away from clang contributions, 
 focusing on LLVM infrastructure.

 Also the main system programming language on Apple systems is 
 Objective-C, with reference counting, and officially deprecated 
 as of WWDC 2022 during the state of platforms keynote.


I dont really care what Apple says on their marketing events. I 
cannot use Swift to write a competitive runtime. It isnt system 
level at this point.

But yeah, iphone is taking the beefier hardware approach. The 
price tag on an entry level phone is insane. A very powerful 
display of marketing and the psychological aspect of markets.
Oct 30 2022
parent Paulo Pinto <pjmlp progtools.org> writes:
On Sunday, 30 October 2022 at 08:56:29 UTC, Ola Fosheim Grøstad 
wrote:

 On Sunday, 30 October 2022 at 08:17:56 UTC, Paulo Pinto wrote:

 If you bothered to read the rational, the main reason are the 
 companies that care about GC in C++, like Epic and Microsoft, 
 didn't adopt the C++11  API.


 That is not countering what I wrote: nobody uses it, there is 
 no demand for a C++ GC.
 ...


Yeah, Unreal C++, C++/CLI, C++/CX don't exist, ergo nobody uses a 
C++ GC.
Oct 30 2022
prev sibling parent reply IGotD- <nise nise.com> writes:
On Sunday, 30 October 2022 at 07:52:09 UTC, Ola Fosheim Grøstad 
wrote:

 (Swift and Go are usually not considered system level.)


Swift is an interesting example of a possible system level 
language, but you have to trip lightly in order not to get heap 
allocations under the hood. Structs (which are value types) can 
end up on the heap when you use protocols together with structs. 
If you start to copy these heap allocated structs, you will 
quickly start to do heap allocations under the hood.

This video gives a little explanation about.
https://developer.apple.com/videos/play/wwdc2016/416/

If pay attention you should be able to avoid these.

With multithreaded system services, Swift seems to be a very good 
alternative. Atomic reference counting is here very suitable. 
Also lately there have been a lot of work on the concurrent model 
for Swift and it supports async/await, concurrent actors.

For the most low level programming Swift isn't an alternative but 
for system services inside an existing OS there should Swift do 
fine. Also, Swift seems to be a good fit for game programming as 
well.
Oct 30 2022
parent reply Ola Fosheim =?UTF-8?B?R3LDuHN0YWQ=?= <ola.fosheim.grostad gmail.com> writes:
On Sunday, 30 October 2022 at 11:04:42 UTC, IGotD- wrote:

 With multithreaded system services, Swift seems to be a very 
 good alternative. Atomic reference counting is here very 
 suitable. Also lately there have been a lot of work on the 
 concurrent model for Swift and it supports async/await, 
 concurrent actors.

 For the most low level programming Swift isn't an alternative 
 but for system services inside an existing OS there should 
 Swift do fine. Also, Swift seems to be a good fit for game 
 programming as well.


Right, Apple is putting a lot of effort into creating an 
environment that makes it attractive to make iOS-only apps (or 
iOS-first-apps). Making more iOS/macOS software use only Swift is 
obviously something that fits their strategies and we can expect 
more of that. They also have an obvious long term interest in 
growing the pool of loyal Swift-only programmers. (Just like 
Microsoft has an interest in making sure that there is a large 


There has been talks by the original author about making Swift a 
proper system level language (that could compete with C) some 
years ago, but not sure if that is still a goal. I don't expect 
it anytime soon, though.
Oct 30 2022
parent reply Imperatorn <johan_forsberg_86 hotmail.com> writes:
On Sunday, 30 October 2022 at 12:04:38 UTC, Ola Fosheim Grøstad 
wrote:

 On Sunday, 30 October 2022 at 11:04:42 UTC, IGotD- wrote:

 [...]


 Right, Apple is putting a lot of effort into creating an 
 environment that makes it attractive to make iOS-only apps (or 
 iOS-first-apps). Making more iOS/macOS software use only Swift 
 is obviously something that fits their strategies and we can 
 expect more of that. They also have an obvious long term 
 interest in growing the pool of loyal Swift-only programmers. 
 (Just like Microsoft has an interest in making sure that there 


 There has been talks by the original author about making Swift 
 a proper system level language (that could compete with C) some 
 years ago, but not sure if that is still a goal. I don't expect 
 it anytime soon, though.


I still think D as a language is superior. But a lot of the 
tooling around it needs some work.

But imo it's worth fixing that because D could soon be popular 
again.
Oct 30 2022
parent Ola Fosheim =?UTF-8?B?R3LDuHN0YWQ=?= <ola.fosheim.grostad gmail.com> writes:
On Sunday, 30 October 2022 at 13:33:21 UTC, Imperatorn wrote:

 I still think D as a language is superior. But a lot of the 
 tooling around it needs some work.

 But imo it's worth fixing that because D could soon be popular 
 again.


I haven't written a lot of Swift code, but I am not enthusiastic 
about some of the stuff Apple have let it inherit from 
Objective-C.

D also has baggage (e.g.  keywords) , so if by "fixing" you mean 
streamlining then I would be hopeful. If there is no streamlining 
involved then I would expect other languages willing to 
streamline and clean up to trend.

I don't really think "it is just historical baggage" and "not 
willing to break" will work out well in the long run, for any 
language. This applies to any language that has not reached 
critical mass, not only D.
Oct 30 2022
prev sibling parent reply Paulo Pinto <pjmlp progtools.org> writes:
On Sunday, 30 October 2022 at 07:16:27 UTC, Walter Bright wrote:

 On 10/29/2022 11:41 PM, Paulo Pinto wrote:

 No one has bothered to endure the work and the voting process 
 to make it part of ISO, including Microsoft that published it 
 via ECMA.
 
 As for why no other has adopted it, it really only makes sense 
 for bytecode based stacks, and there is no competition to CLR 
 for low-level languages.


 Not a good sign for D needing to adopt managed pointers.


Yeah, but those managed pointers are taken advantage in 
commercial products like Meadow boards,

https://www.wildernesslabs.co/


features.

Also the fact that Native AOT is now part of the picture, instead 
of the NGEN, .NET Native and Mono AOT special cases, makes it 
even better.

Unity is also taking avantage of those managed pointers while 
they migrate to .NET Core away from Mono, and in the process 



came from two main camps, former Midori developers and Unity 
folks.

Two domains that D with its pure approach to pointers has lost, 
embedded development and game engines scripting.

Swift and Objective-C, the system programing languages of Apple 
also have multiple pointer types.
Oct 30 2022
parent reply Walter Bright <newshound2 digitalmars.com> writes:
On 10/30/2022 1:29 AM, Paulo Pinto wrote:

 Swift and Objective-C, the system programing languages of Apple also have 
 multiple pointer types.


Do you have a reference? I did some googling, and didn't come up with anything.
Oct 30 2022
next sibling parent reply Imperatorn <johan_forsberg_86 hotmail.com> writes:
On Sunday, 30 October 2022 at 18:42:58 UTC, Walter Bright wrote:

 On 10/30/2022 1:29 AM, Paulo Pinto wrote:

 Swift and Objective-C, the system programing languages of 
 Apple also have multiple pointer types.


 Do you have a reference? I did some googling, and didn't come 
 up with anything.


https://mobikul.com/pointers-in-swift/
Oct 30 2022
parent Walter Bright <newshound2 digitalmars.com> writes:
On 10/30/2022 11:51 AM, Imperatorn wrote:

 On Sunday, 30 October 2022 at 18:42:58 UTC, Walter Bright wrote:

 On 10/30/2022 1:29 AM, Paulo Pinto wrote:

 Swift and Objective-C, the system programing languages of Apple also have 
 multiple pointer types.


 Do you have a reference? I did some googling, and didn't come up with anything.


 
 https://mobikul.com/pointers-in-swift/


Interesting. I didn't know that.
Oct 30 2022
prev sibling parent reply Paulo Pinto <pjmlp progtools.org> writes:
On Sunday, 30 October 2022 at 18:42:58 UTC, Walter Bright wrote:

 On 10/30/2022 1:29 AM, Paulo Pinto wrote:

 Swift and Objective-C, the system programing languages of 
 Apple also have multiple pointer types.


 Do you have a reference? I did some googling, and didn't come 
 up with anything.


You can read the documentation over here,

https://clang.llvm.org/docs/AutomaticReferenceCounting.html

https://developer.apple.com/library/archive/releasenotes/ObjectiveC/RN-TransitioningToARC/Introduction/Introduction.html#//apple_ref/doc/uid/TP40011226

https://docs.swift.org/swift-book/LanguageGuide/AutomaticReferenceCounting.html

And if there is some legacy Objective-C 2.0 GC code lying around, 
there is

https://developer.apple.com/library/archive/documentation/Cocoa/Conceptual/GarbageCollection/Introduction.html#//apple_ref/doc/uid/TP40002431

Basically the attribute qualifiers for pointers and class 
properties, specially in Objective-C case, and the Swift 
Objective-C interop, influence the semantics and type semantics 
of what ARC does with the pointers and their compatibility with 
raw pointers that aren't managed by ARC.

And the now dead tracing GC experiement, also had its own flavour 
of GC managed pointers alongside raw ones.
Oct 30 2022
next sibling parent reply IGotD- <nise nise.com> writes:
On Sunday, 30 October 2022 at 19:26:56 UTC, Paulo Pinto wrote:

 You can read the documentation over here,

 https://clang.llvm.org/docs/AutomaticReferenceCounting.html

 https://developer.apple.com/library/archive/releasenotes/ObjectiveC/RN-TransitioningToARC/Introduction/Introduction.html#//apple_ref/doc/uid/TP40011226

 https://docs.swift.org/swift-book/LanguageGuide/AutomaticReferenceCounting.html

 And if there is some legacy Objective-C 2.0 GC code lying 
 around, there is

 https://developer.apple.com/library/archive/documentation/Cocoa/Conceptual/GarbageCollection/Introduction.html#//apple_ref/doc/uid/TP40002431

 Basically the attribute qualifiers for pointers and class 
 properties, specially in Objective-C case, and the Swift 
 Objective-C interop, influence the semantics and type semantics 
 of what ARC does with the pointers and their compatibility with 
 raw pointers that aren't managed by ARC.

 And the now dead tracing GC experiement, also had its own 
 flavour of GC managed pointers alongside raw ones.


Just for completeness, the Swift developers are currently 
experimenting with an ownership model. Because this overlaps a 
little bit what is happening with D, I provide you a link.

https://github.com/apple/swift/blob/main/docs/OwnershipManifesto.md

This would mean that Swift would be more Rust like and this also 
includes runtime no aliasing checks. If this will make into 
version 7 remains to be seen.
Oct 30 2022
parent reply Walter Bright <newshound2 digitalmars.com> writes:
On 10/30/2022 1:14 PM, IGotD- wrote:

 Just for completeness, the Swift developers are currently experimenting with
an 
 ownership model. Because this overlaps a little bit what is happening with D,
I 
 provide you a link.
 
 https://github.com/apple/swift/blob/main/docs/OwnershipManifesto.md
 
 This would mean that Swift would be more Rust like and this also includes 
 runtime no aliasing checks. If this will make into version 7 remains to be
seen.



"If a storage reference expression evaluates to a storage reference that is 
implemented by a variable, then the formal access duration of that access may 
not overlap the formal access duration of any other access to the same variable 
unless both accesses are reads."

That's exactly like ownership/borrowing. D does it in  live functions.
Oct 30 2022
parent reply Templated Person <temp no-mail.com> writes:
On Sunday, 30 October 2022 at 22:36:15 UTC, Walter Bright wrote:

 That's exactly like ownership/borrowing. D does it in  live 
 functions.


I don't understand why is it not a goal to replace the GC with 
Swift / Nim-like reference counting. Stuff like ` live` already 
is in the works and can be used to optimize some reference count 
operations away.

Did you already consider and rejected this approach?

You may also want to read this document: ["Memory Management in 
Lobster"](https://aardappel.github.io/lobster/memory_management.html). See the
"Ownership Analysis" header specifically.

I think this approach can finally rid us of endless GC 
bikeshedding, plus most people would be okay with reference 
counting at kernel level. Only thing to worry about is reference 
cycles, Nim solves that using tracing and Swift solves that using 
weak pointers.
Oct 30 2022
next sibling parent rikki cattermole <rikki cattermole.co.nz> writes:
On 31/10/2022 12:38 PM, Templated Person wrote:

 On Sunday, 30 October 2022 at 22:36:15 UTC, Walter Bright wrote:

 That's exactly like ownership/borrowing. D does it in  live functions.


 
 I don't understand why is it not a goal to replace the GC with Swift / 
 Nim-like reference counting. Stuff like ` live` already is in the works 
 and can be used to optimize some reference count operations away.


Indeed a borrow checker could be used to elide calls to reference 
counting when you borrow the memory.

If only it wasn't opt-in on a function, and instead was guaranteed based 
upon the fact that it was borrowed...

Of course eliding can also occur if we have proper reference counting 
primitives for structs/classes. LLVM has directives for this to allow 
eliding regardless of what the frontend does.

It would also solve the const/immutable problem for reference counting 
types :)
Oct 30 2022
prev sibling parent Walter Bright <newshound2 digitalmars.com> writes:
On 10/30/2022 4:38 PM, Templated Person wrote:

 I don't understand why is it not a goal to replace the GC with Swift /
Nim-like 
 reference counting.


We've looked at RC so many times. It has problems with:

1. transitive const

2. needs an exception handler to decrement the count

3. some memory leak problems that need (ironically) an ownership/borrowing 
system to fix
Oct 30 2022
prev sibling parent reply Walter Bright <newshound2 digitalmars.com> writes:
On 10/30/2022 12:26 PM, Paulo Pinto wrote:


 You can read the documentation over here,
 
 https://clang.llvm.org/docs/AutomaticReferenceCounting.html
 
 https://developer.apple.com/library/archive/releasenotes/ObjectiveC/RN-TransitioningToARC/Introduction/Introduction.html#//apple_ref/doc/uid/TP40011226
 
 https://docs.swift.org/swift-book/LanguageGuide/AutomaticReferenceCounting.html


I didn't realize you classified ARC as a separate pointer type. You can't do 
pointy things with it like pointer arithmetic, or taking the address of a 
variable with it. It's sort of like an associative array in D is a special
type, 
but not what I'd consider a pointer type. Even class references in D are not 
really a special pointer type.

But thank you for the references.


 And if there is some legacy Objective-C 2.0 GC code lying around, there is
 
 https://developer.apple.com/library/archive/documentation/Cocoa/Conceptual/GarbageCollection/Introduction.html#//apple_ref/doc/uid/TP40002431
 
 Basically the attribute qualifiers for pointers and class properties,
specially 
 in Objective-C case, and the Swift Objective-C interop, influence the
semantics 
 and type semantics of what ARC does with the pointers and their compatibility 
 with raw pointers that aren't managed by ARC.
 
 And the now dead tracing GC experiement, also had its own flavour of GC
managed 
 pointers alongside raw ones.


Does that mean it had managed pointers, and abandoned them?
Oct 30 2022
next sibling parent Paulo Pinto <pjmlp progtools.org> writes:
On Sunday, 30 October 2022 at 22:21:12 UTC, Walter Bright wrote:

 On 10/30/2022 12:26 PM, Paulo Pinto wrote:


 You can read the documentation over here,
 
 https://clang.llvm.org/docs/AutomaticReferenceCounting.html
 
 https://developer.apple.com/library/archive/releasenotes/ObjectiveC/RN-TransitioningToARC/Introduction/Introduction.html#//apple_ref/doc/uid/TP40011226
 
 https://docs.swift.org/swift-book/LanguageGuide/AutomaticReferenceCounting.html


 I didn't realize you classified ARC as a separate pointer type. 
 You can't do pointy things with it like pointer arithmetic, or 
 taking the address of a variable with it. It's sort of like an 
 associative array in D is a special type, but not what I'd 
 consider a pointer type. Even class references in D are not 
 really a special pointer type.
 ..


It is the same difference as GC pointers and untraced pointers in 
most languages with GC and low level systems programming 
capabilities.

You tag the pointer types with __autoreleasing, __strong, 
__unsafe_unretained, __weak.

And if you want to feel lucky instead of having safe code, you 
can also do pointer arithmetic with them, thankfully Swift only 
allows this in the unsafe variants.

See "Conversion of pointers to ownership-qualified types".
Oct 31 2022
prev sibling parent Paulo Pinto <pjmlp progtools.org> writes:
On Sunday, 30 October 2022 at 22:21:12 UTC, Walter Bright wrote:

 On 10/30/2022 12:26 PM, Paulo Pinto wrote:


 You can read the documentation over here,
 
 https://clang.llvm.org/docs/AutomaticReferenceCounting.html
 
 https://developer.apple.com/library/archive/releasenotes/ObjectiveC/RN-TransitioningToARC/Introduction/Introduction.html#//apple_ref/doc/uid/TP40011226
 
 https://docs.swift.org/swift-book/LanguageGuide/AutomaticReferenceCounting.html


 I didn't realize you classified ARC as a separate pointer type. 
 You can't do pointy things with it like pointer arithmetic, or 
 taking the address of a variable with it. It's sort of like an 
 associative array in D is a special type, but not what I'd 
 consider a pointer type. Even class references in D are not 
 really a special pointer type.
 ..


It is the same difference as GC pointers and untraced pointers in 
most languages with GC and low level systems programming 
capabilities.

You tag the pointer types with __autoreleasing, __strong, 
__unsafe_unretained, __weak.

And if you want to feel lucky instead of having safe code, you 
can also do pointer arithmetic with them, thankfully Swift only 
allows this in the unsafe variants.

See "Conversion of pointers to ownership-qualified types".

Regarding the question to managed pointers in Objective-C 2.0, it 
used write-barriers with a conservative GC for pointers 
explicitly marked as __strong or __weak. In  class declarations 
the pointers are implicitly __strong if not marked otherwise.
Oct 31 2022
prev sibling parent reply linger <xiao linger.me> writes:
On Sunday, 30 October 2022 at 05:55:44 UTC, Walter Bright wrote:

 On 10/29/2022 7:14 PM, 12345swordy wrote:

 C++/CLI is used manually to create a gateway to the .net 
 framework from c++ and back. That and the fact the 
 implementation is windows only so that greatly hinders the 
 adoption of the language.


 I do understand that. But if it was a winner, why have none of 
 the other C++ compilers adopted it? Why isn't in the C++ 
 Standard? Why isn't it in the C Standard?



1. I believe D's GC is not a problem, D always say itself is `a 

systems programming language`, they target users who don't care 
about GC.

No one will write an OS or "application on RTOS" by a GC lang.

In my option D should pointing to application developers like 
GUI/Web Server.

for GUI D can easily use exist C legacy, for web server it can 
improve their speed, "faster java" or "improved go".

2. Other problem for D is tools.

I tried code-d, the debugger never work for me, no rename/find 
reference in LSP. Others language like Go/Rust their LSP and 
vscode plugins is official maintained, but for D code-d looks 
like "WebFreak001" personally work.
Oct 30 2022
parent Paulo Pinto <pjmlp progtools.org> writes:
On Monday, 31 October 2022 at 03:04:49 UTC, linger wrote:

 On Sunday, 30 October 2022 at 05:55:44 UTC, Walter Bright wrote:

 On 10/29/2022 7:14 PM, 12345swordy wrote:

 C++/CLI is used manually to create a gateway to the .net 
 framework from c++ and back. That and the fact the 
 implementation is windows only so that greatly hinders the 
 adoption of the language.


 I do understand that. But if it was a winner, why have none of 
 the other C++ compilers adopted it? Why isn't in the C++ 
 Standard? Why isn't it in the C Standard?



 1. I believe D's GC is not a problem, D always say itself is `a 

 systems programming language`, they target users who don't care 
 about GC.

 No one will write an OS or "application on RTOS" by a GC lang.
 ...


https://www.ptc.com/en/products/developer-tools/perc

https://www.aicas.com/wp/

https://www.astrobe.com/astrobe.htm

https://www.withsecure.com/en/solutions/innovative-security-hardware/usb-armory

https://www.wildernesslabs.co/

http://joeduffyblog.com/2015/11/03/blogging-about-midori/

https://www.wikiwand.com/en/Modula-2%2B

https://en.wikipedia.org/wiki/Oberon_(operating_system)

https://www.youtube.com/watch?v=z_dt7NG38V4

Just a small taste of OSes and RTOS products that were never 
written.
Oct 31 2022
prev sibling parent reply Adam D Ruppe <destructionator gmail.com> writes:
On Saturday, 29 October 2022 at 19:55:31 UTC, Walter Bright wrote:

      strcpy(char* p, const(char)* q)

 Now consider managed:


First, I proposed raw, not managed, let's be safe by default. 
Also remember what `alias this` does; an unprotected pointer (aka 
raw!(T*)) can implicitly cast to a protected pointer (aka T*). 
Third, think about what strcpy does. There's no need to change 
that signature at all - it is exactly the same as it is now, 
since it doesn't actually write to any pointers.

I'd assume managed by default - just like how arrays are bounds 
checked by default. If the programmer gets lazy, they get the 1% 
performance penalty but default protection. You have to opt out 
of the barrier with the `raw!T` (or the command line argument to 
turn it all off).

And since the barrier is only meaningful to pointer writes, it is 
completely useless with a const pointer because they are never 
written. So no need to draw a distinction there at all. Moreover, 
writing *through* a pointer is not the same as writing *to* the 
pointer. strcpy is writing to `char`s, not to `char*`, so even 
the same code is generated anyway. You don't have to barrier a 
`char`, the GC doesn't care if its value changes.

But even if it did write to the pointer, there'd be no need to 
change the signature, since the raw pointer implicitly converts 
to the managed pointer. And remember, the managed pointer only 
even generated different code if the *pointer itself* is actually 
written to, and moreover, we can even elide the checks if we know 
it is pointing to the same block, since the GC won't care about 
specifically where in the block it points, just that it points to 
the block. So even `a = a[1 .. $];` need not use a barrier. (I 
think.)

Arguably, all C functions should take raw pointers, but if the 
reference is borrowed, again it doesn't matter too much since you 
know there's another reference at the call site. So you might get 
away with ignoring that detail too. But still, the guiding 
principle is to be safe by default and allow people a chance to 
opt out with explicit action. Just like bounds checking in 
principle.
Oct 29 2022
parent reply Walter Bright <newshound2 digitalmars.com> writes:
On 10/29/2022 3:59 PM, Adam D Ruppe wrote:

 First, I proposed raw, not managed, let's be safe by default. Also remember
what 
 `alias this` does; an unprotected pointer (aka raw!(T*)) can implicitly cast
to 
 a protected pointer (aka T*). Third, think about what strcpy does. There's no 
 need to change that signature at all - it is exactly the same as it is now, 
 since it doesn't actually write to any pointers.


strcpy writes through its first parameter


 I'd assume managed by default - just like how arrays are bounds checked by 
 default. If the programmer gets lazy, they get the 1% performance penalty but 
 default protection. You have to opt out of the barrier with the `raw!T` (or
the 
 command line argument to turn it all off).
 
 And since the barrier is only meaningful to pointer writes, it is completely 
 useless with a const pointer because they are never written. So no need to
draw 
 a distinction there at all. Moreover, writing *through* a pointer is not the 
 same as writing *to* the pointer. strcpy is writing to `char`s, not to
`char*`, 
 so even the same code is generated anyway. You don't have to barrier a `char`, 
 the GC doesn't care if its value changes.
 
 But even if it did write to the pointer, there'd be no need to change the 
 signature, since the raw pointer implicitly converts to the managed pointer.
And 
 remember, the managed pointer only even generated different code if the
*pointer 
 itself* is actually written to,


No, if what it points to is written, because that's what makes the target page 
"dirty".


 and moreover, we can even elide the checks if we 
 know it is pointing to the same block, since the GC won't care about 
 specifically where in the block it points, just that it points to the block.
So 
 even `a = a[1 .. $];` need not use a barrier. (I think.)
 
 Arguably, all C functions should take raw pointers, but if the reference is 
 borrowed, again it doesn't matter too much since you know there's another 
 reference at the call site. So you might get away with ignoring that detail
too. 
 But still, the guiding principle is to be safe by default and allow people a 
 chance to opt out with explicit action. Just like bounds checking in principle.


In DOS programming, near pointer could always be converted to far. So why
didn't 
everyone just use far APIs? A lot did. But it turns out, you could get a lot 
more performance by mixing near and far, at the cost of ugly code and a lot of 
careful work.

I was glad to leave all that behind.

Besides, if it was so easy to do, why has nobody produced a C compiler that
uses 
a GC instead of malloc/free?

Microsoft implemented a raw/managed pointer type in C++/CLI, and it has set 
nobody on fire. It appears to be a dead end.
Oct 29 2022
parent reply Adam D Ruppe <destructionator gmail.com> writes:
On Sunday, 30 October 2022 at 02:15:06 UTC, Walter Bright wrote:

 Besides, if it was so easy to do, why has nobody produced a C 
 compiler that uses a GC instead of malloc/free?


Well, it has been done with Bohem.

But anyway I wrote up my sketch design in my blog:
http://dpldocs.info/this-week-in-d/Blog.Posted_2022_10_31.html


It is more like bounds checking than a new type. Sure, I do 
propose a new type, but just to locally bypass the thing, not as 
something mandatory. With a compiler switch, you can turn it on 
or off to experiment with different strategies.
Oct 31 2022
parent Walter Bright <newshound2 digitalmars.com> writes:
On 10/31/2022 9:46 AM, Adam D Ruppe wrote:

 On Sunday, 30 October 2022 at 02:15:06 UTC, Walter Bright wrote:

 Besides, if it was so easy to do, why has nobody produced a C compiler that 
 uses a GC instead of malloc/free?


 
 Well, it has been done with Bohem.


D's GC is very similar to the Boehm one, but more accurate since the D compiler 
provides layout info to the GC.



 But anyway I wrote up my sketch design in my blog:
 http://dpldocs.info/this-week-in-d/Blog.Posted_2022_10_31.html
 It is more like bounds checking than a new type. Sure, I do propose a new
type, 
 but just to locally bypass the thing, not as something mandatory. With a 
 compiler switch, you can turn it on or off to experiment with different
strategies.


Thanks for doing that. Now, if someone wants to implement it ...
Nov 01 2022
prev sibling parent reply bachmeier <no spam.net> writes:
On Saturday, 29 October 2022 at 10:04:01 UTC, IGotD- wrote:

 On Saturday, 29 October 2022 at 09:42:32 UTC, Walter Bright 
 wrote:

 It's literally impossible for me to stop anyone who wants to 
 improve the GC. It's all open source, and Boost licensed. It's 
 even designed to be pluggable.


 No they can't because D doesn't have a built in managed pointer 
 type and they are limited to a subset of GC algorithms (even 
 limited among the tracing GC ones).

 It is possible to use a library custom GC type but then 
 runtime/phobos don't use these so replacing the GC in the 
 entire program isn't possible.

 Many have tried to explain this numerous times but you just 
 ignore this obvious fact.


If you're changing the compiler to add a different GC strategy, 
you can add managed pointers.
Oct 29 2022
parent reply Ola Fosheim =?UTF-8?B?R3LDuHN0YWQ=?= <ola.fosheim.grostad gmail.com> writes:
On Saturday, 29 October 2022 at 14:43:54 UTC, bachmeier wrote:

 If you're changing the compiler to add a different GC strategy, 
 you can add managed pointers.


I think you need more than this to do it well, in terms of system 
level programming.

You need to minimize thread-to-thread interference. You need to 
strengthen the type system and make better use of `shared`.
Oct 29 2022
parent reply bachmeier <no spam.net> writes:
On Saturday, 29 October 2022 at 15:45:11 UTC, Ola Fosheim Grøstad 
wrote:

 On Saturday, 29 October 2022 at 14:43:54 UTC, bachmeier wrote:

 If you're changing the compiler to add a different GC 
 strategy, you can add managed pointers.


 I think you need more than this to do it well, in terms of 
 system level programming.

 You need to minimize thread-to-thread interference. You need to 
 strengthen the type system and make better use of `shared`. 




I was replying to someone claiming they couldn't write a new GC 
because they need managed pointers. I'm not going to take a 
position on whether that is sufficient, but if they have a fork, 
they can add them to the language and show the benefits.
Nov 01 2022
parent reply Don Allen <donaldcallen gmail.com> writes:
On Tuesday, 1 November 2022 at 16:52:34 UTC, bachmeier wrote:

 On Saturday, 29 October 2022 at 15:45:11 UTC, Ola Fosheim 
 Grøstad wrote:

 On Saturday, 29 October 2022 at 14:43:54 UTC, bachmeier wrote:

 If you're changing the compiler to add a different GC 
 strategy, you can add managed pointers.


 I think you need more than this to do it well, in terms of 
 system level programming.

 You need to minimize thread-to-thread interference. You need 
 to strengthen the type system and make better use of `shared`. 




 I was replying to someone claiming they couldn't write a new GC 
 because they need managed pointers. I'm not going to take a 
 position on whether that is sufficient, but if they have a 
 fork, they can add them to the language and show the benefits.


Having gotten thoroughly sick of the general tone of too much of 
this forum, I've taken a many-day break from it.

But I looked in today and saw this thread. It confirmed my reason 
for taking the break, in spades.

I greatly admire what Theo de Raadt has achieved with OpenBSD, 
due to his own extraordinary technical talent and his ability to 
attract smart people who believe in his goals and approach. I do 
not admire de Raadt's nasty, condescending way of dealing with 
(mostly) innocent victims who post to misc openbsd.org. But I do 
agree completely with de Raadt's Law for dealing with people who 
say "OpenBSD should really do X", which is "Send us a diff", 
usually followed by some variant of "or get lost".

I think a number of people complaining about aspects of D, real 
and imagined, should be made familiar with de Raadt's Law. They 
also should be reminded that this is an open source project, 
available to all of us free of charge. You can't behave like an 
aggrieved paying customer in this circumstance. The project was 
started by Walter and he continues to be the leader and major 
contributor. D would not exist without him. We are his 
beneficiaries. Those who have complaints, and especially those 
who state them rudely but don't contribute code because they 
don't "have the spare time" or just want someone else to do the 
work they won't, should not be taken seriously. Unless, of 
course, they've come up with a bolt-from-the-blue insight, which 
seems to be an exceedingly rare occurrence. What this amounts to 
is that I think Walter is too nice a guy; a little de Raadt (very 
little!) would be a big help.

Another issue is marketing. Talent for that is rare in great 
engineers. Wozniak was the technical smarts behind Apple as a 
startup, but Jobs had the marketing flare. A historically great 
combination. Andrew Kelley seems to be one of those rare people 
with both engineering and marketing talent, though it remains to 
be seen (when V1.0 finally happens) whether he's really a great 
engineering talent. Linus Torvalds is another, who gets attention 
by being outrageous. Richard Stallman is still another. Eccentric 
as he is, he has a powerful mind and makes a strong, clear 
argument for sharing and community. And even de Raadt knows how 
to reign in his nastiness in public and just lets us see how 
charming and brilliant he can be.

Walter admits he's not a good marketer. Perhaps he's right, 
though I've seen a number of his talks and thought they were 
quite good and entertaining. Walter is a classic great engineer; 
I've known a number of them over the years in places like MIT and 
BBN. Look up Frank Heart, Ray Tomlinson, Bob Kahn, Gerald J. 
Sussman and Tom Knight. None of them care or cared about 
marketing. Some would have been good at it if they had, some not.

There are a number of reasons why programming languages become 
hugely popular or not, but having an attention-getting advocate 
is clearly a huge plus. Walter's talents lie in engineering good 
compilers and in evolutionary language design. He's not Steve 
Jobs, or even Andrew Kelley. But he has produced a really fine 
piece of work, a clear improvement over C, with which I have a 
lot of experience (ever tried to write code on an overloaded Vax 
780 running 4.3 BSD?), and I suspect, over C++, with which I have 
only a little experience, as well. Is it perfect? Of course not. 
Show me the perfect programming language. Whether it meets your 
expectations or not is your call. But I really think that this 
constant bitching about D, from people who are not putting their 
time where their mouth is, is beyond the pale.

And for the record, the D GC has simply not been a problem in my 
work with the language. And I would point out that the language 
makes it easy to avoid dynamic allocations where they would be 
undesirable (by using stack-allocated buffers, as occurs 
repeatedly in the C library, e.g., strncpy).
Nov 01 2022
next sibling parent reply Timon Gehr <timon.gehr gmx.ch> writes:
On 01.11.22 21:47, Don Allen wrote:

 don't contribute code because they don't


I have contributed code to DMD, I have contributed ideas and designs, 
(co-)wrote multiple accepted DIPs and even more drafts, and reported a 
lot of issues. I have contributed to other community projects as well, 
even when lacking the spare time. I have burned out as a result, more 
than once.

I have also gone through a painful experience where I was explicitly 
asked by D leadership to work on a specific project instead of what I 
had considered important and then this line of work was just dropped later.


 "have the spare time"


Not everyone is in Walter's position. I really don't understand why you 
are singling me out here and being disrespectful towards me. I made that 
remark in a post where I was explicitly appreciative of the huge amount 
of work Walter is putting into D, but I still somewhat envy his ability 
to work so much on what he wants to work on. Other people have to report 
to their higher-ups and peers. Higher-ups and peers who will criticize 
them for even using D, let alone contributing to the compiler. I hope 
you understand that nowadays there are many people in jobs where open 
source contributions are a no go by default, _even_ in their spare time. 
It's generally much harder now to build something on your own that will 
be successful and last due to the proliferation of large tech 
monopolies, overbearing intellectual property laws and a general loss of 
freedom.

Anyway, note that Walter has Ola in his kill file and so do I.
Nov 01 2022
next sibling parent reply Don Allen <donaldcallen gmail.com> writes:
On Tuesday, 1 November 2022 at 22:43:57 UTC, Timon Gehr wrote:

 On 01.11.22 21:47, Don Allen wrote:

 don't contribute code because they don't





 "have the spare time"


 Not everyone is in Walter's position. I really don't understand 
 why you are singling me out here and being disrespectful 
 towards me.


I was not and am not. It's a common phrase that I've seen in that 
past in these situations and that's what I was talking about. 
You'll note that something similar was said by someone else in 
this thread.

Also, I was not aware that you had said anything like that. I 
haven't read every message in this thread. I'm also aware of the 
fact that you've contributed to the project, so it wouldn't make 
much sense for me to point the finger at you, would it?

In any case, I'm sorry you were offended, but it was not 
intentional.
Nov 01 2022
parent Timon Gehr <timon.gehr gmx.ch> writes:
On 02.11.22 00:30, Don Allen wrote:

 
 In any case, I'm sorry you were offended, but it was not intentional.


No worries! No offense taken, was just a bit confusing.
Nov 01 2022
prev sibling next sibling parent zjh <fqbqrr 163.com> writes:
On Tuesday, 1 November 2022 at 22:43:57 UTC, Timon Gehr wrote:


 I have contributed code to DMD, I have contributed ideas and 
 designs, (co-)wrote multiple accepted DIPs and even more 
 drafts, and reported a lot of issues. I have contributed to 
 other community projects as well, even when lacking the spare 
 time. I have burned out as a result, more than once.

 I have also gone through a painful experience where I was 
 explicitly asked by D leadership to work on a specific project 
 instead of what I had considered important and then this line 
 of work was just dropped later.


Thank you for `your and D man`'s  efforts.
Nov 01 2022
prev sibling parent Dukc <ajieskola gmail.com> writes:
On Tuesday, 1 November 2022 at 22:43:57 UTC, Timon Gehr wrote:

 Not everyone is in Walter's position. I really don't understand 
 why you are singling me out here and being disrespectful 
 towards me.


Heat in this forum generally comes from two kinds of people. The 
first kind are those that are direct in their opinions, but work 
with the language and direct their criticism at real pain points 
and suggest, often even contribute, workable improvements. Those 
people are not the problem and in my books you belong to that 
first category. Manu Evans is another classic example of that 
kind of person.

The another kind of people, that are the real problem, are those 
who have an air of negativity about D and the language foundation 
in general. They turn many threads into those battles where most 
of us feel the need to defend D against overt criticism. Often - 
not always, but often - they have no or next to no record of 
contributing. I can't pinpoint exactly what the problem in their 
behaviour is, but somehow they almost never manage to be 
constructive. I can only suspect they have some subconscious 
desire to prove others misguided and themselves above the mass, 
or something like that.



 I hope you understand that nowadays there are many people in 
 jobs where open source contributions are a no go by default, 
 _even_ in their spare time.


<political rant> Forbidding that should be declared illegal in 
every country. I can maybe understand if, say someone developing 
car radio software, would be forbidden from contributing to 
open-source radio software, but to software in general? That's 
ridiculous!
</political rant>
Nov 02 2022
prev sibling next sibling parent Imperatorn <johan_forsberg_86 hotmail.com> writes:
On Tuesday, 1 November 2022 at 20:47:23 UTC, Don Allen wrote:

 On Tuesday, 1 November 2022 at 16:52:34 UTC, bachmeier wrote:

 [...]


 Having gotten thoroughly sick of the general tone of too much 
 of this forum, I've taken a many-day break from it.

 [...]


Well said
Nov 01 2022
prev sibling next sibling parent Patrick Schluter <Patrick.Schluter bbox.fr> writes:
On Tuesday, 1 November 2022 at 20:47:23 UTC, Don Allen wrote:

 On Tuesday, 1 November 2022 at 16:52:34 UTC, bachmeier wrote:

 [...]


 Having gotten thoroughly sick of the general tone of too much 
 of this forum, I've taken a many-day break from it.

 [...]


Thank you for this necessary message. These weekly D negativity 
threads start really to be annoying.
Nov 02 2022
prev sibling parent reply Guillaume Piolat <first.last spam.org> writes:
On Tuesday, 1 November 2022 at 20:47:23 UTC, Don Allen wrote:

 I think a number of people complaining about aspects of D, real 
 and imagined, should be made familiar with de Raadt's Law. They 
 also should be reminded that this is an open source project, 
 available to all of us free of charge. You can't behave like an 
 aggrieved paying customer in this circumstance. The project was 
 started by Walter and he continues to be the leader and major 
 contributor. D would not exist without him. We are his 
 beneficiaries. Those who have complaints, and especially those 
 who state them rudely but don't contribute code because they 
 don't "have the spare time" or just want someone else to do the 
 work they won't, should not be taken seriously.


+1
Just ban the offending trolls from using this forum.
We have endured 10 years of trolling, and the more D gets popular 
the worse it becomes.
This is limiting the size of this community.
Just use the ban hammer.
Threads like that, that end up on HN with a negative title, are a 
huge waste of core people's time. Nothing gets out of it.
Nov 02 2022
parent reply Imperatorn <johan_forsberg_86 hotmail.com> writes:
On Wednesday, 2 November 2022 at 15:53:30 UTC, Guillaume Piolat 
wrote:

 On Tuesday, 1 November 2022 at 20:47:23 UTC, Don Allen wrote:

 I think a number of people complaining about aspects of D, 
 real and imagined, should be made familiar with de Raadt's 
 Law. They also should be reminded that this is an open source 
 project, available to all of us free of charge. You can't 
 behave like an aggrieved paying customer in this circumstance. 
 The project was started by Walter and he continues to be the 
 leader and major contributor. D would not exist without him. 
 We are his beneficiaries. Those who have complaints, and 
 especially those who state them rudely but don't contribute 
 code because they don't "have the spare time" or just want 
 someone else to do the work they won't, should not be taken 
 seriously.


 +1
 Just ban the offending trolls from using this forum.
 We have endured 10 years of trolling, and the more D gets 
 popular the worse it becomes.
 This is limiting the size of this community.
 Just use the ban hammer.
 Threads like that, that end up on HN with a negative title, are 
 a huge waste of core people's time. Nothing gets out of it.


Well said. Sometimes it feels like some individuals want D to 
fail for some reason, I don't know why. I made this thread (at 
least tried) to point out that D is actually good, and you can 
use it, today.

Let's stop complaining and focus instead on making things better 
and keep improving D.

It doesn't need to be big to count, just anything. Update the 
wiki, fix a spelling error, make sure information is up to date. 
Everything is valuable. Also, please try look at what the 
leadership is trying to do, and not just what they haven't done. 
They deserve way more appreciation, it's many hours of work and 
doesn't happen by itself.
Nov 02 2022
parent reply "H. S. Teoh" <hsteoh qfbox.info> writes:
On Wed, Nov 02, 2022 at 05:37:59PM +0000, Imperatorn via Digitalmars-d wrote:
[...]

 Let's stop complaining and focus instead on making things better and
 keep improving D.
 
 It doesn't need to be big to count, just anything. Update the wiki,
 fix a spelling error, make sure information is up to date. Everything
 is valuable.


Side-story: when I first found D, I would run into problems and bugs,
and complained about them here in the forums.  Then I was told to file
them in bugzilla, so I did.  But things weren't going as fast as I'd
like them to, so I decided to take things into my own hands and started
submitting PRs. It doesn't actually take much to contribute to D; Phobos
especially is quite easy to read and understand (in contrast with many
programming language standard libraries -- e.g. I tried reading glibc
code once and almost got PTSD from it).  However, in those days the PR
queue was backed up, so that was slow going as well.  Then one day,
after complaining about the PR queue, Andrei suddenly granted me write
access to Phobos.  So I started reviewing PRs and pushing them through.
Since then, I've contributed to Phobos, druntime, dlang.org (the website
repo), and even a few dmd PRs.  I've also contributed to various other
3rd party D repos, primarily Adam's excellent arsd, and a couple of
other miscellaneous projects.  I'm just sad that these days I just don't
have the time/energy to contribute as frequently as I used to, but it's
still one of the most rewarding experiences I've had in the realm of
open source software.

So my word to other would-be contributors: just do it! Contributing to D
is not as hard as you might think. In fact, it's pretty easy, thanks to
D making your typically obtuse source code much easier to read.  A
random internet nobody like myself literally just walked into the room
out of the blue, contributed a couple of PRs, and was given the keys to
Phobos, so to speak.  It can happen to you too! ;-)



 Also, please try look at what the leadership is trying to do, and not
 just what they haven't done. They deserve way more appreciation, it's
 many hours of work and doesn't happen by itself.


And don't forget D was made (and still is being made) by volunteers,
other than Walter himself, and given to you for FREE.  The reasonable
response, IMO, is gratitude, at the very least. And contributing back
when you can.  Rather than making demands with harsh criticisms as if
Walter owed you something. (Spoiler: he does not.)


T

-- 
"A one-question geek test. If you get the joke, you're a geek: Seen on a
California license plate on a VW Beetle: 'FEATURE'..." -- Joshua D. Wachs -
Natural Intelligence, Inc.
Nov 02 2022
parent Imperatorn <johan_forsberg_86 hotmail.com> writes:
On Wednesday, 2 November 2022 at 18:12:39 UTC, H. S. Teoh wrote:

 [...]


Listen to this man ^
This is how it's done my friends.

❤️
Nov 02 2022
prev sibling parent reply Imperatorn <johan_forsberg_86 hotmail.com> writes:
On Saturday, 29 October 2022 at 09:42:32 UTC, Walter Bright wrote:

 On 10/29/2022 2:18 AM, Imperatorn wrote:

 For anyone reading this, if you want to be a hero and 
 remembered for all eternity, improve the D GC.


 It's literally impossible for me to stop anyone who wants to 
 improve the GC. It's all open source, and Boost licensed. It's 
 even designed to be pluggable.

 Make a better one, and we'll incorporate it.

 I'll be happy to be shown to be wrong about it.


I'm not saying you're wrong. It's more like a challenge 😎
Oct 29 2022
parent reply rikki cattermole <rikki cattermole.co.nz> writes:
On 29/10/2022 11:13 PM, Imperatorn wrote:

 It's more like a challenge 😎


It's dangerous to go alone! Take this.

https://www.amazon.com/Garbage-Collection-Handbook-Management-Algorithms/dp/1420082795

https://www.amazon.com/Art-Multiprocessor-Programming-Maurice-Herlihy/dp/0124159508
Oct 29 2022
parent reply Imperatorn <johan_forsberg_86 hotmail.com> writes:
On Saturday, 29 October 2022 at 10:17:28 UTC, rikki cattermole 
wrote:

 On 29/10/2022 11:13 PM, Imperatorn wrote:

 It's more like a challenge 😎


 It's dangerous to go alone! Take this.

 https://www.amazon.com/Garbage-Collection-Handbook-Management-Algorithms/dp/1420082795

 https://www.amazon.com/Art-Multiprocessor-Programming-Maurice-Herlihy/dp/0124159508


Thanks, I'll look into those
Oct 29 2022
parent reply matheus <matheus gmail.com> writes:
On Saturday, 29 October 2022 at 10:25:20 UTC, Imperatorn wrote:

 On Saturday, 29 October 2022 at 10:17:28 UTC, rikki cattermole 
 wrote:

 On 29/10/2022 11:13 PM, Imperatorn wrote:

 It's more like a challenge 😎


 It's dangerous to go alone! Take this.

 https://www.amazon.com/Garbage-Collection-Handbook-Management-Algorithms/dp/1420082795

 https://www.amazon.com/Art-Multiprocessor-Programming-Maurice-Herlihy/dp/0124159508


 Thanks, I'll look into those


https://libgen.rs

Matheus.
Oct 29 2022
parent Imperatorn <johan_forsberg_86 hotmail.com> writes:
On Saturday, 29 October 2022 at 11:10:20 UTC, matheus wrote:

 On Saturday, 29 October 2022 at 10:25:20 UTC, Imperatorn wrote:

 On Saturday, 29 October 2022 at 10:17:28 UTC, rikki cattermole 
 wrote:

 On 29/10/2022 11:13 PM, Imperatorn wrote:

 It's more like a challenge 😎


 It's dangerous to go alone! Take this.

 https://www.amazon.com/Garbage-Collection-Handbook-Management-Algorithms/dp/1420082795

 https://www.amazon.com/Art-Multiprocessor-Programming-Maurice-Herlihy/dp/0124159508


 Thanks, I'll look into those


 https://libgen.rs

 Matheus.


❤️
Oct 29 2022
prev sibling next sibling parent reply Walter Bright <newshound2 digitalmars.com> writes:
Oct 29 2022
parent =?UTF-8?Q?Ali_=c3=87ehreli?= <acehreli yahoo.com> writes:
On 10/29/22 02:16, Walter Bright wrote:




Apologies for posting a direct link but it's number 73 at this time anyway:

   https://news.ycombinator.com/item?id=33381285

Ali
Oct 29 2022
prev sibling parent reply Guillaume Piolat <first.last spam.org> writes:
On Saturday, 29 October 2022 at 04:46:21 UTC, Walter Bright wrote:

 2. Choice is nice. For example, I prefer to use the GC for 
 initialization work, and the inner loop gets manual allocation. 
 I get the best of both.


Yes.

I've been working on fast programs all my professional life.
Say you want top performance.
You would go ASICs.
But it's impractical so you could go FPGA.
But it's impractical so you could go GPGPU.
But it's impractical so you decide to go native.

One already traded a lot of speed for convenience, and THEN 
decide one need every last performance bit. This is a _common_ 
scenario, though not necessarily a reasonable one.

So let's say you were tasked to make one program as fast as 
possible, native on the CPU.

Seen from afar, this GC thing will be a tiny blip on the radar of 
everything that could make your program a bit slower: disk 
caches, network, memory bandwidth, maxing threading, compiler 
bugs... and of course the much larger risk of breaking the 
program with failed optimizations.

It is easy to make things fast even with the D GC. You just have 
to optimize if it is a problem, move it out of GC. Grow buffers, 
use realloc(), etc. It is the same you would have done in other 
native languages. This doesn't just rule out the stdlib, it also 
rules out almost any other library not written with the 
performance goal.

Thankfully we have  nogc, -betterC, -profile=gc, and whatnot. 
AFAIK people of D are using to push the boundaries and have fast 
things. I would wager it's not the biggest challenge of all to 
deal with the GC - or to avoid it. Perhaps harder in a team?

The GC is an extension that allows programs that can afford a GC 
(most) to be written faster.

It is the default, because most programs don't begin their lives 
with a need to be fast, or correct, but mostly to be written 
quickly! always-has-been.gif

Write gates are inherently "not-native", like integer overflow 
checks and boundscheck that you can't remove. It is one more 
invariant to maintain for the system programmer, for something 
that would couple things way beyond the druntime it was made for. 
It is surprising it is pushed so often with zero use cases.
Oct 29 2022
parent reply Ola Fosheim =?UTF-8?B?R3LDuHN0YWQ=?= <ola.fosheim.grostad gmail.com> writes:
On Saturday, 29 October 2022 at 11:22:20 UTC, Guillaume Piolat 
wrote:

 You would go ASICs.
 But it's impractical so you could go FPGA.
 But it's impractical so you could go GPGPU.
 But it's impractical so you decide to go native.


I think this pattern is close the culture of C/C++, in the sense 
that many like to get a clear view of how their code is related 
to machine code instructions and memory layout. C/C++ is as close 
they feel they can get to machine code without taking the costs 
of dropping down to that level.

Rust and D have some of these, but also a large segment of users 
that are attracted to primarily high level programming. To a 
large extent I think this is a result of how these languages 
present them to newbies. If you present a high level layer to 
newbies you will grow a different user-base profile/culture. I am 
not sure if this is a good move as it is difficult to collect 
feedback that gives a clear focus on where to improve if the 
interests are diverse.

Maybe Zig is doing better than some competitors because it does 
not try to provide a high level experience (or do they?). Anyway, 
from a distance it looks like Zig is attracting a more more 
cohesive group of programmers with more overlapping expectations.
Oct 29 2022
parent reply ISO C with Modules <isoC gmail.com> writes:
On Sunday, 30 October 2022 at 00:36:23 UTC, Ola Fosheim Grøstad 
wrote:

 ...
 ....
 Maybe Zig is doing better than some competitors because it does 
 not try to provide a high level experience (or do they?). 
 Anyway, from a distance it looks like Zig is attracting a more 
 more cohesive group of programmers with more overlapping 
 expectations.


So Zig (like all C replacement wannabeess..) IS meant to be a 
higher level of experience of C?

But C is 'THE' standard, for low level programming (excluding 
assembly of course).

Why would anyone need a higher level for low level programming?

That makes no sense whatsoever!

It's why all these 'better than C' languages never get anywhere...

C++ (not C) should be the replacment target of new programming 
languages.

The only improvement you can make on C, is getting rid of the 
need for .h files.

i.e. C needs modules. That's all it needs. To add anything else, 
simply takes away it's advantages (which is .. low level 
programming).

Yes... I know.. D does this for C... but it needs to be an 
international standard for it to be meaningful.

I cannot go work for a company that uses C, and say hey we can 
use D's C with modules.

It's a non-starter.

ISO C with Modules ..please.
Oct 29 2022
next sibling parent Ola Fosheim =?UTF-8?B?R3LDuHN0YWQ=?= <ola.fosheim.grostad gmail.com> writes:
On Sunday, 30 October 2022 at 04:06:40 UTC, ISO C with Modules 
wrote:

 ISO C with Modules ..please.


That is basically C++20... You just need to wait for 
implementations to be finalized.
Oct 30 2022
prev sibling parent reply Imperatorn <johan_forsberg_86 hotmail.com> writes:
On Sunday, 30 October 2022 at 04:06:40 UTC, ISO C with Modules 
wrote:

 On Sunday, 30 October 2022 at 00:36:23 UTC, Ola Fosheim Grøstad 
 wrote:

 [...]


 So Zig (like all C replacement wannabeess..) IS meant to be a 
 higher level of experience of C?

 [...]


Why does D need to be standardized? I mean, it would be great if 
it was, but why would it be a "non-starter" otherwise?
Oct 30 2022
parent reply ISO C with Modules <ISO_C gmail.com> writes:
On Sunday, 30 October 2022 at 07:45:55 UTC, Imperatorn wrote:

 ..
 ...
 Why does D need to be standardized? I mean, it would be great 
 if it was, but why would it be a "non-starter" otherwise?


So my arguement was for making a D like implementation of 'C with 
modules', into an ISO standard (not making D into a ISO standard).

You ask why?

Because an international standard *ensures* that 'quiet changes' 
do NOT occur.
Oct 30 2022
next sibling parent Max Samukha <maxsamukha gmail.com> writes:
On Sunday, 30 October 2022 at 09:27:14 UTC, ISO C with Modules 
wrote:


 Because an international standard *ensures* that 'quiet 
 changes' do NOT occur.


It also ensures that hardly any changes occur. I hoped C++ would 
be killed by the inefficiency of the standardization process, but 
the environment doesn't seem to be changing fast enough for that 
to happen.
Oct 30 2022
prev sibling parent reply bachmeier <no spam.net> writes:
On Sunday, 30 October 2022 at 09:27:14 UTC, ISO C with Modules 
wrote:

 On Sunday, 30 October 2022 at 07:45:55 UTC, Imperatorn wrote:

 ..
 ...
 Why does D need to be standardized? I mean, it would be great 
 if it was, but why would it be a "non-starter" otherwise?


 So my arguement was for making a D like implementation of 'C 
 with modules', into an ISO standard (not making D into a ISO 
 standard).

 You ask why?

 Because an international standard *ensures* that 'quiet 
 changes' do NOT occur.


You know what else ensures that quiet changes do NOT occur? Using 
the same version of the compiler. It also prevents you from 
having to choose between using compiler extensions or limiting 
yourself to functionality that didn't have the consensus of the 
committee. And when an updated standard comes out, which adds 
modules, you don't have to decide which "standard" you're using.
Oct 30 2022
parent reply Tejas <notrealemail gmail.com> writes:
On Sunday, 30 October 2022 at 14:12:39 UTC, bachmeier wrote:

 On Sunday, 30 October 2022 at 09:27:14 UTC, ISO C with Modules 
 wrote:

 On Sunday, 30 October 2022 at 07:45:55 UTC, Imperatorn wrote:

 ..
 ...
 Why does D need to be standardized? I mean, it would be great 
 if it was, but why would it be a "non-starter" otherwise?


 So my arguement was for making a D like implementation of 'C 
 with modules', into an ISO standard (not making D into a ISO 
 standard).

 You ask why?

 Because an international standard *ensures* that 'quiet 
 changes' do NOT occur.


 You know what else ensures that quiet changes do NOT occur? 
 Using the same version of the compiler. It also prevents you 
 from having to choose between using compiler extensions or 
 limiting yourself to functionality that didn't have the 
 consensus of the committee. And when an updated standard comes 
 out, which adds modules, you don't have to decide which 
 "standard" you're using.


Stuff breaks when things change as loudly as possible, ie, with a 
large number of warnings beforehand; I doubt a silent change in 
any moderately popular compiler will ever go unnoticed, since it 
would be liable to affect something, somewhere, and someone will 
come and complain
Oct 30 2022
parent bachmeier <no spam.net> writes:
On Sunday, 30 October 2022 at 15:00:49 UTC, Tejas wrote:

 On Sunday, 30 October 2022 at 14:12:39 UTC, bachmeier wrote:

 On Sunday, 30 October 2022 at 09:27:14 UTC, ISO C with Modules 
 wrote:

 On Sunday, 30 October 2022 at 07:45:55 UTC, Imperatorn wrote:

 ..
 ...
 Why does D need to be standardized? I mean, it would be 
 great if it was, but why would it be a "non-starter" 
 otherwise?


 So my arguement was for making a D like implementation of 'C 
 with modules', into an ISO standard (not making D into a ISO 
 standard).

 You ask why?

 Because an international standard *ensures* that 'quiet 
 changes' do NOT occur.


 You know what else ensures that quiet changes do NOT occur? 
 Using the same version of the compiler. It also prevents you 
 from having to choose between using compiler extensions or 
 limiting yourself to functionality that didn't have the 
 consensus of the committee. And when an updated standard comes 
 out, which adds modules, you don't have to decide which 
 "standard" you're using.


 Stuff breaks when things change as loudly as possible, ie, with 
 a large number of warnings beforehand; I doubt a silent change 
 in any moderately popular compiler will ever go unnoticed, 
 since it would be liable to affect something, somewhere, and 
 someone will come and complain


Nothing breaks, either loudly or quietly, whatever those terms 
mean, if you don't change the compiler. It is common for people 
to invent reasons to justify what they want to do.
Oct 30 2022
prev sibling next sibling parent reply bachmeier <no spam.net> writes:
On Friday, 28 October 2022 at 09:51:04 UTC, Imperatorn wrote:

 Hi guys,

 Just wanted to remind you that, D maybe isn't that bad.

 We're very good at bashing our own language, but we should also 
 remember sometimes what it has given us.


Who's this "we" of whom you speak?

D does the job for me. It would be weird for me to post over and 
over here that it worked for me yet again.

As Mark Twain once said, "There are only two kinds of languages: 
the ones people complain about and the ones nobody uses."
Oct 28 2022
parent reply Siarhei Siamashka <siarhei.siamashka gmail.com> writes:
On Friday, 28 October 2022 at 14:22:23 UTC, bachmeier wrote:

 As Mark Twain once said, "There are only two kinds of 
 languages: the ones people complain about and the ones nobody 
 uses."


The former being C++ or Rust and the latter being D? ;-)
Oct 28 2022
parent reply Imperatorn <johan_forsberg_86 hotmail.com> writes:
On Friday, 28 October 2022 at 18:56:31 UTC, Siarhei Siamashka 
wrote:

 On Friday, 28 October 2022 at 14:22:23 UTC, bachmeier wrote:

 As Mark Twain once said, "There are only two kinds of 
 languages: the ones people complain about and the ones nobody 
 uses."


 The former being C++ or Rust and the latter being D? ;-)


Bro, that quote would make D the most used language in the known 
universe
Oct 28 2022
parent reply Ali <fakeemail example.com> writes:
On Friday, 28 October 2022 at 19:42:43 UTC, Imperatorn wrote:

 Bro, that quote would make D the most used language in the 
 known universe


stop being sympathetic towards D, yes, it could have been in a 
better place, but it is not, it will not, it is what it is

sympathy towards D will change nothing

Walter is a nice guy, and you wish his language did better, you 
wish he was in a better place, but nice people dont always win, 
it is what it is

I dont know what is it exactly about D that drive so many people 
to have that much sympathy for it
Oct 28 2022
next sibling parent Imperatorn <johan_forsberg_86 hotmail.com> writes:
On Friday, 28 October 2022 at 20:41:13 UTC, Ali wrote:

 On Friday, 28 October 2022 at 19:42:43 UTC, Imperatorn wrote:

 Bro, that quote would make D the most used language in the 
 known universe


 stop being sympathetic towards D, yes, it could have been in a 
 better place, but it is not, it will not, it is what it is

 sympathy towards D will change nothing

 Walter is a nice guy, and you wish his language did better, you 
 wish he was in a better place, but nice people dont always win, 
 it is what it is

 I dont know what is it exactly about D that drive so many 
 people to have that much sympathy for it


💓
Oct 28 2022
prev sibling next sibling parent reply bachmeier <no spam.net> writes:
On Friday, 28 October 2022 at 20:41:13 UTC, Ali wrote:

 On Friday, 28 October 2022 at 19:42:43 UTC, Imperatorn wrote:

 Bro, that quote would make D the most used language in the 
 known universe


 stop being sympathetic towards D, yes, it could have been in a 
 better place, but it is not, it will not, it is what it is

 sympathy towards D will change nothing

 Walter is a nice guy, and you wish his language did better, you 
 wish he was in a better place, but nice people dont always win, 
 it is what it is

 I dont know what is it exactly about D that drive so many 
 people to have that much sympathy for it


Have you ever used a language other than D? If so, you will find 
that, no matter which one it is, there are things you don't like 
about it or that you think could have been done better. If you 
don't like D, don't use it, but there's no value in writing 
condescending posts telling those of us that do that we're too 
dumb to know we shouldn't.
Oct 28 2022
parent Imperatorn <johan_forsberg_86 hotmail.com> writes:
On Friday, 28 October 2022 at 20:51:56 UTC, bachmeier wrote:

 On Friday, 28 October 2022 at 20:41:13 UTC, Ali wrote:

 On Friday, 28 October 2022 at 19:42:43 UTC, Imperatorn wrote:

 Bro, that quote would make D the most used language in the 
 known universe


 stop being sympathetic towards D, yes, it could have been in a 
 better place, but it is not, it will not, it is what it is

 sympathy towards D will change nothing

 Walter is a nice guy, and you wish his language did better, 
 you wish he was in a better place, but nice people dont always 
 win, it is what it is

 I dont know what is it exactly about D that drive so many 
 people to have that much sympathy for it


 Have you ever used a language other than D? If so, you will 
 find that, no matter which one it is, there are things you 
 don't like about it or that you think could have been done 
 better. If you don't like D, don't use it, but there's no value 
 in writing condescending posts telling those of us that do that 
 we're too dumb to know we shouldn't.


Exactly, I have used over 30 languages. That's why I am making 
this post, to get some perspective.
D isn't that bad.

I think D can be saved with not too much effort actually.

But don't tell anyone D is the best, let it be a secret 😎
Oct 28 2022
prev sibling next sibling parent Imperatorn <johan_forsberg_86 hotmail.com> writes:
On Friday, 28 October 2022 at 20:41:13 UTC, Ali wrote:

 On Friday, 28 October 2022 at 19:42:43 UTC, Imperatorn wrote:

 Bro, that quote would make D the most used language in the 
 known universe


 stop being sympathetic towards D, yes, it could have been in a 
 better place, but it is not, it will not, it is what it is

 sympathy towards D will change nothing

 Walter is a nice guy, and you wish his language did better, you 
 wish he was in a better place, but nice people dont always win, 
 it is what it is

 I dont know what is it exactly about D that drive so many 
 people to have that much sympathy for it


"wish that he was in a better place"

Sorry Walter, RIP 😎
Oct 28 2022
prev sibling next sibling parent reply "H. S. Teoh" <hsteoh qfbox.info> writes:
On Fri, Oct 28, 2022 at 08:41:13PM +0000, Ali via Digitalmars-d wrote:
[...]

 I dont know what is it exactly about D that drive so many people to
 have that much sympathy for it


Maybe, just maybe, D does a lot of things right, in spite of doing a few
things wrong (that people love to pick on and complain about)? ;-)

What I can't explain, though, is why people who purportedly hate D and
think it's DOA still linger around the D forums for some reason, and
spend a lot of time and energy writing about why D sux.  Instead of,
y'know, moving on to Rust and living happily ever after, or something.
What's keeping them here?  Maybe they secretly love D and just can't
admit it to themselves? :-P  OR maybe they just have too much time on
their hands that could have been spent, I dunno, writing Rust or
something.  Really makes one wonder why they aren't spending their time
writing code in a better (according to them) language rather than
complaining about a language they purportedly don't like, in a forum
dedicated to that language.  It's puzzling.


T

-- 
First Rule of History: History doesn't repeat itself -- historians merely
repeat each other.
Oct 28 2022
next sibling parent Sergey <kornburn yandex.ru> writes:
On Friday, 28 October 2022 at 21:11:00 UTC, H. S. Teoh wrote:

 On Fri, Oct 28, 2022 at 08:41:13PM +0000, Ali via Digitalmars-d 
 wrote: [...]

 I dont know what is it exactly about D that drive so many 
 people to have that much sympathy for it


 Maybe, just maybe, D does a lot of things right, in spite of 
 doing a few
 things wrong (that people love to pick on and complain about)? 
 ;-)

 What I can't explain, though, is why people who purportedly 
 hate D and think it's DOA still linger around the D forums for 
 some reason, and spend a lot of time and energy writing about 
 why D sux.  Instead of, y'know, moving on to Rust and living 
 happily ever after, or something. What's keeping them here?  
 Maybe they secretly love D and just can't admit it to 
 themselves? :-P  OR maybe they just have too much time on their 
 hands that could have been spent, I dunno, writing Rust or 
 something.  Really makes one wonder why they aren't spending 
 their time writing code in a better (according to them) 
 language rather than complaining about a language they 
 purportedly don't like, in a forum dedicated to that language.  
 It's puzzling.


 T


Maybe dissapointment that hopes were not justified..
Long time no hear from Chris :) He was angry about breaking 
changes with new version of compiler and that he had to rewrite 
his >100k loc project if I remember correctly.

I've seen also similar example - one member was part of 
D-community and wrote some projects in D and put his time and 
effort (making projects, bug reports). But after that he lost his 
hope or maybe some other bad experience, or just other tools 
resolve his problems.
Now everytime when he see on one IT-news website, if someone 
mentioning D in the comments - he make a lot of replies how D is 
bad, that some bugs (his bugs) have not fixed more than 10 years.
On question "why so serious and negative?" - he is answering that 
at first he was ambassador of D, but it was big waste of his time 
and he would like to save others from this fate.
Oct 28 2022
prev sibling parent reply Alexandru Ermicioi <alexandru.ermicioi gmail.com> writes:
On Friday, 28 October 2022 at 21:11:00 UTC, H. S. Teoh wrote:

 On Fri, Oct 28, 2022 at 08:41:13PM +0000, Ali via Digitalmars-d 
 wrote: [...]

 [...]


 Maybe, just maybe, D does a lot of things right, in spite of 
 doing a few
 things wrong (that people love to pick on and complain about)? 
 ;-)

 [...]


Maybe some of them do like it a lot, and that is the reason they 
complain. They are just dishonest with themselves, in the forum.
Oct 29 2022
parent Imperatorn <johan_forsberg_86 hotmail.com> writes:
On Saturday, 29 October 2022 at 16:31:44 UTC, Alexandru Ermicioi 
wrote:

 On Friday, 28 October 2022 at 21:11:00 UTC, H. S. Teoh wrote:

 On Fri, Oct 28, 2022 at 08:41:13PM +0000, Ali via 
 Digitalmars-d wrote: [...]

 [...]


 Maybe, just maybe, D does a lot of things right, in spite of 
 doing a few
 things wrong (that people love to pick on and complain about)? 
 ;-)

 [...]


 Maybe some of them do like it a lot, and that is the reason 
 they complain. They are just dishonest with themselves, in the 
 forum.


Hmm, could be.

You see the potential, and therefore want to actualize that 
potential, but you don't know how, so you complain.
Oct 29 2022
prev sibling parent =?UTF-8?Q?Ali_=c3=87ehreli?= <acehreli yahoo.com> writes:
On 10/28/22 13:41, Ali wrote:


 stop being sympathetic towards D


And stop being sympathetic towards C++.


 , yes, it could have been in a better
 place, but it is not, it will not, it is what it is


I completely agree. D has been here for so long and it will still be 
here for even longer.


 sympathy towards D will change nothing


Symphaty towards unicorns will change nothing either.


 Walter is a nice guy, and you wish his language did better,


Not at all. The language is just fine. Very usable... because... I use 
it with ease...


 you wish he
 was in a better place, but nice people dont always win, it is what it is


Agreed.


 I dont know what is it exactly about D that drive so many people to have
 that much sympathy for it


Humans... Flies will gravitate towards the popular, but some of us will 
value merit.

Ali
Oct 29 2022
prev sibling next sibling parent reply Paulo Pinto <pjmlp progtools.org> writes:
On Friday, 28 October 2022 at 09:51:04 UTC, Imperatorn wrote:

 Hi guys,

 Just wanted to remind you that, D maybe isn't that bad.

 We're very good at bashing our own language, but we should also 
 remember sometimes what it has given us.

 I have spent the last months going through other languages, and 
 I can say, the grass is always not so much greener on the other 
 side.

 Yes, there are more mature languages.
 Yes, there are languages with better ecosystems.

 But, just as an example - Zig - which is getting attention, is 
 according to the community itself (including its creator) not 
 in 1.0 until about 2025.

 And still people use it, and might even think it's better than 
 D.

 Some information from their community (not my words)
 It does **not** have a standardized package manager and build 
 system.
 It does **not** have an official registry of packages.
 It **is** unstable.
 It should **not** be used in production (actively advised 
 against).
 It changes so often that you can not rely on code to work even 
 in 1 month from now.
 etc

 And still, people still think Zig is better for some reason.

 Yes, D has it's flaws, true. But it's far from unfixable? Or is 
 that what people believe?

 Forget about Jai, Odin, Beef and all those languages.

 Go - Welcome rheumatism 👴
 Rust - Welcome brain tumor from not even being able to 
 prototype something in less than 2 years 😩
 C++ - Welcome to hell 🔥
 ...

 The only real language out there that is close to what D 
 is/could be is Nim and I respect it.
 But, its syntax is not that kind to those who loved the curly 
 braces.

 All I'm saying is - maybe it's best if we just fix D?

 There is some valid criticism, like the risk for attribute soup 
 etc. But maybe it's fixable?

 Remember what D gives you in terms of UFCS, CTFE, 
 metaprogramming, performance, package manager, prototyping, 
 inline assembly, 3 compilers for different use cases etc.

 Is D really that bad?


The language itself isn't bad, it actually quite alright, when I 
bough Andrei's book, I thought to have found a modern version of 
Modula-3 and Delphi.

However in all these years, the direction was never clear, and 
its use at Facebook and Remedy didn't do much to help it grow 
adoption.

Nowadays although D the language is quite nice, for my line of 

level coding + AOT + ecosystem, mean that in no way I would be 
able to convince my peers to use D.

On top of that, for better or worse, Go and Rust are also 
creeping in into my line of work, as we are adopting frameworks 
written in those languages, making it even harder to try to 
advocate for D.

So for me, D remains one of the languages that I have fun doing 
hobby coding.
Oct 28 2022
parent reply Imperatorn <johan_forsberg_86 hotmail.com> writes:
On Friday, 28 October 2022 at 15:55:33 UTC, Paulo Pinto wrote:

 On Friday, 28 October 2022 at 09:51:04 UTC, Imperatorn wrote:

 [...]


 The language itself isn't bad, it actually quite alright, when 
 I bough Andrei's book, I thought to have found a modern version 
 of Modula-3 and Delphi.

 However in all these years, the direction was never clear, and 
 its use at Facebook and Remedy didn't do much to help it grow 
 adoption.

 Nowadays although D the language is quite nice, for my line of 

 level coding + AOT + ecosystem, mean that in no way I would be 
 able to convince my peers to use D.

 On top of that, for better or worse, Go and Rust are also 
 creeping in into my line of work, as we are adopting frameworks 
 written in those languages, making it even harder to try to 
 advocate for D.

 So for me, D remains one of the languages that I have fun doing 
 hobby coding.


Same for me. But I never understand why. If D was called Rust 
instead, would it be more popular or widely used? I seriously 
don't know sometimes. It feels like fashion
Oct 28 2022
parent Paulo Pinto <pjmlp progtools.org> writes:
On Friday, 28 October 2022 at 16:31:48 UTC, Imperatorn wrote:

 On Friday, 28 October 2022 at 15:55:33 UTC, Paulo Pinto wrote:

 On Friday, 28 October 2022 at 09:51:04 UTC, Imperatorn wrote:

 [...]


 The language itself isn't bad, it actually quite alright, when 
 I bough Andrei's book, I thought to have found a modern 
 version of Modula-3 and Delphi.

 However in all these years, the direction was never clear, and 
 its use at Facebook and Remedy didn't do much to help it grow 
 adoption.

 Nowadays although D the language is quite nice, for my line of 

 low level coding + AOT + ecosystem, mean that in no way I 
 would be able to convince my peers to use D.

 On top of that, for better or worse, Go and Rust are also 
 creeping in into my line of work, as we are adopting 
 frameworks written in those languages, making it even harder 
 to try to advocate for D.

 So for me, D remains one of the languages that I have fun 
 doing hobby coding.


 Same for me. But I never understand why. If D was called Rust 
 instead, would it be more popular or widely used? I seriously 
 don't know sometimes. It feels like fashion


Execution, knowing what it is supposed to be and double down on 
that.

D could have been the C++ companion for game developers, instead
Oct 28 2022
prev sibling next sibling parent Ali <fakeemail example.com> writes:
On Friday, 28 October 2022 at 09:51:04 UTC, Imperatorn wrote:

 Hi guys,
 Is D really that bad?


It seems you already have an answer, and looking for validation,
what you see is what you get, there are no secrets or hidden gems

If you dont like what you see, you dont like D
Oct 28 2022
prev sibling next sibling parent reply RubyTheRoobster <rubytheroobster yandex.com> writes:
On Friday, 28 October 2022 at 09:51:04 UTC, Imperatorn wrote:

 Hi guys,

 Just wanted to remind you that, D maybe isn't that bad.

 [...]


There is something to be said for adding static break and static 
continue to the language, and we could do away with classes as a 
reference type, but D is the only language that provides the 
metaprogramming facilities that I need.
Oct 28 2022
next sibling parent reply Imperatorn <johan_forsberg_86 hotmail.com> writes:
On Friday, 28 October 2022 at 16:58:20 UTC, RubyTheRoobster wrote:

 On Friday, 28 October 2022 at 09:51:04 UTC, Imperatorn wrote:

 Hi guys,

 Just wanted to remind you that, D maybe isn't that bad.

 [...]


 There is something to be said for adding static break and 
 static continue to the language, and we could do away with 
 classes as a reference type, but D is the only language that 
 provides the metaprogramming facilities that I need.


Write a DIP 😍
Oct 28 2022
parent RubyTheRoobster <rubytheroobster yandex.com> writes:
On Friday, 28 October 2022 at 16:59:51 UTC, Imperatorn wrote:

 On Friday, 28 October 2022 at 16:58:20 UTC, RubyTheRoobster 
 wrote:

 On Friday, 28 October 2022 at 09:51:04 UTC, Imperatorn wrote:

 Hi guys,

 Just wanted to remind you that, D maybe isn't that bad.

 [...]


 There is something to be said for adding static break and 
 static continue to the language, and we could do away with 
 classes as a reference type, but D is the only language that 
 provides the metaprogramming facilities that I need.


 Write a DIP 😍


I would write one, but I don’t want my name on anything.
Oct 28 2022
prev sibling parent reply Ali <fakeemail example.com> writes:
On Friday, 28 October 2022 at 16:58:20 UTC, RubyTheRoobster wrote:

 but D is the only language that provides the metaprogramming 
 facilities that I need.


Can you elaborate more on this, can you give real life examples, 
on how this was useful
I think many languages, provide the benefits of metaprogramming, 
without necessarily calling it metaprogramming

for example:
1. Tcl everything is a string, and you have the eval function
2. Any dynamic language, that have an eval function, and where 
you can add a config file in code to your programs
3. lisp, every this is a list, and you can easily pass a function 
as a parameter
4. any language that have functions as first class objects and 
allow you to pass functions as parameters
5. any object oriented language, and it all really depend on how 
good your object model is
6. languages with metaobject

So can you give examples, of how D does those things better, or 
does things that others cant, code examples
Oct 28 2022
parent =?UTF-8?Q?Ali_=c3=87ehreli?= <acehreli yahoo.com> writes:
On 10/28/22 10:17, Ali wrote:


 I think many languages, provide the benefits of metaprogramming, without
 necessarily calling it metaprogramming


The way I understand it, metaprogramming in languages like D are decided 
at compile time. That's why C++ has been shown to be faster than C. 
Bjarne Stroustrup has an example here:

   https://www.stroustrup.com/new_learning.pdf

In short, sort() in C++ is faster than C because there is no dispatching 
through a function pointer at runtime. In languages like D, the deal is 
sealed at compile time.

D allows optimizations with compile-time introspection as well.


 for example:
 1. Tcl everything is a string, and you have the eval function


Which means, everything is parsed at run time, right? Perhaps they use 
JIT to amortize some compilation away.


 2. Any dynamic language, that have an eval function, and where you can
 add a config file in code to your programs


Same as Tcl: Must be slow.


 3. lisp, every this is a list, and you can easily pass a function as a
 parameter


At least the passed function needs to be called. There is a function 
call dispatch there.


 4. any language that have functions as first class objects and allow you
 to pass functions as parameters


Same: Function pointer dispatch.


 5. any object oriented language, and it all really depend on how good
 your object model is


Same. Or worse: Even objects need vtbl dispatch there. In contrast, D's 
range algorithms nail the implementation down to exact types that you 
have. No dynamic dispatching of any kind.

There is on contest really...


 6. languages with metaobject


I don't know that but perhaps they are better is some sense. (?)


 So can you give examples, of how D does those things better, or does
 things that others cant, code examples


I don't need to give any example at this point. Maybe you have further 
questions?

Ali
Oct 29 2022
prev sibling next sibling parent reply "H. S. Teoh" <hsteoh qfbox.info> writes:
On Fri, Oct 28, 2022 at 09:51:04AM +0000, Imperatorn via Digitalmars-d wrote:

 Hi guys,
 
 Just wanted to remind you that, D maybe isn't that bad.


[...]

 Yes, D has it's flaws, true. But it's far from unfixable? Or is that
 what people believe?


[...]

 Is D really that bad?


Nope.

D is my favorite language. Wouldn't settle for anything else.  Yeah, D
has its ugly dark corners and pet peeves that make me cringe... but then
again, every language has those, it's just a matter of whether the
benefits outweigh the annoyances.  IMO, D's advantages FAR outweigh the
dark corners.  I have decades of experience in C and C++, a smattering
of Java and other languages, and I can say none of them even holds a
candle to D.

(Although D has spoiled me so much I haven't actually bothered using C++
or Java for years now, maybe even decades, so this is probably outdated
information. :-D  Well I did write some minimal Java in my Android
project, but I wouldn't call that *using* Java, it's more like just lip
service to ease some of the pains of working with Android NDK. Even that
little made me wanna puke -- just WAY too much boilerplate, it's nigh
unusable unless you use a high-powered, resource-hogging IDE (or a auto
codegen utility, written in D :-P). I do actively use C for my day job,
but the PTB are a conservative bunch and we haven't really moved beyond
the 90's in terms of C standards, so that part is probably outdated
too. Whatever.)

Don't listen to the naysayers, D is awesome.  If it wasn't, I wouldn't
be here in the first place. *We* wouldn't be here.  Many of us came here
because we're sick and tired of other languages' bogonities. D must have
done *something* right that we're still here today.  Every language has
flaws, and D is no exception.  But that doesn't make it any less
awesome.  It still r0x my world, I don't care what other people say or
think.


T

-- 
Famous last words: I *think* this will work...
Oct 28 2022
parent Imperatorn <johan_forsberg_86 hotmail.com> writes:
On Friday, 28 October 2022 at 17:36:48 UTC, H. S. Teoh wrote:

 On Fri, Oct 28, 2022 at 09:51:04AM +0000, Imperatorn via 
 Digitalmars-d wrote:

 [...]


 [...]

 [...]


 [...]

 [...]


 Nope.

 [...]


❤️
Oct 28 2022
prev sibling next sibling parent reply Walter Bright <newshound2 digitalmars.com> writes:
On 10/28/2022 2:51 AM, Imperatorn wrote:

 And still, people still think Zig is better for some reason.


Zig has very good marketing.

The best thing we can do, is simply write articles about the programs we write
in D.

Submit presentation proposals at conferences other than DConf help a *lot*. And 
the people who have presented at DConf in the past already have presentations 
ready to go. Please just submit them!

Even for CPPCON. Submit a proposal about interfacing D to C++.

Or do one of those youtube videos showing yourself developing a D program.
Oct 28 2022
next sibling parent zjh <fqbqrr 163.com> writes:
On Saturday, 29 October 2022 at 01:59:13 UTC, Walter Bright wrote:

 ... Submit a proposal about interfacing D to C++.



What `the most lacking` is the latest `'D'` and `'C++'` 
interfacing info.
There is little information available.
Oct 28 2022
prev sibling parent Imperatorn <johan_forsberg_86 hotmail.com> writes:
On Saturday, 29 October 2022 at 01:59:13 UTC, Walter Bright wrote:

 On 10/28/2022 2:51 AM, Imperatorn wrote:

 And still, people still think Zig is better for some reason.


 Zig has very good marketing.

 The best thing we can do, is simply write articles about the 
 programs we write in D.

 Submit presentation proposals at conferences other than DConf 
 help a *lot*. And the people who have presented at DConf in the 
 past already have presentations ready to go. Please just submit 
 them!

 Even for CPPCON. Submit a proposal about interfacing D to C++.

 Or do one of those youtube videos showing yourself developing a 
 D program.


True, I never understand how they do it though. D *is* superior.

Maybe I will do some videos on D development next month actually.
Oct 29 2022
prev sibling next sibling parent reply You know I'm bad <youknowIamBad gmail.com> writes:
On Friday, 28 October 2022 at 09:51:04 UTC, Imperatorn wrote:

 ..
 Is D really that bad?


No. If you use the version of D that I use, that has BOTH private 
to the class AND private to the module, then .. D is not that bad 
;-)
Oct 29 2022
parent zjh <fqbqrr 163.com> writes:
On Saturday, 29 October 2022 at 07:21:36 UTC, You know I'm bad 
wrote:

 that has BOTH private to the class AND private to the module, 
 then .. D is not that bad ;-)



`Class level private` options should be provided for D.

You can do without it, but you should `have` it. It's more 
convenient for users.
Oct 29 2022
prev sibling next sibling parent reply Imperatorn <johan_forsberg_86 hotmail.com> writes:
On Friday, 28 October 2022 at 09:51:04 UTC, Imperatorn wrote:

 Hi guys,

 Just wanted to remind you that, D maybe isn't that bad.

 [...]


My original question remains, is D really that bad? I don't think 
so. I think the frustration comes from not being able to fix some 
things. But, I think it's doable, while others seem not to think 
so.
Oct 30 2022
parent reply Ola Fosheim =?UTF-8?B?R3LDuHN0YWQ=?= <ola.fosheim.grostad gmail.com> writes:
On Sunday, 30 October 2022 at 16:00:24 UTC, Imperatorn wrote:

 My original question remains, is D really that bad? I don't 
 think so. I think the frustration comes from not being able to 
 fix some things. But, I think it's doable, while others seem 
 not to think so.


It is doable if you come up with a design that is wholesome and 
can get Walter on board, but I dont think it can be done in the 
forums or issue by issue.

The D semantics are fairly standard for the most part so it would 
be weird to assume that it could not be "fixed".
Oct 30 2022
parent reply Imperatorn <johan_forsberg_86 hotmail.com> writes:
On Sunday, 30 October 2022 at 17:18:40 UTC, Ola Fosheim Grøstad 
wrote:

 On Sunday, 30 October 2022 at 16:00:24 UTC, Imperatorn wrote:

 My original question remains, is D really that bad? I don't 
 think so. I think the frustration comes from not being able to 
 fix some things. But, I think it's doable, while others seem 
 not to think so.


 It is doable if you come up with a design that is wholesome and 
 can get Walter on board, but I dont think it can be done in the 
 forums or issue by issue.

 The D semantics are fairly standard for the most part so it 
 would be weird to assume that it could not be "fixed".


You might be right. I don't know. I guess the "goal" has to be 
more precise to be able to judge whether we are on the right 
track or not.
Oct 30 2022
parent reply Daniel Donnelly, Jr. <enjoysmath gmail.com> writes:
I think D can safely be used in production.  If the sublanguage 
of D that you actually know all works well, then it's good to go! 
:D
Oct 30 2022
parent reply Imperatorn <johan_forsberg_86 hotmail.com> writes:
On Sunday, 30 October 2022 at 19:05:35 UTC, Daniel Donnelly, Jr. 
wrote:

 I think D can safely be used in production.  If the sublanguage 
 of D that you actually know all works well, then it's good to 
 go! :D


I think so too. But sometimes I get the feeling there's a belief 
that you can't. I want to understand where this belief comes 
from. If you can use C in production you can use D in production.

It's kinda weird that someone can state "D isn't production 
ready" while at the same time say "Zig is production ready" when 
their own community explicitly says "don't use it in production", 
"it's unstable".

It does not compute my friends.

Clarification:
Zig was just an example, I could have chosen any other language 
in the same sphere. I have nothing against Zig at all and I think 
they have a good and honest community.
Oct 30 2022
next sibling parent reply Mike Parker <aldacron gmail.com> writes:
On Sunday, 30 October 2022 at 19:16:22 UTC, Imperatorn wrote:


 It's kinda weird that someone can state "D isn't production 
 ready" while at the same time say "Zig is production ready" 
 when their own community explicitly says "don't use it in 
 production", "it's unstable".

 It does not compute my friends.


Given that there are plenty of people using D in production right 
now, I'd say it doesn't matter at all when someone says something 
like that. There always have been and always will be naysayers 
expressing negative opinions about D, and many of them aren't 
going to change their minds no matter what any of us do or say. 
You can't change minds that aren't open to changing.

Meanwhile, the rest of us are using D to get stuff done and/or 
working to make it better. The best thing anyone who likes the 
language can do is to keep using it and promote their work. Write 
about it, share it, make videos about it, etc. There are people 
out there who *are* open to trying new languages. Content showing 
how we're using D to solve real-world problems will potentially 
entice them to try it. You can see that in discussion threads 
asking current D users how they came to D: it was this article, 
or that video, or that project.

I rarely engage with anyone bashing D on reddit/HN or wherever 
anymore. There's usually no point to it. I'll leave a comment to 
correct misinformation when I see it (e.g., "there used to be two 
standard libraries, one GC and one non-GC, and the GC library 
won" was a recent one I found), or to clarify something. My 
comments in that case are for people reading the thread, not for 
the person I'm replying to. Sometimes the original commenter will 
reply with something like, "Thanks. I didn't know that." or "My 
info must be out of date.", but that's very rare in my experience.

My advice: if you're happy with D, then ignore the crap people 
say and just get on with it. Work on your project, report issues, 
fix issues if you can, and if you can make the time, blog about 
your experiences.
Oct 30 2022
next sibling parent surlymoor <surlymoor cock.li> writes:
On Monday, 31 October 2022 at 01:52:20 UTC, Mike Parker wrote:

 I rarely engage with anyone bashing D on reddit/HN or wherever 
 anymore. There's usually no point to it. I'll leave a comment 
 to correct misinformation when I see it (e.g., "there used to 
 be two standard libraries, one GC and one non-GC, and the GC 
 library won" was a recent one I found), or to clarify 
 something. My comments in that case are for people reading the 
 thread, not for the person I'm replying to. Sometimes the 
 original commenter will reply with something like, "Thanks. I 
 didn't know that." or "My info must be out of date.", but 
 that's very rare in my experience.

 My advice: if you're happy with D, then ignore the crap people 
 say and just get on with it. Work on your project, report 
 issues, fix issues if you can, and if you can make the time, 
 blog about your experiences.


This is the way.
Oct 30 2022
prev sibling parent "H. S. Teoh" <hsteoh qfbox.info> writes:
On Mon, Oct 31, 2022 at 01:52:20AM +0000, Mike Parker via Digitalmars-d wrote:
[...]

 I rarely engage with anyone bashing D on reddit/HN or wherever
 anymore.  There's usually no point to it.


In my decades long experience with online forums, I've come to one
conclusion: flamewars (heated debates and arguments) are *never*
productive. Ever.  Most online personae have already made up their minds
beforehand and have no intention of changing their opinions. Even if you
beat them in the argument they will simply ignore it and repeat exactly
the same thing somewhere or sometime else.  It's a total waste of time
and energy.

You'll save yourself much time, energy, and grief, by not engaging in
the first place, and directing your efforts elsewhere.  Like
contributing code, writing articles and docs, etc..  Online forums with
like-minded people sometimes can be a good way of blowing off steam or
petting yourself on the back, but when the flames break out, the only
winning move is to not play.


[...]

 My advice: if you're happy with D, then ignore the crap people say and
 just get on with it. Work on your project, report issues, fix issues
 if you can, and if you can make the time, blog about your experiences.


Exactly!!!

I'd also add, if you have a good experience with your D project, it
doesn't hurt to rave about it on the forums (I should do that more often
:-D).  The tendency is to post only when you encounter a problem, and
this creates a false impression of general negativity to a bystander.
Occasionally sprinkling some positive reports will help dispel this
false impression.


T

-- 
Nobody is perfect.  I am Nobody. -- pepoluan, GKC forum
Nov 02 2022
prev sibling parent Walter Bright <newshound2 digitalmars.com> writes:
On 10/30/2022 12:16 PM, Imperatorn wrote:

 It does not compute my friends.


Stories contributing to my education on this matter:

----------------------------
Company A would come to us and say: "we'll buy a bunch of your compilers, but
we 
need X implemented."

We'd implemented X, and rush back to A: "we got X implemented! How many 
compilers do you wish to purchase?"

A says: "er, well, uhh, .... we also need Y! Yeah, do Y and we'll be ready to
buy!"

You can guess where this goes. We do Y, and then they want Z. It's a 
never-ending merry-go-round. They were never going to buy it, they just didn't 
want to say that, so they'd just come up with some imagined deficit and use
that 
as an excuse.
-----------------------------
A friend of mine, a Java user, in the 90's while talking to me said that what 
the world needs was a native Java compiler. He went on and on about it, saying 
it would be a huge success for me (I wrote a Java compiler for Symantec) and 
would make a big impact.

At the end of this, I said "I think you're right. So right, in fact, that I 
already developed a native Java compiler. You can download it right now and use
it!"

He was silent. Of course he didn't download it. It didn't take the world by 
storm, either.
------------------------------
This was recounted by a friend of mine. He was kibitzing with a colleague who 
adamantly claimed that the most important feature of a C++ compiler was compile 
speed. So my friend asked him which C++ compiler he used. The reply was 
Microsoft C++. My friend laughed and said that compiler speed was the lowest 
priority to him, as MSC++ was, at the time, the slowest C++ compiler on the 
market. Zortech C++ was 4x as fast at compilation.

The most important feature for him was the brand name.
------------------------------
I was driving home after seeing a movie with friends. One them remarked about 
how I hated the movie. I was shocked, saying I loved the movie. The reply: "but 
you only said negative things about it." Upon reflection, that was an accurate 
description of what I did, and what I normally did.
------------------------------

The lessons I learned from this are:

1. some people just like to complain

2. existing users are far, far more worthwhile to listen to than others

3. existing users who have specific problems in their workflow with the product 
are the ones to prioritize

4. marketing is unbelievably important

5. be careful that you're not just making a faster horse. Sometimes you gotta 
take a chance and build a car
Oct 30 2022
prev sibling next sibling parent reply Bioinfornatics <bioinfornatics fedoraproject.org> writes:
On Friday, 28 October 2022 at 09:51:04 UTC, Imperatorn wrote:

 Hi guys,

 Just wanted to remind you that, D maybe isn't that bad.

 We're very good at bashing our own language, but we should also 
 remember sometimes what it has given us.

 I have spent the last months going through other languages, and 
 I can say, the grass is always not so much greener on the other 
 side.

 Yes, there are more mature languages.
 Yes, there are languages with better ecosystems.

 But, just as an example - Zig - which is getting attention, is 
 according to the community itself (including its creator) not 
 in 1.0 until about 2025.

 And still people use it, and might even think it's better than 
 D.

 Some information from their community (not my words)
 It does **not** have a standardized package manager and build 
 system.
 It does **not** have an official registry of packages.
 It **is** unstable.
 It should **not** be used in production (actively advised 
 against).
 It changes so often that you can not rely on code to work even 
 in 1 month from now.
 etc

 And still, people still think Zig is better for some reason.

 Yes, D has it's flaws, true. But it's far from unfixable? Or is 
 that what people believe?

 Forget about Jai, Odin, Beef and all those languages.

 Go - Welcome rheumatism 👴
 Rust - Welcome brain tumor from not even being able to 
 prototype something in less than 2 years 😩
 C++ - Welcome to hell 🔥
 ...

 The only real language out there that is close to what D 
 is/could be is Nim and I respect it.
 But, its syntax is not that kind to those who loved the curly 
 braces.

 All I'm saying is - maybe it's best if we just fix D?

 There is some valid criticism, like the risk for attribute soup 
 etc. But maybe it's fixable?

 Remember what D gives you in terms of UFCS, CTFE, 
 metaprogramming, performance, package manager, prototyping, 
 inline assembly, 3 compilers for different use cases etc.

 Is D really that bad?


The main probem of D is the miss of a killer library.

     + Java is still heavily used,
       Big data: hadoop, spark ...
       Next generation Database: neo4j, orie tDB, janusgraph...
        Search: elastic search...
     + C/rust: kernel usage
     + Python : Datascience, web (fastapi) a ease of developpement

     D community has started some interresting but never reach its 
public
     Mir, D dataframe, full futured web framework...
     One of the problem of D it is some c++ user want user D as 
c++ alternative... without GC

     While to me D is the mix of
       + Python ease of use, ability to script with rdmd
       + eiffel with contract programming
       + Java, garbage collector
      With some extras features
     In one language that do 90% the work of c++ without to be a 
c++.

     So as long as the community continues
      this schizophrenia, there is no hope
Oct 31 2022
parent reply zjh <fqbqrr 163.com> writes:
On Monday, 31 October 2022 at 10:09:13 UTC, Bioinfornatics wrote:


     D community has started some interresting but never reach 
 its public
     Mir, D dataframe, full futured web framework...
     One of the problem of D it is some c++ user want user D as 
 c++ alternative... without GC

     While to me D is the mix of
       + Python ease of use, ability to script with rdmd
       + eiffel with contract programming
       + Java, garbage collector
      With some extras features
     In one language that do 90% the work of c++ without to be a 
 c++.

     So as long as the community continues
      this schizophrenia, there is no hope



D is a `center` language . It `competes` with all languages. 
Therefore, it has higher requirements!
`GC` cannot support it to survive in the intense competition.
Oct 31 2022
parent reply IGotD- <nise nise.com> writes:
On Monday, 31 October 2022 at 12:10:15 UTC, zjh wrote:

 D is a `center` language . It `competes` with all languages. 
 Therefore, it has higher requirements!
 `GC` cannot support it to survive in the intense competition.


Modern languages have more support for asynchronous and 
multithreaded programming than ever. You simply cannot have a 
stop the world GC in such environments in order to be competitive.
Oct 31 2022
next sibling parent reply Imperatorn <johan_forsberg_86 hotmail.com> writes:
On Monday, 31 October 2022 at 12:20:10 UTC, IGotD- wrote:

 On Monday, 31 October 2022 at 12:10:15 UTC, zjh wrote:

 D is a `center` language . It `competes` with all languages. 
 Therefore, it has higher requirements!
 `GC` cannot support it to survive in the intense competition.


 Modern languages have more support for asynchronous and 
 multithreaded programming than ever. You simply cannot have a 
 stop the world GC in such environments in order to be 
 competitive.


I guess async/await is one thing I really miss in D (when 

do that I need.
Oct 31 2022
parent Bioinfornatics <bioinfornatics fedoraproject.org> writes:
On Monday, 31 October 2022 at 12:24:38 UTC, Imperatorn wrote:

 On Monday, 31 October 2022 at 12:20:10 UTC, IGotD- wrote:

 On Monday, 31 October 2022 at 12:10:15 UTC, zjh wrote:

 D is a `center` language . It `competes` with all languages. 
 Therefore, it has higher requirements!
 `GC` cannot support it to survive in the intense competition.


 Modern languages have more support for asynchronous and 
 multithreaded programming than ever. You simply cannot have a 
 stop the world GC in such environments in order to be 
 competitive.


 I guess async/await is one thing I really miss in D (when 

 can't do that I need.


They are fiber for this purpose:
https://tour.dlang.org/tour/en/multithreading/fibers

Did you want syntaxic sugar to use async/await which would use a 
fiber?
Oct 31 2022
prev sibling next sibling parent reply zjh <fqbqrr 163.com> writes:
On Monday, 31 October 2022 at 12:20:10 UTC, IGotD- wrote:

 You simply cannot have a stop the world GC in such environments 
 in order to be competitive.


`D` needs a reasonable `todo` list with `priority` !.
There are too many things to do. `D` need to arrange them 
reasonably!
Oct 31 2022
next sibling parent reply Walter Bright <newshound2 digitalmars.com> writes:
On 10/31/2022 5:47 AM, zjh wrote:

 `D` needs a reasonable `todo` list with `priority` !.


The thing is, we don't assign people tasks from a list. People work on what
they 
want to work on. Sponsors can fund specific tasks they need done.
Oct 31 2022
next sibling parent reply Timon Gehr <timon.gehr gmx.ch> writes:
On 10/31/22 20:52, Walter Bright wrote:

 On 10/31/2022 5:47 AM, zjh wrote:

 `D` needs a reasonable `todo` list with `priority` !.


 
 The thing is, we don't assign people tasks from a list. People work on 
 what they want to work on. Sponsors can fund specific tasks they need done.


The value of such a list is that people who do want to work on one of 
the items on the list anyway receive some assurance that what they want 
to work on aligns with the goals of the project and has a reasonable 
chance of being upstreamed. This is important for people who have 
limited resources to spend on open source projects not immediately 
related to their day job. For example, your and Andrei's very clear, 
concise and consistent communication making clear that that `static 
foreach` is desirable but difficult to implement is exactly what 
prompted me to start working on the implementation.

I think the foundation has generally been moving into this direction? 
(E.g., vision statements.) Of course, keeping a detailed list up to date 
also causes some overhead, so it is a tradeoff.
Oct 31 2022
parent reply Walter Bright <newshound2 digitalmars.com> writes:
On 10/31/2022 2:58 PM, Timon Gehr wrote:

 The value of such a list is that people who do want to work on one of the
items 
 on the list anyway receive some assurance that what they want to work on
aligns 
 with the goals of the project and has a reasonable chance of being upstreamed.


All they have to do is ask the community by posting in the forum.

We've been known to incorporate projects people have done all on their own 
initiative. I've been known to ask the creators of such projects to donate them 
to D.



 This is important for people who have limited resources to spend on open
source 
 projects not immediately related to their day job. For example, your and 
 Andrei's very clear, concise and consistent communication making clear that
that 
 `static foreach` is desirable but difficult to implement is exactly what 
 prompted me to start working on the implementation.


Thank you for adding static foreach! Much appreciated. People with your level
of 
skill and knowledge of programming languages are rare, and it's highly likely 
I'll want to incorporate anything you feel motivated to do.



 I think the foundation has generally been moving into this direction? (E.g., 
 vision statements.) Of course, keeping a detailed list up to date also causes 
 some overhead, so it is a tradeoff.


If someone wants to pick up where the prototype concurrent GC was left, I'm all 
for it. I suspect we all are for it.

For anyone who does this, it'll look very good on her/his resume! The payoff is 
much more than just for D karma points.
Oct 31 2022
next sibling parent reply rikki cattermole <rikki cattermole.co.nz> writes:
On 01/11/2022 1:16 PM, Walter Bright wrote:

 For anyone who does this, it'll look very good on her/his resume! The 
 payoff is much more than just for D karma points.


Depends on what you are meaning.

There is one concurrent GC implementation using the existing 
implementation that is left to be done, snap shotting on Windows. This 
is mostly just adding a tiny bit of code in what should have been very 
obvious points (sadly it isn't).

Otherwise its write barriers and a whole new GC implementation, which 
very much would be impressive!
Nov 01 2022
parent Walter Bright <newshound2 digitalmars.com> writes:
On 11/1/2022 3:05 AM, rikki cattermole wrote:

 There is one concurrent GC implementation using the existing implementation
that 
 is left to be done, snap shotting on Windows. This is mostly just adding a
tiny 
 bit of code in what should have been very obvious points (sadly it isn't).


Please pick up the flag and lead to victory!
Nov 01 2022
prev sibling parent reply UmmReally <UmmReally gmail.com> writes:
On Tuesday, 1 November 2022 at 00:16:32 UTC, Walter Bright wrote:

 ..
 ....
 We've been known to incorporate projects people have done all 
 on their own initiative. I've been known to ask the creators of 
 such projects to donate them to D.


Well.. just as long that project doesn't involve providing 'an 
option' to the programmer, so the programmer can specify that a 
member of a class is private to that class.

Anything else... fine.. he'll consider it...but 'private to the 
class' .. never!
Nov 01 2022
next sibling parent reply "H. S. Teoh" <hsteoh qfbox.info> writes:
On Wed, Nov 02, 2022 at 03:42:47AM +0000, UmmReally via Digitalmars-d wrote:
[...]

 Well.. just as long that project doesn't involve providing 'an option'
 to the programmer, so the programmer can specify that a member of a
 class is private to that class.
 
 Anything else... fine.. he'll consider it...but 'private to the class'
 .. never!


Of all the issues that one could bring up about the nuclear reactor
design, the one that keeps coming up is the color of the bikeshed
attached to the building.  Clearly, this must be one of the most
critical aspects of nuclear reactor design, and the key question that
will decide whether the funding will be approved. :-P


T

-- 
All men are mortal. Socrates is mortal. Therefore all men are Socrates.
Nov 01 2022
next sibling parent reply UmmReally <UmmReally gmail.com> writes:
On Wednesday, 2 November 2022 at 04:09:09 UTC, H. S. Teoh wrote:

 ...

 Of all the issues that one could bring up about the nuclear 
 reactor design, the one that keeps coming up is the color of 
 the bikeshed attached to the building.  Clearly, this must be 
 one of the most critical aspects of nuclear reactor design, and 
 the key question that will decide whether the funding will be 
 approved. :-P


 T


Wanting to use a class to represent a concrete abstract type, 
which you can do in 'official D', is not bikesheding.

At best, in 'offical' D, you can 'simulate' using a class as an 
concrete abstract type, by putting that class in its own module.

C'mon. Let's be honest about this ;-)

The real 'bikesheding', is the pretending that this is ok.
Nov 02 2022
parent UmmReally <UmmReally gmail.com> writes:
On Wednesday, 2 November 2022 at 08:02:13 UTC, UmmReally wrote:

....


argH! prehistoric forum software!


 Wanting to use a class to represent a concrete abstract type, 
 which you can do in 'official D', is not bikesheding.


CORRECTION:
Wanting to use a class to represent a concrete abstract type, 
which you CANNOT do in 'official D', is not bikesheding.
Nov 02 2022
prev sibling parent reply bachmeier <no spam.net> writes:
On Wednesday, 2 November 2022 at 04:09:09 UTC, H. S. Teoh wrote:

 On Wed, Nov 02, 2022 at 03:42:47AM +0000, UmmReally via 
 Digitalmars-d wrote: [...]

 Well.. just as long that project doesn't involve providing 'an 
 option' to the programmer, so the programmer can specify that 
 a member of a class is private to that class.
 
 Anything else... fine.. he'll consider it...but 'private to 
 the class' .. never!


 Of all the issues that one could bring up about the nuclear 
 reactor design, the one that keeps coming up is the color of 
 the bikeshed attached to the building.  Clearly, this must be 
 one of the most critical aspects of nuclear reactor design, and 
 the key question that will decide whether the funding will be 
 approved. :-P


The big issue is why `struct` is not capitalized. If Walter would 
just fix that, D would surely take off. Until then, D is a 
complete joke.
Nov 02 2022
parent Imperatorn <johan_forsberg_86 hotmail.com> writes:
On Wednesday, 2 November 2022 at 21:54:12 UTC, bachmeier wrote:

 On Wednesday, 2 November 2022 at 04:09:09 UTC, H. S. Teoh wrote:

 On Wed, Nov 02, 2022 at 03:42:47AM +0000, UmmReally via 
 Digitalmars-d wrote: [...]

 [...]


 Of all the issues that one could bring up about the nuclear 
 reactor design, the one that keeps coming up is the color of 
 the bikeshed attached to the building.  Clearly, this must be 
 one of the most critical aspects of nuclear reactor design, 
 and the key question that will decide whether the funding will 
 be approved. :-P


 The big issue is why `struct` is not capitalized. If Walter 
 would just fix that, D would surely take off. Until then, D is 
 a complete joke.


🤣
Nov 02 2022
prev sibling parent reply surlymoor <surlymoor cock.li> writes:
On Wednesday, 2 November 2022 at 03:42:47 UTC, UmmReally wrote:

 On Tuesday, 1 November 2022 at 00:16:32 UTC, Walter Bright 
 wrote:

 ..
 ....
 We've been known to incorporate projects people have done all 
 on their own initiative. I've been known to ask the creators 
 of such projects to donate them to D.


 Well.. just as long that project doesn't involve providing 'an 
 option' to the programmer, so the programmer can specify that a 
 member of a class is private to that class.

 Anything else... fine.. he'll consider it...but 'private to the 
 class' .. never!


Just have a module with the class in it and nothing more, brotown.
I'll bill you my consultation fees later.
Nov 01 2022
parent reply UmmReally <UmmReally gmail.com> writes:
On Wednesday, 2 November 2022 at 04:48:23 UTC, surlymoor wrote:

 Just have a module with the class in it and nothing more, 
 brotown.
 I'll bill you my consultation fees later.


In my version of D (a fork based on someone elses work), I am not 
'forced' to use that 'workaround'.

Even javascript has private to the class.

D is comlete joke! i.e. ..>  that you cannot even make a private 
member within a class (except through some stupid 'workaround').

So with that...back on to topic.. YES 'offical' D really IS that 
bad!

(but not my version of D ;-)

btw. This is not really a complaint ;-)

It's great that I can create my own fork based on someone else 
work (to do what I can do in anyother langauge, including 
javascript!).
Nov 02 2022
parent reply =?UTF-8?Q?Ali_=c3=87ehreli?= <acehreli yahoo.com> writes:
On 11/2/22 00:19, UmmReally wrote:

 On Wednesday, 2 November 2022 at 04:48:23 UTC, surlymoor wrote:

 Just have a module with the class in it and nothing more, brotown.
 I'll bill you my consultation fees later.


 In my version of D (a fork based on someone elses work), I am not
 'forced' to use that 'workaround'.


A workaround is for a real problem not for an imagined one.

Besides, it is not good style to still complain about "official D" if 
you are happy with your fork.


 Even javascript has private to the class.


Because monkey see monkey do.


 D is comlete joke! i.e. ..>  that you cannot even make a private member
 within a class (except through some stupid 'workaround').


That kind of thought comes from cargo cult. Your interpretation of 
"cannot" shows a misunderstanding: D's choice is by design.


 So with that...back on to topic.. YES 'offical' D really IS that bad!


Then forkit!


 (but not my version of D ;-)


Just don't continue trolling then. Be grateful.


 btw. This is not really a complaint ;-)


There is only one definition left then: trolling.


 It's great that I can create my own fork based on someone else work (to
 do what I can do in anyother langauge, including javascript!).


I am not jealous. Email me when private-to-class will ever be really 
useful to you.

Ali
Nov 02 2022
next sibling parent reply UmmReally <UmmReally gmail.com> writes:
On Wednesday, 2 November 2022 at 18:02:11 UTC, Ali Çehreli wrote:

 On 11/2/22 00:19, UmmReally wrote:

 On Wednesday, 2 November 2022 at 04:48:23 UTC, surlymoor


 wrote:

 Just have a module with the class in it and nothing more,




 brotown.

 I'll bill you my consultation fees later.


 In my version of D (a fork based on someone elses work), I am


 not

 'forced' to use that 'workaround'.


 A workaround is for a real problem not for an imagined one.

 Besides, it is not good style to still complain about "official 
 D" if you are happy with your fork.


 Even javascript has private to the class.


 Because monkey see monkey do.


 D is comlete joke! i.e. ..>  that you cannot even make a


 private member

 within a class (except through some stupid 'workaround').


 That kind of thought comes from cargo cult. Your interpretation 
 of "cannot" shows a misunderstanding: D's choice is by design.


 So with that...back on to topic.. YES 'offical' D really IS


 that bad!

 Then forkit!


 (but not my version of D ;-)


 Just don't continue trolling then. Be grateful.


 btw. This is not really a complaint ;-)


 There is only one definition left then: trolling.


 It's great that I can create my own fork based on someone


 else work (to

 do what I can do in anyother langauge, including javascript!).


 I am not jealous. Email me when private-to-class will ever be 
 really useful to you.

 Ali


You always accuse people of trolling for some reason??

I understand group/tribal psychology very well, so i can excuse 
you're comments.

But for the record, my post clearly states it was not a 
complaint, that I was expressing an opionion in relation to the 
topic of this thread, and that I am grateful for being able to 
build (fork) on someone elses work.

So go ahead. Highjack my comment and make me out to be a troll.

But you only make yourself, and the D 'tribe', look bad when you 
do so.

The topic of the thread is 'Is D really that bad' (not 'Express 
and opinion so we can call you a troll').
Nov 02 2022
next sibling parent Jordan Wilson <wilsonjord gmail.com> writes:
On Wednesday, 2 November 2022 at 20:13:59 UTC, UmmReally wrote:

 On Wednesday, 2 November 2022 at 18:02:11 UTC, Ali Çehreli 
 wrote:

 On 11/2/22 00:19, UmmReally wrote:

 [...]


 wrote:

 [...]




 brotown.

 [...]


 not

 [...]


 A workaround is for a real problem not for an imagined one.

 Besides, it is not good style to still complain about 
 "official D" if you are happy with your fork.


 [...]


 Because monkey see monkey do.


 [...]


 private member

 [...]


 That kind of thought comes from cargo cult. Your 
 interpretation of "cannot" shows a misunderstanding: D's 
 choice is by design.


 [...]


 that bad!

 Then forkit!


 [...]


 Just don't continue trolling then. Be grateful.


 [...]


 There is only one definition left then: trolling.


 [...]


 else work (to

 [...]


 I am not jealous. Email me when private-to-class will ever be 
 really useful to you.

 Ali


 You always accuse people of trolling for some reason??

 I understand group/tribal psychology very well, so i can excuse 
 you're comments.

 But for the record, my post clearly states it was not a 
 complaint, that I was expressing an opionion in relation to the 
 topic of this thread, and that I am grateful for being able to 
 build (fork) on someone elses work.

 So go ahead. Highjack my comment and make me out to be a troll.

 But you only make yourself, and the D 'tribe', look bad when 
 you do so.

 The topic of the thread is 'Is D really that bad' (not 'Express 
 and opinion so we can call you a troll').


The statement that D is a "complete joke" and "YES 'offical' D 
really IS that bad" due to D's module level encapsulation is 
quite extreme to the point where one can reasonably wonder if it 
is indeed trolling, particular if combined with mild mockery 
("he'll consider it...but 'private to the class'...never!"), and 
in light of previous history of communications (even Username 
choices).

Jordan
Nov 02 2022
prev sibling parent =?UTF-8?Q?Ali_=c3=87ehreli?= <acehreli yahoo.com> writes:
On 11/2/22 13:13, UmmReally wrote:

 On Wednesday, 2 November 2022 at 18:02:11 UTC, Ali Çehreli wrote:

 On 11/2/22 00:19, UmmReally wrote:





 D is comlete joke! i.e. ..>  that you cannot even make a


 private member

 within a class (except through some stupid 'workaround').







 YES 'offical' D really IS


 that bad!





 You always accuse people of trolling for some reason??


It's because people do troll.


 Highjack my comment and make me out to be a troll.


Please just look up the meaning of trolling in your favorite dictionary. 
Here is one:

   https://www.merriam-webster.com/dictionary/troll

Especially 2.a: "to antagonize (others) online by deliberately posting 
inflammatory, irrelevant, or offensive comments or other disruptive 
content".

My advice to anyone who doesn't like being called a troll is simply to 
not troll.

Ali
Nov 02 2022
prev sibling parent reply UmmReally <UmmReally gmail.com> writes:
On Wednesday, 2 November 2022 at 18:02:11 UTC, Ali Çehreli wrote:

 On 11/2/22 00:19, UmmReally wrote:

 On Wednesday, 2 November 2022 at 04:48:23 UTC, surlymoor


 wrote:

 Just have a module with the class in it and nothing more,




 brotown.

 I'll bill you my consultation fees later.


 In my version of D (a fork based on someone elses work), I am


 not

 'forced' to use that 'workaround'.


 A workaround is for a real problem not for an imagined one.

 Besides, it is not good style to still complain about "official 
 D" if you are happy with your fork.


 Even javascript has private to the class.


 Because monkey see monkey do.


Mmm... javascript... the most widely used language in the world, 
used on 95% (?)of all websites, by 16+ million developers...

That makes for a lot of monkeys.
Nov 02 2022
parent reply =?UTF-8?Q?Ali_=c3=87ehreli?= <acehreli yahoo.com> writes:
On 11/2/22 13:38, UmmReally wrote:

 On Wednesday, 2 November 2022 at 18:02:11 UTC, Ali Çehreli wrote:

 On 11/2/22 00:19, UmmReally wrote:





 Even javascript has private to the class.


 Because monkey see monkey do.


 Mmm... javascript... the most widely used language in the world, used on
 95% (?)of all websites, by 16+ million developers...

 That makes for a lot of monkeys.


Those 16+ million developers are not the designers of Javascript; they 
just use it. The reason Javascript has private-to-class is because other 
languages had that before Javascript was created in 1995.

Ali
Nov 02 2022
parent reply Max Samukha <maxsamukha gmail.com> writes:
On Wednesday, 2 November 2022 at 21:17:22 UTC, Ali Çehreli wrote:


 Those 16+ million developers are not the designers of 
 Javascript; they just use it. The reason Javascript has 
 private-to-class is because other languages had that before 
 Javascript was created in 1995.

 Ali


The millions of lemmings might be right in this case. There seems 
to be no good reason to think module-level is superior to 
class-level. It is definitely surprising and annoying to a lot of 
programmers coming from class-based OOP languages.
Nov 02 2022
next sibling parent reply =?UTF-8?Q?Ali_=c3=87ehreli?= <acehreli yahoo.com> writes:
On 11/2/22 21:54, Max Samukha wrote:

 On Wednesday, 2 November 2022 at 21:17:22 UTC, Ali Çehreli wrote:


 Those 16+ million developers are not the designers of Javascript; they
 just use it. The reason Javascript has private-to-class is because
 other languages had that before Javascript was created in 1995.

 Ali


 The millions of lemmings might be right in this case. There seems to be
 no good reason to think module-level is superior to class-level.


Yes: Just like there is no reason class-level is superior to 
module-level. There are pros and cons to both. For example, module-level 
is better because it obviates the need for the 'friend' keyword.


 It is
 definitely surprising


Yes, a new language can be surprising in many ways.


 and annoying


That's harsh and subjective... That can't be a reason to complicate the 
language. In my case, I fully embraced module-level private as a net 
win. If I am not alone, it is proof there are also programmers that 
think otherwise.


 to a lot of programmers coming from
 class-based OOP languages.


I welcome all of them and invite them to realize that they want (not 
"need") class-level private just because they are used to it.

Ali
Nov 02 2022
parent reply UmmReally <UmmReally gmail.com> writes:
On Thursday, 3 November 2022 at 05:29:22 UTC, Ali Çehreli wrote:

 On 11/2/22 21:54, Max Samukha wrote:

 On Wednesday, 2 November 2022 at 21:17:22 UTC, Ali Çehreli


 wrote:

 Those 16+ million developers are not the designers of




 Javascript; they

 just use it. The reason Javascript has private-to-class is




 because

 other languages had that before Javascript was created in




 1995.

 Ali


 The millions of lemmings might be right in this case. There


 seems to be

 no good reason to think module-level is superior to


 class-level.

 Yes: Just like there is no reason class-level is superior to 
 module-level. There are pros and cons to both. For example, 
 module-level is better because it obviates the need for the 
 'friend' keyword.


Well, my version of D has private to the class. I do not use 
friends.

So you argument is wrong.

What you (always) do, is make it out to be one or the other.

I have both private to the class, and private to the module, in 
my version of D.

Please STOP making it an argument for one or the other.

How about D letting the programmer make the choice.



 It is
 definitely surprising


 Yes, a new language can be surprising in many ways.


Especially when such an important type as the 'class' has no 
concept of privacy within a module (not even an option). No 
wonder people as suprised. You expect them not to be??


 That's harsh and subjective... That can't be a reason to 
 complicate the language. In my case, I fully embraced 
 module-level private as a net win. If I am not alone, it is 
 proof there are also programmers that think otherwise.


 to a lot of programmers coming from
 class-based OOP languages.


 I welcome all of them and invite them to realize that they want 
 (not "need") class-level private just because they are used to 
 it.

 Ali


Again, my version (fork) of D allows me to use BOTH. Offical D 
does not.

Why you so against people having a choice to do in D, what they 
can do in any other major programming language? I don't get it. 
Maybe it's you trolling us?
Nov 02 2022
next sibling parent rikki cattermole <rikki cattermole.co.nz> writes:
On 03/11/2022 6:57 PM, UmmReally wrote:

 Why you so against people having a choice to do in D.


You have the freedom to fork, which you have done.

You weren't the first, nor will you be the last to do so.

However this does not require us to upstream those changes and we are 
not convinced of your argument. This line of discussion is simply not 
fruitful and you are not being limited in what your fork does, please 
move on from this.
Nov 02 2022
prev sibling next sibling parent Mike Parker <aldacron gmail.com> writes:
On Thursday, 3 November 2022 at 05:57:57 UTC, UmmReally wrote:


 Why you so against people having a choice to do in D, what they 
 can do in any other major programming language? I don't get it. 
 Maybe it's you trolling us?


I'm happy for you that your private-to-the-class fork of dmd 
makes you happy, but your repeated derailing of threads under a 
variety of usernames isn't doing anyone any good. It certainly 
isn't going to convince anyone to change the behavior of private. 
So please, let's drop it in this thread.

Thanks!
Nov 02 2022
prev sibling parent reply zjh <fqbqrr 163.com> writes:
On Thursday, 3 November 2022 at 05:57:57 UTC, UmmReally wrote:

 Why you so against people having a choice to do in D, what they 
 can do in any other major programming language? I don't get it. 
 Maybe it's you trolling us?



Don't try to persuade them, they are stubborn.

This is also the reason why the `D` community is so small.
Nov 02 2022
parent zjh <fqbqrr 163.com> writes:
On Thursday, 3 November 2022 at 06:42:55 UTC, zjh wrote:

 On Thursday, 3 November 2022 at 05:57:57 UTC, UmmReally wrote:

 Why you so against people having a choice to do in D, what 
 they can do in any other major programming language? I don't 
 get it. Maybe it's you trolling us?





 This is also the reason why the `D` community is so small.



`GC` can be an option, but it is a must.
So 'D' missed its time! The price it pays for it is `unique vast`!
Nov 02 2022
prev sibling next sibling parent reply Walter Bright <newshound2 digitalmars.com> writes:
On 11/2/2022 9:54 PM, Max Samukha wrote:

 The millions of lemmings might be right in this case. There seems to be no
good 
 reason to think module-level is superior to class-level. It is definitely 
 surprising and annoying to a lot of programmers coming from class-based OOP 
 languages.


The biggest class based language (Java) does not allow more than one class in a 
module, so the issue is moot.

Therefore, when writing code in Java-style, this won't be an issue, either.
Nov 03 2022
next sibling parent reply "H. S. Teoh" <hsteoh qfbox.info> writes:
On Thu, Nov 03, 2022 at 06:13:13PM -0700, Walter Bright via Digitalmars-d wrote:

 On 11/2/2022 9:54 PM, Max Samukha wrote:

 The millions of lemmings might be right in this case. There seems to
 be no good reason to think module-level is superior to class-level.
 It is definitely surprising and annoying to a lot of programmers
 coming from class-based OOP languages.


 
 The biggest class based language (Java) does not allow more than one
 class in a module, so the issue is moot.


[...]

That's not entirely accurate. Java allows multiple classes in a module,
provided only one of them is a public class. You can have an arbitrary
number of private and nested classes within a single module.


T

-- 
The problem with the world is that everybody else is stupid.
Nov 03 2022
parent reply Walter Bright <newshound2 digitalmars.com> writes:
On 11/3/2022 8:24 PM, H. S. Teoh wrote:

 Java allows multiple classes in a module,
 provided only one of them is a public class. You can have an arbitrary
 number of private and nested classes within a single module.


That "one public class" is the module.
Nov 04 2022
parent reply rikki cattermole <rikki cattermole.co.nz> writes:
On 05/11/2022 3:09 AM, Walter Bright wrote:

 On 11/3/2022 8:24 PM, H. S. Teoh wrote:

 Java allows multiple classes in a module,
 provided only one of them is a public class. You can have an arbitrary
 number of private and nested classes within a single module.


 
 That "one public class" is the module.


Just so ugh we keep things to the correct terminology (for other readers):

Java has modules. They are not mapped to a file. The above is regarding 
files not (Java) modules.

https://en.wikipedia.org/wiki/Java_Platform_Module_System
Nov 04 2022
parent reply 12345swordy <alexanderheistermann gmail.com> writes:
On Friday, 4 November 2022 at 14:13:59 UTC, rikki cattermole 
wrote:

 On 05/11/2022 3:09 AM, Walter Bright wrote:

 On 11/3/2022 8:24 PM, H. S. Teoh wrote:

 Java allows multiple classes in a module,
 provided only one of them is a public class. You can have an 
 arbitrary
 number of private and nested classes within a single module.


 
 That "one public class" is the module.


 Just so ugh we keep things to the correct terminology (for 
 other readers):

 Java has modules. They are not mapped to a file. The above is 
 regarding files not (Java) modules.

 https://en.wikipedia.org/wiki/Java_Platform_Module_System


Which honestly, that should be even more of an indicator that D 
should drop the one module per file restriction, and allow 
multiple modules in a single file.

- Alex
Nov 05 2022
next sibling parent rikki cattermole <rikki cattermole.co.nz> writes:
On 06/11/2022 5:23 AM, 12345swordy wrote:

 Which honestly, that should be even more of an indicator that D should 
 drop the one module per file restriction, and allow multiple modules in 
 a single file.


Not at all.

Its an entirely different concept and has to do with distribution rather 
than the programming language itself.
Nov 05 2022
prev sibling parent reply Dukc <ajieskola gmail.com> writes:
On Saturday, 5 November 2022 at 16:23:34 UTC, 12345swordy wrote:

 Java has modules. They are not mapped to a file. The above is 
 regarding files not (Java) modules.

 https://en.wikipedia.org/wiki/Java_Platform_Module_System


 Which honestly, that should be even more of an indicator that D 
 should drop the one module per file restriction, and allow 
 multiple modules in a single file.


I like the D system. We sort the code to files with similar logic 
way we sort it to namespaces anyway. Having to add a namespace 
block that encompasses the whole file to every single of them is 
just annoying for no good reason.

Now I wouldn't mind if there was a way to have in-file modules in 
addition to a file being a module (though I'd question if the 
additional complexity is justified), but if I have to pick one or 
the other I prefer the D system hands down.
Nov 05 2022
next sibling parent reply Walter Bright <newshound2 digitalmars.com> writes:
On 11/5/2022 2:26 PM, Dukc wrote:

 I like the D system. We sort the code to files with similar logic way we sort
it 
 to namespaces anyway. Having to add a namespace block that encompasses the
whole 
 file to every single of them is just annoying for no good reason.
 
 Now I wouldn't mind if there was a way to have in-file modules in addition to
a 
 file being a module (though I'd question if the additional complexity is 
 justified), but if I have to pick one or the other I prefer the D system hands 
 down.


Using the module as the fundamental unit of encapsulation and making it a 1:1 
correspondence with files is a good fit for modern filesystems. (Old
filesystems 
were so slow most people would try to cram a program into a small number of
files.)

Divorcing modules from file names makes for clumsy, hackish attempts solutions 
to figuring out which file a particular module resides in.
Nov 05 2022
next sibling parent rikki cattermole <rikki cattermole.co.nz> writes:
On 06/11/2022 2:56 PM, Walter Bright wrote:

 Using the module as the fundamental unit of encapsulation and making it 
 a 1:1 correspondence with files is a good fit for modern filesystems. 
 (Old filesystems were so slow most people would try to cram a program 
 into a small number of files.)


We do have this handy dandy little assumption in our design however:

``foo\bar.d(1): Error: package name 'foo' conflicts with usage as a 
module name in file foo.d``

```
.
├── entry.d
├── foo
│   └── bar.d
└── foo.d
```

It does mean we can place multiple modules in a file as long as only one 
of them is the root.

```d
module root;

module root.foo {

}
```
Nov 05 2022
prev sibling next sibling parent TTK Ciar <ttk ciar.org> writes:
On Sunday, 6 November 2022 at 01:56:34 UTC, Walter Bright wrote:

 Divorcing modules from file names makes for clumsy, hackish 
 attempts solutions to figuring out which file a particular 
 module resides in.


Perl modules make for a good compromise -- when a module needs to 
be found, it's a 1:1 correlation to filename, but for modules 
referred to within the file, there is no such requirement.

That having been said, I can count on my fingers the number of 
times I've actually used multiple modules per file, and won't 
miss them writing D.
Nov 07 2022
prev sibling parent 12345swordy <alexanderheistermann gmail.com> writes:
On Sunday, 6 November 2022 at 01:56:34 UTC, Walter Bright wrote:


 Divorcing modules from file names makes for clumsy, hackish 
 attempts solutions to figuring out which file a particular 
 module resides in.


That is why build systems such as makefile exist for a very good 


- Alex
Nov 08 2022
prev sibling parent reply CM <celestialmachinist proton.me> writes:
On Saturday, 5 November 2022 at 21:26:16 UTC, Dukc wrote:

 [...]


Yeah, one of my favorite features of D is its module system, 
especially coming from C. Now if only we could have module 
templates to further my ML-D fantasy.
Nov 05 2022
parent reply Tejas <notrealemail gmail.com> writes:
On Sunday, 6 November 2022 at 03:37:13 UTC, CM wrote:

 On Saturday, 5 November 2022 at 21:26:16 UTC, Dukc wrote:

 [...]


 Yeah, one of my favorite features of D is its module system, 
 especially coming from C. Now if only we could have module 
 templates to further my ML-D fantasy.


`mixin template`  doesn't scratch that itch?
Nov 05 2022
parent CM <celestialmachinist proton.me> writes:
On Sunday, 6 November 2022 at 04:50:18 UTC, Tejas wrote:

 On Sunday, 6 November 2022 at 03:37:13 UTC, CM wrote:

 On Saturday, 5 November 2022 at 21:26:16 UTC, Dukc wrote:

 [...]


 Yeah, one of my favorite features of D is its module system, 
 especially coming from C. Now if only we could have module 
 templates to further my ML-D fantasy.


 `mixin template`  doesn't scratch that itch?


I do indeed use other kinds of aggregate templates, and they're a 
fine workaround; Nonetheless, module templates would be nicer, 
though hardly important given other matters. Because—y'know—I 
could just use an ML.
Nov 05 2022
prev sibling parent Max Samukha <maxsamukha gmail.com> writes:
On Friday, 4 November 2022 at 01:13:13 UTC, Walter Bright wrote:

 On 11/2/2022 9:54 PM, Max Samukha wrote:

 The millions of lemmings might be right in this case. There 
 seems to be no good reason to think module-level is superior 
 to class-level. It is definitely surprising and annoying to a 
 lot of programmers coming from class-based OOP languages.


 The biggest class based language (Java) does not allow more 
 than one class in a module, so the issue is moot.





 Therefore, when writing code in Java-style, this won't be an 
 issue, either.


Every quirk has a workaround.
Nov 03 2022
prev sibling parent reply razyk <user home.org> writes:
On 03.11.22 05:54, Max Samukha wrote:

 
 The millions of lemmings might be right in this case. There seems to be 
 no good reason to think module-level is superior to class-level. It is 
 definitely surprising and annoying to a lot of programmers coming from 
 class-based OOP languages.


FWIW Delphi added "strict private" and "strict protected".
Nov 05 2022
next sibling parent reply Walter Bright <newshound2 digitalmars.com> writes:
On 11/5/2022 9:52 AM, razyk wrote:

 FWIW Delphi added "strict private" and "strict protected".


D will go one better:

   "private IReallyMeanItThisTime"
Nov 05 2022
parent razyk <user home.org> writes:
On 06.11.22 05:53, Walter Bright wrote:

 On 11/5/2022 9:52 AM, razyk wrote:

 FWIW Delphi added "strict private" and "strict protected".


 
 D will go one better:
 
    "private IReallyMeanItThisTime"


It was "Delphi 7" before.
Nov 06 2022
prev sibling parent Max Samukha <maxsamukha gmail.com> writes:
On Saturday, 5 November 2022 at 16:52:57 UTC, razyk wrote:

 FWIW Delphi added "strict private" and "strict protected".


Nice!

Honestly, I don't care much. I would prefer "private" to 
consistently mean "private to this scope". Given that languages 
like Python are doing well without any access attributes, we 
could just leave it as is.
Nov 06 2022
prev sibling parent reply Dukc <ajieskola gmail.com> writes:
On Monday, 31 October 2022 at 19:52:42 UTC, Walter Bright wrote:

 On 10/31/2022 5:47 AM, zjh wrote:

 `D` needs a reasonable `todo` list with `priority` !.


 The thing is, we don't assign people tasks from a list. People 
 work on what they want to work on. Sponsors can fund specific 
 tasks they need done.


Plus, there already is a task list for whoever wants ideas. Two 
in fact, depending on what sort of list you're looking for. 
Bugzilla, and [the project 
board](https://github.com/orgs/dlang/projects?query=is%3Aopen) 
our pull request managers recently opened.
Oct 31 2022
parent Imperatorn <johan_forsberg_86 hotmail.com> writes:
On Monday, 31 October 2022 at 21:58:59 UTC, Dukc wrote:

 On Monday, 31 October 2022 at 19:52:42 UTC, Walter Bright wrote:

 On 10/31/2022 5:47 AM, zjh wrote:

 `D` needs a reasonable `todo` list with `priority` !.


 The thing is, we don't assign people tasks from a list. People 
 work on what they want to work on. Sponsors can fund specific 
 tasks they need done.


 Plus, there already is a task list for whoever wants ideas. Two 
 in fact, depending on what sort of list you're looking for. 
 Bugzilla, and [the project 
 board](https://github.com/orgs/dlang/projects?query=is%3Aopen) 
 our pull request managers recently opened.


That's good!

Btw, got to think about this regarding D "are we there yet"

I bet Walter feels like this sometimes when asked about D:
https://youtu.be/Pt9Bmc7hnuc
Nov 01 2022
prev sibling parent zjh <fqbqrr 163.com> writes:
On Monday, 31 October 2022 at 12:47:22 UTC, zjh wrote:


 There are too many things to do. `D` need to arrange them 
 reasonably!


Here is an 
[article](https://fqbqrr.blog.csdn.net/article/details/109110021) 
written by a Russian on `why you should choose D`. The original 
text has been lost.This is a `Russian` to `Chinese` version. It 
should be able to translate into English with `google translate`.
Oct 31 2022
prev sibling parent reply Bioinfornatics <bioinfornatics fedoraproject.org> writes:
On Monday, 31 October 2022 at 12:20:10 UTC, IGotD- wrote:

 On Monday, 31 October 2022 at 12:10:15 UTC, zjh wrote:

 D is a `center` language . It `competes` with all languages. 
 Therefore, it has higher requirements!
 `GC` cannot support it to survive in the intense competition.


 Modern languages have more support for asynchronous and 
 multithreaded programming than ever. You simply cannot have a 
 stop the world GC in such environments in order to be 
 competitive.


Nowaday IT industry want to be productive
That is why in 2000's many people used Ruby
That is why in 2020 they are lot of developpement in
+ JavaScript/typescript
  - one language for the backend and the frontend
+ Python a multipurpose language
  - backend
  - Datascience
Those popular language hide the memory management complexity

With the growth of python community. More and more people are not 
satisfied as python is too slow. That is why Microsoft spend so 
many ressources to get a faster python. To get the productivity 
without to be too slow.

C/Go/rust aime to be a system language this market is really 
small.
People want to produce something easily with a good performance. 
That is the spirit of D.

And yes we know that most of Rust peoples use ut it only because 
it is popular. As it is popular more people want to try. Now they 
start to write teir python library in Rust.

That is why the market is here with a GC. Thus D have to provides 
those libraries:
+ Datascience
+ Backend such as fastapi (why vibe.d is not becomz popular)
+ Full featured wasm library writen in D (one language for the 
backend and the frontend)
Oct 31 2022
parent jmh530 <john.michael.hall gmail.com> writes:
On Monday, 31 October 2022 at 16:27:48 UTC, Bioinfornatics wrote:

 [snip]

 Nowaday IT industry want to be productive
 That is why in 2000's many people used Ruby
 That is why in 2020 they are lot of developpement in
 + JavaScript/typescript
  - one language for the backend and the frontend
 + Python a multipurpose language
  - backend
  - Datascience
 Those popular language hide the memory management complexity

 [snip]


I agree with a lot of this, but remember that it takes people to 
do these things. They don't just fall out of the sky.
Oct 31 2022
prev sibling next sibling parent SealabJaster <sealabjaster gmail.com> writes:
On Friday, 28 October 2022 at 09:51:04 UTC, Imperatorn wrote:

 Is D really that bad?


It's far from bad but far from perfect :)

My own personal annoyances with D are:

* Subpar support for  nogc code. I don't quite know why but I've 
really taken a liking to writing in  nogc, and I'm very very 
slowly writing my own library to handle some things, but it's 
kinda sad we don't even have  nogc containers in Phobos.

I'm not a GC hater btw, and I like how simple it can be to reason 
about D's GC.

* Poor ecosystem. I know we can tap into the vast landscape of C, 
but I'd rather a nice native D API instead (or D wrapper). 
Strangely, I don't really feel any real motivation now to share 
my code, especially on dub, so I mostly just write things for 
myself to use.

I want to improve things myself, and I've had some fun ideas in 
mind, but time; effort, and increasing disinterest in the 
language outside my own little bubble, is kinda stopping that.

* The 'fashion' of stuffing things into library solutions instead 
of adding it into the language. I _love_ what we can achieve in D 
via its native prowess for metaprogramming, but it kinda falls 
flat on its face at times.

For example, with pattern matching for SumType, having an error 
in your match handlers can be very... interesting to debug; 
likely has much more impact on compile times than a native 
language solution, and I've been meaning to measure what the name 
mangling for symbols that end up in the resulting binary is like 
for more extensive usage of sum types.


makes code feel more expressive to me.

* The impossible situation we're cornered into when it comes to 
discussing adding things directly into the language: Should it be 
 gc?  nogc? both? exceptions? support the newer safety fetures? 
how can we shoe horn it into a library instead? etc. etc.

String interpolation is my favourite example of this.

* A general lack of vision. Honestly I don't really know what D 
wants to be or achieve, and I find it hard for my personal usages 
at the moment due to things like a lack of a solid AWS SDK. It's 
a language for everyone and everything yet also no one and 
nothing at the same time.

* Tooling not being terribly great compared to other languages.

Still though, there's no other language I love using more than 
this one, even if I personally can't see much of a future for it 
anymore :)

idk, it's weird because in some ways I've kinda given up hope 
with D, but I still want to use it because nothing else I've 
tried really compares in terms of expressiveness and 
metaprogramming. I have to use Go a lot for work, and even with 
generics I'm just begging for even simple templating that D has 
instead of generics ;-;
Nov 01 2022
prev sibling next sibling parent reply ryuukk_ <ryuukk.dev gmail.com> writes:
Hijacking this thread since there seems to be lot of energy 
available here

It would be cool if someone could take care of that issue: 
https://forum.dlang.org/thread/lxnogwxpuiwlxvruqlrs forum.dlang.org

It's pretty concerning that this more than 1 year old bug still 
exist, quite dangerous bug
Nov 01 2022
next sibling parent "H. S. Teoh" <hsteoh qfbox.info> writes:
On Tue, Nov 01, 2022 at 09:31:09PM +0000, ryuukk_ via Digitalmars-d wrote:

 Hijacking this thread since there seems to be lot of energy available
 here
 
 It would be cool if someone could take care of that issue:
 https://forum.dlang.org/thread/lxnogwxpuiwlxvruqlrs forum.dlang.org
 
 It's pretty concerning that this more than 1 year old bug still exist,
 quite dangerous bug


Are you referring to this issue?

	https://issues.dlang.org/show_bug.cgi?id=22583

I just tested it, dmd shows the bug, but ldc2 generates correct code.
Looks like a DMD backend bug.  I'm looking at the dmd generated asm
right now to see what's going on... looks like it has something to do
with passing floats via the xmm* registers that somehow got mixed up
between caller/callee.

Once I have a clearer idea I'll update the bug.  DMD backend is beyond
my depth, though. Black magic happens there and I don't have the
time/patience to figure it all out.


T

-- 
Music critic: "That's an imitation fugue!"
Nov 01 2022
prev sibling next sibling parent Imperatorn <johan_forsberg_86 hotmail.com> writes:
On Tuesday, 1 November 2022 at 21:31:09 UTC, ryuukk_ wrote:

 Hijacking this thread since there seems to be lot of energy 
 available here

 It would be cool if someone could take care of that issue: 
 https://forum.dlang.org/thread/lxnogwxpuiwlxvruqlrs forum.dlang.org

 It's pretty concerning that this more than 1 year old bug still 
 exist, quite dangerous bug


How is that dangerous though?
Nov 01 2022
prev sibling parent reply Walter Bright <newshound2 digitalmars.com> writes:
On 11/1/2022 2:31 PM, ryuukk_ wrote:

 Hijacking this thread since there seems to be lot of energy available here
 
 It would be cool if someone could take care of that issue: 
 https://forum.dlang.org/thread/lxnogwxpuiwlxvruqlrs forum.dlang.org
 
 It's pretty concerning that this more than 1 year old bug still exist, quite 
 dangerous bug


If bugs aren't reported to https://issues.dlang.org they're pretty much 
guaranteed to be overlooked and forgotten. The forums make for a terrible bug 
database.
Nov 01 2022
parent reply Tejas <notrealemail gmail.com> writes:
On Wednesday, 2 November 2022 at 01:04:03 UTC, Walter Bright 
wrote:

 On 11/1/2022 2:31 PM, ryuukk_ wrote:

 Hijacking this thread since there seems to be lot of energy 
 available here
 
 It would be cool if someone could take care of that issue: 
 https://forum.dlang.org/thread/lxnogwxpuiwlxvruqlrs forum.dlang.org
 
 It's pretty concerning that this more than 1 year old bug 
 still exist, quite dangerous bug


 If bugs aren't reported to https://issues.dlang.org they're 
 pretty much guaranteed to be overlooked and forgotten. The 
 forums make for a terrible bug database.


It's already been reported

If you clicked that link, you'd have seen two bug reports:

https://issues.dlang.org/show_bug.cgi?id=23450

https://issues.dlang.org/show_bug.cgi?id=22583
Nov 01 2022
parent Walter Bright <newshound2 digitalmars.com> writes:
On 11/1/2022 7:21 PM, Tejas wrote:

 It's already been reported


Good.
Nov 02 2022
prev sibling parent Imperatorn <johan_forsberg_86 hotmail.com> writes:
On Friday, 28 October 2022 at 09:51:04 UTC, Imperatorn wrote:

 Hi guys,

 Just wanted to remind you that, D maybe isn't that bad.

 [...]


Summary for new users:

D rox
Nov 03 2022