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