May 17, 2022

On Tuesday, 17 May 2022 at 04:30:18 UTC, max haughton wrote:

>

Z3 and LLVM are not written in C, unless you mean the stable APIs to them.

Sooo... In this context C and C++ with C interface is the same.

Yes, many Cish codebases are dressed up as C++ these days.

May 17, 2022

On Tuesday, 17 May 2022 at 04:34:16 UTC, max haughton wrote:

>

On Tuesday, 17 May 2022 at 02:43:31 UTC, Ola Fosheim Grøstad wrote:

>

On Tuesday, 17 May 2022 at 01:57:44 UTC, forkit wrote:

>

Only then will we have sufficient impetus to get off our butts and do something about our extensive reliance on what is arguably, the most unsafe language of all -> C.

Actually, C is one of the few languages in use where there are industtial verification solutions...

Anyway, D has always followed C semantics and has always been system level. It never claimed not to be.

People who care a lot about correctness now use Rust, compilers for such languages are implemented in Rust. In that narrow space Rust cannot be displaced in the next 10 years.

Yet, Skia, Z3, LLVM and other big performance libraries will remain in C in the next 10 years. Nobody wants to rewrite those in other languages. Nobody can afford to build competitive free alternatives. So, C it is!

ImportC done well allows D to benefit from the selfimposed restriction of being C-like that has been there from day 1.

The only way to do it well is to do an integration that drills down to the level of the lexer, parser and AST.

Other than memory safety rust doesn't have all that many virtues beyond any other language for guaranteeing correctness.

Ada remains the top dog for properly critical software. SPARK still does not have many proper challengers in the space.

Those who care for Ada, or correctness, are also interested into bringing Rust into the game,

https://blog.adacore.com/adacore-and-ferrous-systems-joining-forces-to-support-rust

https://www.autosar.org/news-events/details/autosar-investigates-how-the-programming-language-rust-could-be-applied-in-adaptive-platform-context/

May 17, 2022
On Tuesday, 17 May 2022 at 01:03:14 UTC, forkit wrote:
> On Sunday, 15 May 2022 at 23:11:28 UTC, max haughton wrote:
>> 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.
>
> The choice of language can eliminate a whole class of bugs.
>
> It can also ensure the likelihood of a whole class of bugs.
>
> I'm sure you know this of course. I'm just stating the obvious.
>
> Fortunately, many get this, and are actively researching ways to move away from C - e.g. https://github.com/tock/tock/blob/master/doc/Design.md
>
> If Apple is not already doing very extensive research in this area, I'd be ...rather shocked.
>...

That is what Swift is all about,

> Swift is intended as a replacement for C-based languages (C, C++, and Objective-C).

Taken from https://www.swift.org/about/

> Swift is a successor to both the C and Objective-C languages.

Taken from https://developer.apple.com/swift/#fast

And some C improvements as well, thanks hardware memory tagging support

> In iOS 14 and iPadOS 14, Apple modified the C compiler toolchain used to build the iBoot bootloader to improve its security. The modified toolchain implements code designed to prevent memory- and type-safety issues that are typically encountered in C programs.

Taken from https://support.apple.com/guide/security/memory-safe-iboot-implementation-sec30d8d9ec1/web

May 17, 2022

On Tuesday, 17 May 2022 at 02:21:28 UTC, forkit wrote:

>

But I cannot do it ;-)

It must be 'we'.

(same with global warming I guess).

having said that, the first line I write in a D module, is -> @safe:

how many others can say the same?

Then fund it, or if you have insufficient monetary resources to effect anything substantial, assist in organizing a group to sponsor libraries written in D. That is, if you truly want to achieve your goals.

P.S. While I often apply @safe at module-level, the GC and bounds-checking already accomplish a lot by themselves in my experience.

May 17, 2022

On Tuesday, 17 May 2022 at 05:19:52 UTC, Ola Fosheim Gr wrote:

>

On Tuesday, 17 May 2022 at 04:30:18 UTC, max haughton wrote:

>

Z3 and LLVM are not written in C, unless you mean the stable APIs to them.

Sooo... In this context C and C++ with C interface is the same.

Yes, many Cish codebases are dressed up as C++ these days.

That doesn't mean anything... You're such a windbag that it reduces the quality of the forum.

May 17, 2022

On Tuesday, 17 May 2022 at 05:43:07 UTC, Araq wrote:

> >

Yes, many Cish codebases are dressed up as C++ these days.

That doesn't mean anything...

Sorry, but I’ve looked over both code bases. They make limited use of C++ abstractions, just like dmd did. And you would interface with D through the Z3 C interface, not C++.

May 17, 2022

On Tuesday, 17 May 2022 at 05:55:16 UTC, Ola Fosheim Grøstad wrote:

>

On Tuesday, 17 May 2022 at 05:43:07 UTC, Araq wrote:

> >

Yes, many Cish codebases are dressed up as C++ these days.

That doesn't mean anything...

Sorry, but I’ve looked over both code bases. They make limited use of C++ abstractions, just like dmd did. And you would interface with D through the Z3 C interface, not C++.

In case that was unclear:

Modern C++ will typically present a template-heavy interface. D cannot interface with that. Now you are in locked up in C++ land.

Cish code in C++ dressing easily provides a C-API. The original DMD codebase, Z3 and many other C++ codebases can with limited effort be translated into C. That makes them Cish… There is a 1-to-1 mapping of most of the model that you need to interface with.

And that is why importC is a valuable addition even if fewer libraries are written in C and more libraries are written in C++ over time.

May 17, 2022

On Tuesday, 17 May 2022 at 00:50:53 UTC, max haughton wrote:

>

On Monday, 16 May 2022 at 22:35:00 UTC, forkit wrote:

>

Just imagine Rust/Go implementing a C compiler inside their own compiler They'd be laughing stock (not because it's wrong or silly, but because they took the initiative to step further awat from C, not further towards it).

https://github.com/rust-lang/rust-bindgen

It's not built in to the compiler but it's officially supported by the Rust foundation.

Well, this looks like one of the automated bindings generators. Many of these exist for various languages since a very long time ago. The problem of creating bindings to the existing popular C and even C++ libraries in order to use them from the other programming languages is not new. Numerous solutions for this problem are also not new. I think that https://www.swig.org/ existed since like forever and D is even listed as one of the supported languages.

In my earlier comment I also mentioned the hybrid projects, which are mixing multiple programming languages in the same codebase to leverage their advantages (C for the performance critical parts and Lua/Python for convenience/safety in the other parts).

Walter is very much hyped about ImportC. But his solution needs to be objectively compared to the other existing solutions, rather than pretending that it's a unique groundbreaking innovation which will finally make D language popular.

May 17, 2022

On Monday, 16 May 2022 at 22:52:27 UTC, forkit wrote:

>

On Monday, 16 May 2022 at 08:08:51 UTC, Walter Bright wrote:

>

...
....
I am unfamiliar with kernel development and its needs. It apparently is also written in a dialect of C with special compiler switches.

What it 'needs' is to move away from C.

https://cve.mitre.org/cgi-bin/cvekey.cgi?keyword=linux+kernel

It's moving to Rust as an option at least for some parts of the kernel and this will reduce the attack surface, so you are preaching to the choir. D decided not to participate in this race. Or even didn't notice that such opportunity existed.

May 17, 2022

On Tuesday, 17 May 2022 at 06:26:23 UTC, Siarhei Siamashka wrote:

>

Walter is very much hyped about ImportC. But his solution needs to be objectively compared to the other existing solutions, rather than pretending that it's a unique groundbreaking innovation which will finally make D language popular.

I actually think D can become a disruptor if this is done properly and the other loose ends of the language is plugged. So being hyped up is warranted in my opinion, even if the road ahead is a long one.

Especially if he successfully has been able to express all C11 constructs in the AST, because then you have something to work with and can gradually improve on embedding macro expansion in D code.

I just pray that the D community avoid heuristic pattern matching hacks. mixinC is ok for the most hardcore users, so you can have that, but you need something with better usability for this to be a success.

If it is significantly harder to use than C-macros in C people will just ask themselves why they don't use C/C++ etc.