Should programming languages be safe or powerful?

Are they not both turing-complete?

The biggest difference is that in Racket, cons cells, and thus lists, are immutable (the Scheme #langs like r5rs use a different incompatible type for their conses). There's other more subtle changes but that's the one most likely to bite people used to Scheme. Well, that and `if` taking exactly 3 arguments.

Indirectly, you can. They'll specify how many floors there needs to be, and combined with automatically-specified things like gravity and local weather phenomena, you can derive what building materials you can safely use.

But you can push back when they ask you to build a 40-storey skyscraper out of dry spaghetti noodles.

I am more than willing to use, support, and even participate in software that is not critical and think a more-bright line separation should exist to delimit the arena for which craft scale software is appropriate. The other side of that is I am willing to acknowledge the existence of arenas not suited to less than formal and legal requirements for the design and ‘construction’ of software artifacts.

Controversially, I think societally we use software in too integrated and too many areas that are better left sequestered and siloed. There really is no reason that a general computing device should be used for both untrusted internet connectivity and storing and accessing banking or medical information. The ubiquity of protected purpose built hardware should have been a goal, with a more general open computing hardware environment used by informed choice.

The program is put together in a way such that it avoids stepping on those cases. For instance, by validating and diagnosing inputs so as to avoiding executing that code.

You would think that a program which has been deemed "correct" cannot misuse any of its own code with undefined results. Alas, that is not the case. Such a program is called a "robust" program. A correct program is one that meets all of its functional requirements; does eveything right with correct inputs. Whether robustness is required for correctness depends entirely on how the program is specified: does the specification explicitly call for robustness (grace on bad inputs) or not?

For instance, the memcpy() function in your C library is a correct program (hopefully). When you use it correctly, it does its specified job. Most implementations of it are not robust, though. Most memcpy functions cheerfully accept overlapping objects and do something, and are easily crashed by bad pointers.

Robustness is related to security. It is often in the areas of the software that lack robustness that attackers find exploitable surfaces!

Safe languages contribute robustness to programs. It's as if the requirements were added to the spec of every program. The programmers working with these languages, and their users, get accustomed to this and then expect robustness out of programs as a tacit requirement.

Note that an incorrect program can be robust! A program that due to some coding mistake or misunderstanding calculates the wrong thing for correct inputs (not meeting a functional requirement) can still be impervious to misuse.

So in a nutshell, safety is more concerned with robustness than correctness. That's why we can talk about languages and libraries being safe, in the absence of a program being specified. Those tools are still safe when they are used to put together a program that doesn't meet its functional requirements.

The safety mechanisms in safe languages may not be enoguh for some desirable level of robustness. Users don't want programs to stop with a diagnostic message because they gave bad inputs. Modern safe languages have tools like exception handling.

Some wrongheaded programmers think that just because the default robustness provided by safe languages is not always good enough for many kinds of professional or industrial applications, those robustness features are therefore not worth it. ("If I'm going to have to check for bad inputs and take special action, what's the use of the language doing the checking robust.") The safe language can make it much easier to do that, though. For instance, we can often let an entire module execute freely and just catch an exception in one place. Say, inside a CAD program, some calculation over a model could divide by zero. We just catch that somewhere, put up a dialog (or log something in a log window) and the CAD program keeps running.

"Programming languages should be safe by default, except in clearly delimited sections of code (as small as a single expression) where the programmer requests less safety."

In terms of the word semantics of the situation, people writing in a safe subset of a language are writing safe code. Once they use the unsafe bits, then they aren't.

It also means that beginners can reasonably use the language for production projects. Including those who have never had the opportunity to study computer science.

To me, it reflects poorly on a language if pretty much the only reasonable way to learn it such that you can use it safely is via computer science course (or another similarly structured environment - perhaps a work place with senior mentors).

Of commonly used languages, that's pretty much true only of C and C++.

That's kind of similar to safe versus unsafe language features.

You still have to respect the operating parameters, because if the part goes into thermal shutdown or current limiting, then your device doesn't perform properly.

When the device doesn't work properly, even though there is no smoke coming out of it, it can still take time to track down the problem.

When using a safe language, we similarly don't necessarily want the user to be exposed to the raw safety mechanism going off, which could have consequences like terminating the image, with the loss of unsaved data, and interrupted workflows.

Typically, in modern safe languages we have some decent choices for handling and recovering from situations like that, so we don't have to be cluttering every operation with conditionals that check for exceptional situations.

But I'd say, in general, building is in a much better state. There are fairly standard rules, which are mostly followed, and most building stay standing, year after year, without the need for constant maintence. On the other hand, software is still really pre-fire of london (at best) in terms of quality and standards.

Wanting to wait until 1.0 to get started is a respectable choice. I prefer to get a head start, compile against master every few weeks, and change what needs changing.

Zig has near-seamless C interop and the Zig compiler is also C cross-compiler:

https://zig.news/kristoff/cross-compile-a-c-c-project-with-z...

Now, the techno-mysticism will eventually become true when we get the AGI you describe but that’s both far beyond what we have now and would immediately raise the question of whether it’d be effort better spent migrating to a less poorly-designed language.