On Wednesday, 17 November 2021 at 07:04:54 UTC, Paulo Pinto wrote:

Sorry, to clarify I meant in the embedded space / functional safety.

I have not seen any Rust anywhere in safety-critical appliations yet.
(Not D either of course)

Since there is no certified compiler for Rust (yet) or toolchain or acknowledged coding standard.
I guess there will come something similar like (a proper) MISRA-C for Rust

Reading through the coding standards ISO, only very recently (10 years ago) even C++ have been mentioned that it might be ok to use. It's a very conservative space.

I have no doubt that in about 10 years or so, Rust could be used (maybe?) in these applications, but it all depends on the system at hand and how you build it.
Like for example what a safe state is, what level you have on certain parts etc etc.

For example you could in theory even use QBASIC to control some critical part of a system if there are no requirements on for example (I don't know the English term) SIL "monitored movements" and only have requirements that the stop function has a certain level. It all depends on the system and requirements.

For example, our company has a product from 1986 which is still in use today because it took us about 7-8 years to get all the documentation and testing in place (that one uses assembly though).

It's not only software requirements, there are RED, LVD, EMC, EMI etc etc, dual architecture, monitoring of outputs, watchdog requirements (ASIL D), latency requirements, active vs passive stop, data integrity requirements (think CRC), bit flip requirements etc (yes, during the validation and verification process we introduce random bit flips to simulate an external memory corruption event, such as cosmic backround radiation) etc.

It is a very conservarive space. In some aspects it might seem dumb (ilke, why would a language with higher guarantees be worse?), but I guess it comes from a sense that you want to be sure all parts work as expected and it's partly driven by fear/being cautious.

Gotta work now, but just a quick summary

https://www.iar.com/products/requirements/functional-safety/iar-embedded-workbench-for-arm-functional-safety/

https://www.highintegritysystems.com/

https://www.ghs.com/products/industrial_safety.html

On Wednesday, 17 November 2021 at 14:18:04 UTC, Imperatorn wrote:

Get in touch with https://ferrous-systems.com/ and you will see your applications, for example how they are collaborating with Green Hills Software,

https://www.youtube.com/watch?v=G5A7rSPYpb8

On Wednesday, 17 November 2021 at 14:23:57 UTC, Paulo Pinto wrote:

Yeah, things are slowly changing

On Wednesday, 17 November 2021 at 17:48:05 UTC, H. S. Teoh wrote:

I am getting Winnie the Pooh vibes from this.

The key to finding a solution is understanding the problem and the context. If you don't, you won't find a solution, you will just create more problems. Has nothing to do with "Good Work". It is a sign of "Poor Work". Don't mix those two terms!

If understanding the problem is difficult, reduce the problem, reduce the scope of what you try to achieve. Learn from others. So what can we learn from other system level programming languages? No GC! Ok, remove the GC. Now the scope has been reduced and we can more easily find an acceptable solution for a system level programming language.

That is basically a consequence of your position, but obviously not what you meant…

On Wednesday, 17 November 2021 at 18:57:23 UTC, Ola Fosheim Grøstad wrote:

Andrei called it "good work" because he meant stuff that is bad enough to draw a lot of effort to review, but not so bad that it could be just dismissed without appearing rude. "Bad" or "poor" would be mean the "obviousy not worth it" work.

Being both GC and NoGC is kind of our unique selling point. There would have to be a very strong case before it'd be wise to discard one or the other from the language.

On Wednesday, 17 November 2021 at 19:39:04 UTC, Dukc wrote:

Yes, he wrote a long essay in order to diffuse the issue of being rude. Clearly a compiler, runtime and standard lib should only accept excellent code, as everybody else builds on top of it. It is better to reduce the scope of the language/library if that cannot be achieved.

The bar for acceptance should not be high, it should be very high.

Yes, but that means that we have to solve a very difficult problem. I think local GC + global RC can be an interesting solution. So it is good that they look at making RC easy to implement. We have to work to find an excellent solution! Mediocre or "you are on your own" is not good enough in system level programming anymore.

Lots of good ideas there.

Violently agree with:

1.
    @safe -> safe
    @trusted -> trusted
    @system -> system
    @nogc -> nogc

  @No @it's @not @that @disruptive.

2. If I understand correctly auto-decoding is being worked on.

3. WebASM being important. YES.

4. Other languages recruit in Python and Web developer circles, since that's what people are taught first.

Some of us don't want GC or Phobos and need to live under @nogc, disabled runtime (not -betterC necessarily) is super useful. I'd want optional Phobos.

I disagree with:

- Formats like JSON Schema need champions from the community who will produce and maintain a DUB package. Likewise for HTTP 2/3.
  Different for the event loop, as it has network effects. Heck, people create D libraries all the time, it just needs direction maybe.

• No mention of DUB aesthetics and usability! It is paramount, more colors and animations would go a long way.

• safe by default: I really don't care about that. I guess it would be a positive? Will I earn more money selling D software? Perhaps slightly more. Why not do it.

Anyway, Robert for president!

On Tuesday, 16 November 2021 at 21:00:48 UTC, Robert Schadek wrote:

I think Zig will be a more powerful competitor in the future than Rust. Rust appeals more to C++ programmers, but Zig is targeting C programmers more. I've been looking at Zig lately, and I have to say I think it's a very interesting language. It has optional standard library and bring-your-own-allocator memory management design, which is very tempting for C folks who like to manage their own memory.

On Wednesday, 17 November 2021 at 20:36:10 UTC, JN wrote:

Good support for "runtimeless" is generally viewed as a requirement for a language to be considered a true system level programming language. I wish someone would do a Zig vs D comparison in the forums as it didn't look all that impressive to me, but I could be wrong.

You also have this for WASM (I know absolutely nothing about it):

https://github.com/AssemblyScript/assemblyscript

One issue with WASM is that you cannot take the address of items on the stack (IIRC) so you have to create an inefficient shadow-stack if the language expects that you can do it. So, really, a restricted D subset tailored to WASM could be better for those who want to use WASM for performance reasons (like writing a game).