On Tuesday, 16 November 2021 at 18:17:29 UTC, Rumbu wrote:
> At least from my point of view, it seems that recently D made a shift from a general purpose language to a C successor, hence the last efforts to improve betterC and C interop, neglecting other areas of the language.

Nothing can compete with C, in terms of being the layer just above assembly.

Many try. All fail.

Improving on D's capability to write and interop with low-level code, seems like a worthwhile exercise to me, as it expands the problem domains in which D can be used.

But that is a very different objective to being C's successor.

C will always B.

On Wed, Nov 17, 2021 at 01:06:57AM +0000, zjh via Digitalmars-d wrote:
> On Wednesday, 17 November 2021 at 00:55:33 UTC, H. S. Teoh wrote:
> 
> Thank you for reminding me. I don't know that point.
> However, suppose others are like me. As soon as they hear GC, they shake
> their heads and leave. What should we do?

What *can* we do?  Lie to them that there's no GC, and when they find out they leave *and* get angry that we lied to them?

You cannot argue with GC-phobia, it's an irrational fear. No amount of argument will change anything.  You cannot reason with the unreasonable; you lose by definition.


> How to expand D's user base?
> We should provide a way for users to never use `GC`, such as
> `embedded`, which is a good market. This is the territory of `C`.

Years ago, before @nogc was implemented, people were clamoring for it, saying that if we could only have the compiler enforce no GC use, hordes of C/C++ programmers would come flocking to us.

Today, we have @nogc implemented and working, and the hordes haven't come yet.

Now people are clamoring for ref-counting and getting rid of GC use in Phobos.  My prediction is that 10 years later, we will finally have ref-counting and Phobos will be @nogc, and the hordes of C/C++ programmers still will not come to us.


T

-- 
Never ascribe to malice that which is adequately explained by incompetence. -- Napoleon Bonaparte

On Wed, Nov 17, 2021 at 01:15:21AM +0000, zjh via Digitalmars-d wrote:
> On Wednesday, 17 November 2021 at 01:02:46 UTC, H. S. Teoh wrote:
> > We already can.  I have many projects that call C libraries (not so much C++ because of incompatibilities between C++ and D templates), and it works fine.
> 
> The abstraction of C is too raw. D needs the ability to own the whole standard library without GC, so as to survive under `low hardware conditions`.

Have you heard about -betterC? ;-)


> There are many C++ users, so you have to provide C++ binding.

The past few years Walter was busy implementing binding to C++ classes. I haven't kept up with the current status of that, but AFAIK it has been implemented to some extent.

I haven't seen the crowd of C++ programmers flocking to D yet.


> Now, there are many `Rust` users, and they may have to be binded. Their is mine. After all, the D user base is too small. You have to bind with others.

AFAIK, most Rust users are ex-C/C++ users.  If they have already chosen Rust over D, good luck convincing them to switch again.

D already has bindings for other languages.  The most important one is C, since that's the de facto baseline for basically every relevant OS out there these days.  C++ is partially supported (you have extern(C++) classes, dpp, etc.).  We have Java support (thanks to Adam's jni.d, which uses D's metaprogramming abilities to make it so nice to interface with Java that I was actually tempted to start using Java again!), and somebody wrote an Excel binding too.

Of course, these are in various states of polishedness, and probably could use more work to round out the experience.  It's easy to say "we need X, we need Y, we should do Z".  But talk doesn't make anything happen; what we have today is because *somebody* decided to actually write code to make it happen instead of posting suggestions to unending threads on the forum. ;-)


T

-- 
"Hi." "'Lo."

On Wed, Nov 17, 2021 at 01:23:38AM +0000, forkit via Digitalmars-d wrote: [...]
> Nothing can compete with C, in terms of being the layer just above assembly.
> 
> Many try. All fail.
> 
> Improving on D's capability to write and interop with low-level code, seems like a worthwhile exercise to me, as it expands the problem domains in which D can be used.
> 
> But that is a very different objective to being C's successor.
> 
> C will always B.

Until buffer overflows, stack corruptions, and other lovely security holes thanks to C's unabashedly unsafe and outdated language constructs make it irrelevant in a world where security is quickly becoming (if it hasn't already become) a primary concern.


Recently at my job I was assigned to review code quality issues found by an automatic code analysing tool in a very large C codebase.  From reviewing (and fixing) hundreds of them, I can confirm that Walter was 100% spot on when he talked about design problems in C, the worst of which are the memory-safety issues.  Some of the top issues I've encountered are:

- Uninitialized variables (i.e., there's a code path that leads to
  reading an uninitialized variable), the worst of which is
  uninitialized pointers.

- Dereferencing of null pointers (forgetting to check for null, or using
  a pointer *before* checking for null -- don't laugh, this happens
  *very* often even with the most seasoned C programmers; the code path
  that triggers this is usually completely non-obvious after a function
  has been revised several times).

- Resource leaks (most frequent: memory leaks; after that file
  descriptor leaks, then other resource leaks).

- Buffer overflows / overruns (unterminated strings being the most
  common). The worst offenders are functions that take a pointer to an
  array without a size parameter and just *assume* that there's enough
  space (oh yes, people still write such monstrosities -- a LOT more
  than you might think).

- Double free.

99.9% of these issues are latent bugs: the usual code paths don't trigger them so nobody realizes that the bugs are there.  But given some carefully-crafted input, or some environmental factors (disk full, file not found, different operating environments, etc.), these bugs will manifest themselves.

Sometimes these bugs *do* cause things to blow up in a customer deployment environment, and cost us a LOT of money to clean up and fix. Not to mention the countless hours of employee time spent chasing down and fixing these bugs -- and the wages paid that could have been spent on things like actually implementing new features and making progress.

And 90% of these issues are completely non-obvious to code reviewers (among whom are some of the best C programmers in our team).  These are not bugs caused by clueless n00bs; these are bugs that sneak into code written by seasoned C coders with decades of experience **because the language is inherently unsafe**.


One day, the realization will dawn on decision-makers that using such an outdated language in today's radically different environment from the 70's when C was designed, is a needless waste of resources. And then the inevitable will happen.


T

-- 
Democracy: The triumph of popularity over principle. -- C.Bond

On Wed, Nov 17, 2021 at 01:57:23AM +0000, zjh via Digitalmars-d wrote:
> On Wednesday, 17 November 2021 at 01:32:50 UTC, H. S. Teoh wrote:
> 
> Can I make full use of the `STD` library without garbage collection?
> If this is achieved, it can be advertised everywhere.
> ,Then why not remove `GC` on the home page?.

Why bend over backwards to please the GC-phobic crowd?  They've already made up their minds, there's no convincing them.

Having a GC IME is an extremely powerful thing, contrary to what the GC haters will tell you.  It frees up your APIs from being littered with memory-management minutiae.  It makes your APIs clean, refactorable, and maintainable.  Easy to use.  It makes your code clean.  You get to make progress in your problem domain instead of wasting 75% of your brain power thinking about memory management at every step.  You save countless hours writing manual memory management code, and countless more hours debugging said code.

And in D, you also get to choose to use manual memory management in performance bottlenecks *where it actually matters*. 90% of application code is not on the hot path, it's a completely waste of effort to meticulously manage memory in such code, when you could be focusing your efforts on the 10% hot path where 90% of the performance gains are made.

Writing code without a GC is wasteful of programmer time, which equals to wasting money paying programmers to do something that should have been done in 10% of the time, leaving the rest of the time to work on things that actually matter, like implementing features and making progress in your problem domain.  You spend tons of wages paying said programmers to debug memory-related bugs, which are notorious to be extremely hard to find and require a lot of time, when these wages could have been used to pay them to implement new features and drive your business forward.  *And* you waste tons of wages paying them to maintain code that's needlessly complex due to having to manually manage memory all the time.  It takes a lot of time and effort to maintain such code, time that could have been diverted for more useful work had a GC been in place.

And you know what?  In spite of all this time and effort, programmers get it wrong anyway -- typical C code is full of memory leaks, pointer bugs, and buffer overflows.  Most of them are latent and only trigger in obscure environments and unusual inputs, and so lie undiscovered, waiting for the day it suddenly explodes on a customer's production environment.  Or somebody comes up with a security exploit...

With a GC, you instantly eliminate 90% of these problems.  Only 10% of the time, you actually need to manually manage memory -- in inner loops and hot paths where it actually matters.

GC phobia is completely irrational and I don't see why we should bend over backwards to please that crowd.


T

-- 
"I'm running Windows '98." "Yes." "My computer isn't working now." "Yes, you already said that." -- User-Friendly