[terminalcommand]

We are all afraid of errors due to manual memory management, but it seems wrong to me to believe that every language that is "safe" from the memory perspective is safe.

I'd argue that in some situations interpreted languages are much more dangerous compared to a simple compiled language like C. With new "safe" languages you do not encounter an error most of the time, but when you do see an error it is quite discouraging to see that your "safe" language fails and you don't have any idea why it fails.

In order to be safe we need simplicity. We need to move the main part of the program to compilation time to have static checks. We need to write comprehensive tests on the parts we leave to the runtime. We need to check inputs at every stage.

We need to be very very careful when using concurrency.

In that matter I find the OpenBSD developers' use of C much more secure than any package on npm.

OTOH C++ is a different beast, it is complex, it has many fine-points to master.

I'd say programming in Go and using QT could be a good choice, if you're considering memory safety above all things.

[whyever]

> With new "safe" languages you do not encounter an error most of the time, but when you do see an error it is quite discouraging to see that your "safe" language fails and you don't have any idea why it fails.

I think it is very odd that you argue for C, which has the concept of undefined behavior, which is much, much worse than any kind of failure the memory-safe languages without static types can offer.

> In that matter I find the OpenBSD developers' use of C much more secure than any package on npm.

Bold claim, they still fall victim to undefined behavior:

https://www.cvedetails.com/vulnerability-list/vendor_id-97/O...