On Sunday, 15 May 2022 at 06:18:58 UTC, forkit wrote:
>
> Also, operating systems of the (near) future will require safety guarantees from the software that is intended to run on that operating system. C is not a language that facilitates this.
>

Um, no that will not happen, ever. The safety guarantee of modern operating systems is and will be the MMU. Relying on "safe" software will never be enough. There have been attempts using safe intermediary languages like Microsoft Singularity but don't expect this ever to be a commercial operating system. The MMU is here to stay.

On Sunday, 15 May 2022 at 12:28:54 UTC, zjh wrote:
> On Sunday, 15 May 2022 at 11:25:47 UTC, H. S. Teoh wrote:
>
> He has been talking nonsense .Just ignore him.

Shame on you.

Just because this is an online forum, and we're not sitting around a table together, you think that is ok?

Please try raising your point-of-view (whatever that is) to an appropriate intellectual level.

On Sunday, 15 May 2022 at 18:47:22 UTC, IGotD- wrote:
> On Sunday, 15 May 2022 at 06:18:58 UTC, forkit wrote:
>>
>> Also, operating systems of the (near) future will require safety guarantees from the software that is intended to run on that operating system. C is not a language that facilitates this.
>>
>
> Um, no that will not happen, ever. The safety guarantee of modern operating systems is and will be the MMU. Relying on "safe" software will never be enough. There have been attempts using safe intermediary languages like Microsoft Singularity but don't expect this ever to be a commercial operating system. The MMU is here to stay.

I don't think the choice of language is going to make much difference but I'd be surprised if Apple don't do something along these lines in the future. They already scan and analyse applications relatively aggressive for mobile and to an extent for MacOS too.

On 5/14/22 23:18, forkit wrote:

> developers have
> a wider obligation that just stitching together software so that it works.

Wider than their salaries? Employers needs developers and developers work for money. In the end it just works out.

> Structured higher-level languages is where we need to be moving towards,

Ok.

> not moving backwards to low-level languages like C.

I am never moving to C. I don't think anybody should be using C ever.

> I understand the appeal of making it easier to use C libraries in a
> otherwise D solution.

Me too! :) I think you think easier access to C libraries is wrong. I disagree.

Besides, I think we've been using the wrong term here: ImportC allows using libraries with C interfaces easier. The implementation could have been any language. But that's beside the point. If there is a library with a C interface that solves a company's problem then they will use that library.

> But ImportC is short-sighted in my opinion, and is a step in the
> opposite direction.
>
> The focus should instead be on @safe, not C.

An open source community allows (should allow?) individuals to spend their energy on any topic that they want. Some will work on ImportC, others (which apparently includes you) will work on @safe.

Ali

On Sunday, 15 May 2022 at 18:47:22 UTC, IGotD- wrote:
>
> Um, no that will not happen, ever. The safety guarantee of modern operating systems is and will be the MMU. Relying on "safe" software will never be enough. There have been attempts using safe intermediary languages like Microsoft Singularity but don't expect this ever to be a commercial operating system. The MMU is here to stay.

Relying on safe software alone, is not what I said.

But modern architectures do not provide a 'safe' operating environment either.

e.g Evict+Time cache attacks on the MMU ??

There is an abundance (to put it mildely) of research and real-world evidence that operating systems are not safe (by design).

IoiT (Internet of insecure things) o/s's bring this to a whole new level.

All (mostly) built using C, which results in an inherently unsafe operating environment.

The problem here is C. Used (and still used) primarily for performance reasons.

As useful as ImportC sounds (if it worked 100% correctly), it seems to be taking D programmers in the wrong direction (given my argument above).

i.e. "just bring C code over here into your D project. It'll be fine. Don't worry. You don't even need to understand what that code does.. just import it."

On Sunday, 15 May 2022 at 23:32:33 UTC, Ali Çehreli wrote:
> ...
> I think you think easier access to C libraries is wrong. I disagree.
>
>

No. My argument is not that ImportC is wrong, or even useless.

My argument has to be taken *in context* of wanting programmers to write safer, more secure code, and how ImportC does not advance that aim, and *possibly* does the exact opposite.

So, by raising my concern, I hope to get people to think twice before importing C code into their D projects, with the aim of not even needing to know what that C code does.

On 5/15/2022 5:28 AM, zjh wrote:
> [...]

Let's keep the discourse here professional.

On Sunday, 15 May 2022 at 23:32:33 UTC, Ali Çehreli wrote:
>
> An open source community allows (should allow?) individuals to spend their energy on any topic that they want. Some will work on ImportC, others (which apparently includes you) will work on @safe.
>
> Ali

My comments are in the context of this thread, about why D is unpopular.

It's not about me wanting to stop people in an open-source community from spending their time on whatever they want.

But I feel ImportC and @safe push D into two completely different directions.

So D may become 'more' popular to those wanting to import more C into their D.

And D may become 'less' popular because more people are importing C into their D.

I'm struggling to see how two different directions get us to... well.. anywhere.

On Monday, 16 May 2022 at 02:05:32 UTC, forkit wrote:
> On Sunday, 15 May 2022 at 23:32:33 UTC, Ali Çehreli wrote:
>>
>> An open source community allows (should allow?) individuals to spend their energy on any topic that they want. Some will work on ImportC, others (which apparently includes you) will work on @safe.
>>
>> Ali
>
> My comments are in the context of this thread, about why D is unpopular.
>
> It's not about me wanting to stop people in an open-source community from spending their time on whatever they want.
>
> But I feel ImportC and @safe push D into two completely different directions.
>
> So D may become 'more' popular to those wanting to import more C into their D.
>
> And D may become 'less' popular because more people are importing C into their D.
>
> I'm struggling to see how two different directions get us to... well.. anywhere.

This assumes that both features apply to exactly the same subset of all D programs, which they don't.

At Symmetry we have very large D codebases which could be easily argued would benefit from both ImportC and @safe given optimal implementations of them both.

Most D code does not directly interface with C, but a lot of D *projects* do, hence ImportC.

Most D projects also benefit from being able to rely on the safety of a given chunk of D code.

On Monday, 16 May 2022 at 02:05:32 UTC, forkit wrote:
>

i just realised, I can now answer the question 'Why is D unpopular?'

Because it has no shared vision.