Jump to page: 1 2
Thread overview
Mission-Critical systems
Mar 16
Lasheen
Mar 17
Lasheen
Mar 16
Dukc
Mar 17
tsbockman
Mar 17
tsbockman
Mar 18
tsbockman
Mar 20
tsbockman
Apr 07
mw
March 16
Is D language designed for working with [Mission-critical] systems?
and what about:

1- Safety, Security and reliability to reach work in avionics systems.
2- memory management for [mission-Critical] systems.
3- which compiler i have to use (if yes).
4- which tools i can use for.

I want any information about that.
Thanks.

March 16
On Tuesday, 16 March 2021 at 04:22:01 UTC, Lasheen wrote:
> Is D language designed for working with [Mission-critical] systems?
> and what about:
>
> 1- Safety, Security and reliability to reach work in avionics systems.
> 2- memory management for [mission-Critical] systems.
> 3- which compiler i have to use (if yes).
> 4- which tools i can use for.
>
> I want any information about that.
> Thanks.

I asked this earlier:

"Sure. It's far better than C is. The biggest impact is simply having array overflow detection. There's a lot more, too, such as protections against uninitialized variables and pointers to expired stack frames."

"If C is ready for safety critical applications, then DasBetterC is beyond ready."

So, you would have to stick to a specific version of D and compiler, run a bunch of tests, document bugs etc, but other than that I see no problem with using D at all.

You just get safer code using D.
March 16
On Tuesday, 16 March 2021 at 04:22:01 UTC, Lasheen wrote:
> Is D language designed for working with [Mission-critical] systems?
> and what about:
>
> 1- Safety, Security and reliability to reach work in avionics systems.
> 2- memory management for [mission-Critical] systems.
> 3- which compiler i have to use (if yes).
> 4- which tools i can use for.
>
> I want any information about that.
> Thanks.

The language itself would be well upon the task. D is more safety-focused than your average language. It might not be quite the safety-before-all language Rust or Ada seem to be, but since even OpenBSD is written in C, I would not worry about the bar being that high.

But currently D is no option for anything that requires a certified compiler since there are none, nor plans to make one.

More info here: https://forum.dlang.org/thread/qspiqykabwfmgoibcvsa@forum.dlang.org
March 17
On Tuesday, 16 March 2021 at 06:57:53 UTC, Imperatorn wrote:
> On Tuesday, 16 March 2021 at 04:22:01 UTC, Lasheen wrote:
>> Is D language designed for working with [Mission-critical] systems?
>> and what about:
>>
>> 1- Safety, Security and reliability to reach work in avionics systems.
>> 2- memory management for [mission-Critical] systems.
>> 3- which compiler i have to use (if yes).
>> 4- which tools i can use for.
>>
>> I want any information about that.
>> Thanks.
>
> I asked this earlier:
>
> "Sure. It's far better than C is. The biggest impact is simply having array overflow detection. There's a lot more, too, such as protections against uninitialized variables and pointers to expired stack frames."
>
> "If C is ready for safety critical applications, then DasBetterC is beyond ready."
>
> So, you would have to stick to a specific version of D and compiler, run a bunch of tests, document bugs etc, but other than that I see no problem with using D at all.
>
> You just get safer code using D.

Thank you for your useful answer,

I tried to search for any tutorials that can help me to get in
but all the information i found were just a general information and i need some tutorials to explain how to start, which compiler i can use, how to use real-time in D, ..etc;

i normally use Ada and C for AI solutions but i think D can be the future of system languages if Walter and Andrey found the support.
March 17
On Tuesday, 16 March 2021 at 04:22:01 UTC, Lasheen wrote:
> Is D language designed for working with [Mission-critical] systems?

As others have said, *in theory* the language itself is much better suited for mission-critical applications than C, because of slices, stronger typing, @safe, etc. But...

> and what about:
>
> 1- Safety, Security and reliability to reach work in avionics systems.

I would not trust any current D compiler with a human life, because they are all rather buggy in my experience. And, they do not offer stable releases with long-term support, so you will inevitably either miss out on critical bug fixes by sticking with an old version, or expose yourself to regressions by updating often.

If the only other option is C, I would probably still pick D, but I suspect there are better options out there than either, once stability and quality of implementation is taken into account - maybe Ada, Rust, or, if a garbage collected language is acceptable, Java/Kotlin/C#.

> 2- memory management for [mission-Critical] systems.

D's stop-the-world garbage collector is not an option for true real time systems, where a missed deadline means someone actually dies.

However, in other cases I would use the GC if the goal is maximum reliability:

Many of the D features that make typical D code less error-prone than C equivalents require the garbage collector. Moreover, most D code uses the garbage collector and so the non-GC alternatives are generally less well-tested, and thus more likely to trigger compiler bugs.

(I speak from personal experience: I am currently working on an @nogc D program, and have so far found and reported several serious compiler bugs in the course of the project.)

> 3- which compiler i have to use (if yes).

The DMD backend is quite buggy (and also optimizes poorly) compared to those used by GDC and LDC. On the other hand, the GDC frontend is very out of date compared to those used by DMD and LDC.

So, definitely use LDC if you are planning to bet human lives and/or millions of dollars on it working fully correctly.
March 17
On Wednesday, 17 March 2021 at 03:44:15 UTC, tsbockman wrote:
> On Tuesday, 16 March 2021 at 04:22:01 UTC, Lasheen wrote:
>> 3- which compiler i have to use (if yes).
>
> The DMD backend is quite buggy (and also optimizes poorly) compared to those used by GDC and LDC. On the other hand, the GDC frontend is very out of date compared to those used by DMD and LDC.
>
> So, definitely use LDC if you are planning to bet human lives and/or millions of dollars on it working fully correctly.

This is misleading as if to say that GDC is not maintained, which is untrue.  GDC's current feature freeze means it is currently a stable rock whilst still getting backported bugfixes from dmd master, and is gaining plenty platform support where DMD and LDC don't have a presence - no GDC, no DMD or LDC on Musl - so another way to look at it, you could instead weigh up whether stability or bleeding edge is better suit for critical systems.
March 17
On Wednesday, 17 March 2021 at 17:13:00 UTC, Iain Buclaw wrote:
> On Wednesday, 17 March 2021 at 03:44:15 UTC, tsbockman wrote:
>> The DMD backend is quite buggy (and also optimizes poorly) compared to those used by GDC and LDC. On the other hand, the GDC frontend is very out of date compared to those used by DMD and LDC.
>>
>> So, definitely use LDC if you are planning to bet human lives and/or millions of dollars on it working fully correctly.
>
> This is misleading as if to say that GDC is not maintained, which is untrue.  GDC's current feature freeze means it is currently a stable rock whilst still getting backported bugfixes from dmd master,

The latest version of GDC which I have easy access to (Ubuntu's 10.2.0 package, since I can't find up to date binaries on the website) reports a frontend version of 2.076. And, it sounds like you're saying that this GDC version likely includes many improvements not listed in the DMD change logs up to 2.076.

But, how am I supposed to know what those backported improvements are? Is there a separate GDC frontend change log somewhere that documents all differences of significance to the user versus the standard 2.076 frontend? If so, I haven't been able to find it.

If I write code that requires a specific frontend bug fix or enhancement to work correctly, how can I detect whether GDC has it at compile time? On DMD and LDC I can just check the frontend __VERSION__, but that doesn't help me detect anything after the standard 2.076 with GDC.
March 18
On Wednesday, 17 March 2021 at 19:54:23 UTC, tsbockman wrote:
> [..] Is there a separate GDC frontend change log somewhere that documents all differences of significance to the user versus the standard 2.076 frontend? [..]

I suppose this is what you're looking for:

Changelog for the current year:
https://github.com/D-Programming-GDC/gcc/blob/master-ci/gcc/d/ChangeLog

Changelog for previous years:
https://github.com/D-Programming-GDC/gcc/blob/master-ci/gcc/d/ChangeLog-2020
https://github.com/D-Programming-GDC/gcc/blob/master-ci/gcc/d/ChangeLog-2019
https://github.com/D-Programming-GDC/gcc/blob/master-ci/gcc/d/ChangeLog-2018

For example:

[..]
	* dmd/MERGE: Merge upstream dmd a3c9bf422.
[..]
	* dmd/MERGE: Merge upstream dmd 7132b3537.

These correspond to:
https://github.com/dlang/dmd/pull/12190
https://github.com/dlang/dmd/pull/12247



March 18
On Thursday, 18 March 2021 at 08:36:51 UTC, Petar Kirov [ZombineDev] wrote:
> On Wednesday, 17 March 2021 at 19:54:23 UTC, tsbockman wrote:
>> [..] Is there a separate GDC frontend change log somewhere that documents all differences of significance to the user versus the standard 2.076 frontend? [..]
>
> I suppose this is what you're looking for:
>
> Changelog for the current year:
> https://github.com/D-Programming-GDC/gcc/blob/master-ci/gcc/d/ChangeLog

Thanks, but I've seen that before. It's an internal development log, and does not describe how code changes translate into different user-facing behavior. So, in order to understand which additional issues are fixed in the current GDC frontend, I have to:

0) Filter all the irrelevant internal changes out of the log.
1) For each "Merge upstream dmd" line,
    a) Manually look up the relevant DMD commit (no links).
    b) Find the pull request that introduced that commit, since that's where most of the discussion is.
    c) Study the DMD pull request to figure out what issue, if any, it fixes.
    d) Read the discussion and study DMD's commit history to figure out whether *all* required changes have also been backported to GDC from other relevant DMD commits, which other changes may or may not even be mentioned in the DMD pull request discussion.

(1.d) is necessary even if I assume the GDC developers never make mistakes or miss anything, because the GDC changelog doesn't even claim to record issues fixed, but only upstream commits merged. An upstream commit may have been merged because it partially fixes some issue, and fully fixing the issue was considered infeasible with a 2.076 base. Or, it may have been merged without all prerequisites simply because backporting the fix is a work in progress.

TLDR; Translating that changelog into a list of issues *fixed* (not just affected) is time consuming and can only be done with confidence by someone who is an expert in the development history/process of both DMD and GDC.
March 18
On 3/16/2021 8:44 PM, tsbockman wrote:
> So, definitely use LDC if you are planning to bet human lives and/or millions of dollars on it working fully correctly.

The first three years of my career was spent developing the flight critical stabilizer trim gearbox for the 757. Flight critical means if it comes apart, you lose the airplane and everyone aboard.

So I know how to build things that are critical for human life.

Generally speaking, there is no relying on any tool to be bug-free. Test and verify everything. Design in a backup system to monitor the behavior.

For example, there was an autopilot embedded system that commanded the stabilizer trim. We all know how a runaway stab trim system can kill people (see the 737MAX).

There were two autopilot computers in parallel. They both had to agree, or both were automatically disconnected. They used different microprocessors, different software algorithms, different programming languages, different compilers. The coding was done by different teams who weren't allowed to talk to each other. A third independent team verified that no problem in one could propagate to the other.

Notice there is no reliance on bug-free hardware, bug-free algorithms, bug-free code, bug-free compilers, etc.
« First   ‹ Prev
1 2