Panzerschrek

How did it work? As I know DOS wasn't even a proper operating system, there were no separate processes, only single running task. So, how was it possible for multiple users to run multiple programs in parallel?

If I wanted working really close to hardware, do bit-twiddling and knowing where every byte is allocated, I'd take Zig

Why not C++? It allows as many low-level operations as one wishes, but don't forces you to manage memory manually where it isn't necessary.

If I wanted to write a small piece of code intended to run absolutely everywhere

GCC and Clang have support of C++ since many years. Is there any modern platform for which no GCC or Clang backend exist?

Yet another attempt to reinvent a better C. Curious, but unpractical. If one need a better C, C++ should be used instead.

It is memory safe

How? Do you have references/pointers? Are all objects except basic scalars heap-allocated and GC-tracked? Do you perform some clever compile-time analysis?

I don't know what you exactly mean with an "abstract container"

I mean something like std::vector<Base> (from C++) able to store pointers to instances of derived classes.

entity is just a tuple of pointers

It looks like having just a pointer to a Legs* component I can't access the whole object (having other components). Am I right?

How does it achieve memory safety? Via garbage collection? Via runtime checks? Via some clever compile-time analysis?

Is it memory safe? Can I cause use-after free, double-free, out-of-bounds access errors or something similar? What about race conditions?

In your DCMP examples you demonstrate how types can be composed from smaller components. How does it work under the hood? Is it possible to create an abstract container for Legs and store inside it any object having this component?

Interesting, but unpractical. As I know there is no way to perform automatic translation from one programming language to another without producing code which looks terrible in the destination language.

In this particular example I see no real safety benefits. If the source program is buggy, the result translated program willcrash at runtime, but if it's (mostly) bug-free and UB-free, such translation gives no benefits.

Interesting. I didn't thought it's possible.

There are also performance benefits of unsigned integer types: division, modulo and sometimes multiplication for them works slightly faster.

Can I write a game using OpenGL in Lisp?

Public infrastructure is different. It should work for everyone. My argument is more about commercial products with profitability kept in mind.

There are cases when providing service for remaining 2% isn't profitable. It's better just say "sorry".

I used to work in company where we have spent a lot of time making custom fixes for our software in order to work-around wired hardware/software bugs on machines of individual customers. Yes, we provided service for remaining 2% or so, but in cost of slowing-down overall product development and not making our product better for remaining 98%.

Nice thing! I did something similar for a couple of years, but with hex-prisms instead of cubic voxels.

exceptions are slow

There are proposals to introduce better exceptions into C++. Like this: https://www.open-std.org/jtc1/sc22/wg21/docs/papers/2018/p07....

But until it's not in the standard, people should use std::expceted instead.

The purpose of cryptography theatre is not to deliver actual security from a cryptographic perspective but act as a kind of magic spell

This reminds me Telegram, which promises to be secure, but requires giving it my phone number, which is the most insecure thing one can do.

Your proposal still contains a security hole, since it still allows executing cmake or something similar. Adding sandboxing in some parts/steps of a build system has no benefits, as soon as the system as whole has loopholes allowing bypassing such sandboxing. It's like adding more locks to the front door, when the backdoor has no locks at all.

I didn't say one should not use thirdparty dependencies at all. They are sometimes useful. But they should be chosen carefully and ideally reviewed. And any updates should be done manually in order to prevent security chain attacks.

Having a standardized package manager allows lowering the bar and bypassing careful thinking. It has also a cumulative effect - if one adds each dependency in its project one by one with proper audits, transitive dependencies may not be managed so carefully. And then we have cargo-style cancer with trivial projects having hundreds of dependent packages.

For me this happens from time to time. But it's for a good reason - I develop my own compiler. And it can be pretty tricky to identify and track such bugs.

Very interesting approach. But I see little practical usage for it. Usually when I care doing fuzzing, I can recompile with clang and fuzzing passes.

I think it's actually good that C++ has no standardized packaging system. This forces one to think carefully before introducing a dependency, since often such dependency have hidden costs, like security vulnerabilities. Since many critical systems are written in C++, it's too much risk to depend on dozens of easily-accessible third-party packages without properly auditing each of them.

I see no benefits in sandboxing such things as build systems. Sooner or later one eventually needs to execute some external code, like a shell script or cmake. And these external programs can do whatever they want. So, caring about sandboxing within a build system executable is just creating a security theater.

It's even worse. Learning Lua may be at least a little bit useful for other tasks. Learning some language specific for this tool is just waste of time.

Using Lua is a fatal flaw. As a C++ programmer I don't want to learn yet another language for a build system.

Is it some silly attempt to gather personal data like physical address/phone number?

I am pretty skeptical about the whole idea about adding such exceptions to the single mutable reference rule. It may be safe to share references to simple structs in terms of raw bytes access, but as long as some non-trivial invariants are involved, it can be a source of nasty bugs.

In my programming language I generally don't allow having more than one mutable reference to a variable. The only exception is when two references point to different elements of structs/tuples. This gives some flexibility without sacrificing correctness.

Because of this, Ante code can safely have multiple mutable borrow references to the same struct at the same time.

I doubt it can work in multithreaded code. Allowing sharing mutable references (even to simple structs) means race conditions, temporal inconsistency between different struct fields and even incorrect read results for basic integer types (if the target CPU can't atomically read/write values of types like u64).

every app is a small HTTP server

This adds unnecessary overhead for communication. using web and web-like approaches on desktop system is a terrible idea.

writing the same algorithm in multiple places with

This seems for me to be reasonable. Like for a video game with server written in Go/C++/Rust and client written in C#/Javascript, where the same calculations should be done on both sides.

implementing reusable components (libraries) for C, C++, C#, D, Java, JavaScript, Python, Swift, TypeScript and OpenCL C, all from single codebase

Why is this needed? I can't imagine that. I am sure writing code in fusion will produce C++ and Python code which is suboptimal and doesn't fit well in these languages.

A whole programming language in 3 weeks? Is it LLM-generated?