December 15, 2020
On Tuesday, 15 December 2020 at 09:11:26 UTC, Paulo Pinto wrote:
> On Tuesday, 15 December 2020 at 08:13:31 UTC, Dylan Graham wrote:
>> On Sunday, 13 December 2020 at 20:35:15 UTC, H. S. Teoh wrote:
>>> On Sun, Dec 13, 2020 at 07:33:30PM +0000, Max Haughton via Digitalmars-d wrote: [...]
>>>> I really think properly killing the GC would give us a big boost in fresh blood to the community. It would still be there, but it's a huge turn off to new users.
>>>
>>> Honestly, IMNSHO the anti-GC crowd is only a vocal minority.  For most normal applications the GC is actually a big plus.
>>
>>
>> D's biggest problem are those trying to turn it into C++.
>
> With the irony that most prominent C++ game engines, and OS component frameworks, do use some form of automatic memory management.

But not usually a stop-the-world one like we have.
December 15, 2020
On Tuesday, 15 December 2020 at 10:33:21 UTC, Paulo Pinto wrote:
> On Tuesday, 15 December 2020 at 09:31:40 UTC, Araq wrote:
>> On Tuesday, 15 December 2020 at 09:11:26 UTC, Paulo Pinto wrote:
>>> With the irony that most prominent C++ game engines, and OS component frameworks, do use some form of automatic memory management.
>>
>> None of these systems confuses GC'ed with non GC'ed pointers. C++ for all its warts doesn't have this flaw.
>
> That I agree, but the problem isn't with the GC, rather the implementation thereof.
>
> Probably the easiest way for D not to break (much) code would be to keep all pointers as GC pointers by default, and non-GC pointers would be the ones marked with @system.
>
> This isn't a novelty, and follows a design similar to other system languages with GC support.

It would be more fruitful to annotate non-GC code i.e. it would need to be subject to ownership checking, which will require annotation to interact with existing D semantics (specifically for interprocedural analysis)
December 15, 2020
On Monday, 14 December 2020 at 19:42:41 UTC, aberba wrote:
> On Sunday, 13 December 2020 at 23:08:05 UTC, IGotD- wrote:
>> On Sunday, 13 December 2020 at 22:53:31 UTC, Paul Backus wrote:
>>>
>>> It's easy to sit around in our armchairs pontificating about how, if only "the D community" (read: someone else) would do X, Y, or Z, all of our problems would be solved.
>>>
>>> It's harder, but ultimately much more rewarding, to roll up one's sleeves and actually make a positive contribution.
>>
>> This is not a one man job which someone can make a neat preview of. It's a decision that has to be made from the maintainers so that several people can start working with such a big task. Also documenting what needs to be done. This ties into the original post with the blog post, that the D project has problems with rallying people towards a common goal (which today is very vague).
>>
>> People starting to add and change things randomly and then hoping that it will be accepted and be merged isn't really a good way to run a project.
>
> Very well put.
>
> The main point of my post is that "What needs to be done" isn't documented so unless you've spent some time in the community to identify the issues out of experience or see them as they pop up here in the forum.
>
> Hence D needs a Project Manager in addition to the PR Manager (wait what happened to the PR manager?). I know devs don't like project managers but the absence of such a person might not speak well to certain companies/individuals looking to invest in D (even if they like it). Isn't that one of the reasons why we have a foundation in the first place? Without knowing the high-level roadmap or core language priorities, what's there to invest in? What about those looking for interesting problems for their thesis? New volunteers?
>
> BeerConf has created room for community members to chat and discuss D issues, and some ideas/mobilization has come from that. It's a similar thing for why there needs to be a roadmap or (at least) a priority list of some kind.
>

The project management stuff is totally true. I have been following D for like 15 years (I think) and D seems to have a permanent identity crisis. Set the priority and stick to it and give confidence. Yes, do it: refuse big stuff that does not fullfill thr goal. Do it. Even if someone gets pissed.

 In fact, even if D has a lot of nice things and is technically nice, it has a lack of vision. However, what I see here is people throwing random ideas as it has always happened. Like this, I think D goes nowhere. It is a pitty bc it has potential. But discussing and throwing random PRs is not going to cut it. Decisions need to be taken. For example (not a proposal at all): memory safety with live, RC, optional GC and the superior tool for GUI and server-side backend. Once decided, stick to it. Any language I have seen that is successful has direction: Go, Rust... even Nim looks more convinced of where they are heading. This kind of discussions are not going to fix anything. It is a let us talk what comes from the top off my head with zero direction permanently. Better to get serious surveys (I say this because since I started  to follow D, it is a perpetual thing that every once in a short while a post liie this arises. Energy that couldu probably be spent in setting direction (namely, taking decisions) and executing.

I know it is easy to critizice without doing anything but I have a severe lack of free time at this point. Just my two cents.

> Individualism simply isn't going to cut it.


December 15, 2020
On Sunday, 13 December 2020 at 19:33:30 UTC, Max Haughton wrote:
> I really think properly killing the GC would give us a big boost in fresh blood to the community. It would still be there, but it's a huge turn off to new users. That and a bit of blog-spam, I constantly see articles for new languages that are (frankly) a bit rubbish compared to various D features but because they are post-(new generation of languages) they are "cooler"

many langs has GC. nobody complains.
D looks weird.
D is simpler and more difficult than C++ at the same time.
  D-templates, alias, UFCS, ranges makes it simpler.
  life/ref/pure/nogc/trusted/safe, lambdas with no captures by value, pragma(inline) (I have still "WTF?", why nogc/safe is attr but inline is foreign-pragma?) - are complicated. Phobos code looks almost same as autogenerated STL code.

D dont want try to use
- write-barrier with GC
- move to LLVM as base.
  u dont need f*ck with x86 asm and register allocations, u already have half-done interop with many langs that also used LLVM, u can generate LLVM-IR, u can add dynamic compilation - generating proxies, parsers on the fly, using scripts without converting types AStringA<=>BString in same heap..
- tail lambdas that looks pretty in other langs.

nogc/safe.. - imo its context attr not function attr.
and for context pragma is OK.
when u accept this u can add new user contexts and say to compiler what is allowed/disallowed. and compiler can say what method u cannot to use in this context coz it used/invoke ->methodB->methodC->thatUseGC for example.
no need to dirty the methods.

with other lang using package-manager is first step that u tried.
for D u can use dub never and u are fine with ur CLI-utilities.

D is language for handmade crafts, not for enterprise.
when u will do lang for bloody-enterprise, than you've get money and people.
and betterC/nogc is not for enterprise, its for some thoughts about enterprise.

D is already very complicated for newbies.
if u cannot write program (something connect to http/grpc service) in a few hours than "f*ck it".
man need 4-12 months for learning D.
December 15, 2020
On Tuesday, 15 December 2020 at 17:45:20 UTC, a11e99z wrote:
> On Sunday, 13 December 2020 at 19:33:30 UTC, Max Haughton wrote:
>> I really think properly killing the GC would give us a big boost in fresh blood to the community. It would still be there, but it's a huge turn off to new users. That and a bit of blog-spam, I constantly see articles for new languages that are (frankly) a bit rubbish compared to various D features but because they are post-(new generation of languages) they are "cooler"
>
> my blahbalh

if u see problem in GC u can make
  RC-string,
  RC-array,
  RC-hashtable and
  RC-ptr
that will close 80% ur and newbies (as u think) needs.

string_impl {
   char* ptr; // -4 is RC
   int start, len;
};
u can use it as span too.
GC will left for lambdas only.

2..4 weeks job that will close 12+years talks.
December 16, 2020
On Tuesday, 15 December 2020 at 17:45:20 UTC, a11e99z wrote:

> D is already very complicated for newbies.
> if u cannot write program (something connect to http/grpc service) in a few hours than "f*ck it".
> man need 4-12 months for learning D.

From my personal experience, the complication comes because D libraries and compiler itself follows the "convention" over "contract" way (similar to the "convention" over "configuration" with ruby on rails :-) ).

Example:  Do you need to be equatable... then add an "opEquals" method to your class/struct (operator overload)... you don't need to implement the "IEquatable" or "IComparable" interface.

A first look to ranges libraries (it is really impressive) exposes that it is based on introspection (static/compile time  code), not on interfaces/contracts.  This makes it difficult for newbies to understand how it works because there is not a "contract" (an interface) explaining you what it does.   If you try to read de comments in the own library, it is oriented to doc generation:  it is extensive and thought for post processed documentation generation and really impossible (in my case) as a guidance to understand the function signature.  The only way to read this "comments" is navigating to dlang.org web and reading the generated documentation.

This gives the real power and weakness to D:   The missing contracts delegates to the compile-time static code the final real code generation... you need to compile to know if you are developing well, no interfaces/contracts can be used to guide you before this phase.  The problem is clean:  functions signature doesn't gives you enough information to understand what exactly it does and you need 4 or more months to acquire the knowledge (the intuition of the typical developer is not enough: you must work it to adapt)

It is like beginning with Functional programming:  you need to understand what it means before trying to write complex code... and D introduces a new paradigm itself for developers that usually works in "productive" more known ways.

Of course, when you change your way of thinking, D reveals it's real power:  *auto*, *alias*,... the same function can be applied to thinks that are not related.  It's magic? not: D doesn't use generics, it uses templates and templates are not generics.

Newbies need to understand this two main concepts:
* D is not based in contracts (it can, but it tries not to use):  Type resolution is more "introspection" based than declaration based.
* D has templates, NOT generics...



Final conclusion... look at this:

void main(){
  0.doThis!(n=>assert(n==0));
  assert( 0.doThis!(n=>n) == 0 );
  assert( "hello".doThis!(s=>s) == "hello" );
  assert( "hello".doThis!(s=>s.length) == 5 );
  assert( doThis!(u=>u)(true) );
}
auto doThis(alias f, T)(T value){
  // Nothing in the "alias f" tells you that it must be an unary function or
  // witch type must return...
  return f(value);
}

Someone coming from java or c# will suffer an aneurysm, but it is really... wonderful? :-)


December 16, 2020
On Wednesday, 16 December 2020 at 10:04:03 UTC, ddcovery wrote:
> On Tuesday, 15 December 2020 at 17:45:20 UTC, a11e99z wrote:
>
>> [...]
>
> From my personal experience, the complication comes because D libraries and compiler itself follows the "convention" over "contract" way (similar to the "convention" over "configuration" with ruby on rails :-) ).
>
> [...]

Consider that C++ has only just got template constraints (concepts), and they have been at the design stage, roughly, since I was born on to this earth.

We have template constraints already, we could have nicer template constraints as a fairly trivial library solution (composing them isn't hard), but ultimately more templates puts a lot of pressure on the compiler for not much benefit.
December 16, 2020
On Wednesday, 16 December 2020 at 10:04:03 UTC, ddcovery wrote:
> On Tuesday, 15 December 2020 at 17:45:20 UTC, a11e99z wrote:
>
>> [...]
>
> From my personal experience, the complication comes because D libraries and compiler itself follows the "convention" over "contract" way (similar to the "convention" over "configuration" with ruby on rails :-) ).
>
> [...]

I understood it as having to do with the lack of packages rather than their implementation details. However, with http/grpc, I think we already have dub packages for those...the hunt stuff. Never used them myself though.
December 16, 2020
On Wednesday, 16 December 2020 at 10:39:38 UTC, Max Haughton wrote:
> On Wednesday, 16 December 2020 at 10:04:03 UTC, ddcovery wrote:
>> On Tuesday, 15 December 2020 at 17:45:20 UTC, a11e99z wrote:
>>
>>> [...]
>>
>> From my personal experience, the complication comes because D libraries and compiler itself follows the "convention" over "contract" way (similar to the "convention" over "configuration" with ruby on rails :-) ).
>>
>> [...]
>
> Consider that C++ has only just got template constraints (concepts), and they have been at the design stage, roughly, since I was born on to this earth.
>
> We have template constraints already, we could have nicer template constraints as a fairly trivial library solution (composing them isn't hard), but ultimately more templates puts a lot of pressure on the compiler for not much benefit.

As a good friend told me 20 years ago: "strong typing allows you to see an application as a set of gears that fit together perfectly"... with templates, you don't know the shape of the gears until compiler tries to build them... this opens a lot of possibilities and introduces some problems.

Problem with "template constraints" is it tries to give a "declarative" vision of something that is solved imperatively  (if you generate a "isEquatable" constraint... you must generate imperative static code to check what "isEquatable" means) and this is a barrier for "intelligense" systems like VSCode plugins that helps developers to check it's code BEFORE it is compiled.  The plugin can't determine what "isEquatable" means and can't help you saying "Person class is not Equatable"... a template constraint is a "custom" blackbox that, semantically, doesn't associate language dependent declarative concepts (like inheritance or interfaces).  Correct me if I'm in an error... I am not really experienced D developer.

If you will work with D, you must be aware about this kind of "small" barriers.


December 16, 2020
On Wednesday, 16 December 2020 at 12:30:06 UTC, ddcovery wrote:
> On Wednesday, 16 December 2020 at 10:39:38 UTC, Max Haughton wrote:
>> [...]
>
> As a good friend told me 20 years ago: "strong typing allows you to see an application as a set of gears that fit together perfectly"... with templates, you don't know the shape of the gears until compiler tries to build them... this opens a lot of possibilities and introduces some problems.
>
> Problem with "template constraints" is it tries to give a "declarative" vision of something that is solved imperatively  (if you generate a "isEquatable" constraint... you must generate imperative static code to check what "isEquatable" means) and this is a barrier for "intelligense" systems like VSCode plugins that helps developers to check it's code BEFORE it is compiled.  The plugin can't determine what "isEquatable" means and can't help you saying "Person class is not Equatable"... a template constraint is a "custom" blackbox that, semantically, doesn't associate language dependent declarative concepts (like inheritance or interfaces).  Correct me if I'm in an error... I am not really experienced D developer.
>
> If you will work with D, you must be aware about this kind of "small" barriers.

Any hypothetical IDE could just use dmd to see if the template fits or not. You absolutely can equate this that or the other because the template constraints will (99% of the time) be a fairly shallow tree of decisions if not flat (they are technically unbounded but so is everything else).