Hard disagree. There are a lot of implementation "details" that, if you want to do properly, are a lot of hard work and very much nontrivial. For example, do try to write a compiler with efficient incremental compilation, and especially one that does so while also having optimization passes. And that's just one example, most things in compiler implementations actually turn out to be fairly complex. And lots of features that modern languages support e.g. more powerful typesystems, trait/typeclass systems, etc. are also very very tricky.
While designing a language is by no means trivial, it generally really occupies just a very small fraction of the language/compiler developer's time. And, in most cases, the two things (language design + implementation details) have to walk hand-in-hand, since small changes to the language design can vastly improve the implementation end.
To add to that, Rust code is generally not written to be 'exception-safe' when panics occur: if a third-party function causes a panic, or if your own code panics from within a callback, then memory may be leaked, and objects in use may end up in an incorrect or unusable state.
You really want to avoid sharing mutable objects across a catch_unwind() boundary, and also avoid using it on a regular basis. Aside from memory leaks, panicking runs the thread's panic hook, which by default prints a stacktrace. You can override the panic hook to be a no-op, but then you won't see anything for actual panics.
Yeah, I'm fairly sure that there is such a flag/toplevel attribute... and if there isn't, there should be one.
It also feels like most of the pains on avoiding panics centers around allocations which, though a bit unfortunate, makes sense; it was an intentional design choice to make allocations panic instead of return Results, because most users of the language would probably crash on allocation fails anyways and it would introduce a lot of clutter. There was some effort some while ago on having better fallible allocations, but I'm not sure what happened over there.
If I'm not mistaken, the treatment of forward declarations proposed in the article actually breaks the C standard, which would be a rather pressing concern. As far as I am aware, that is the reason why things are the way they are right now in C land.
(In the past, there were more legitimate concerns on the ease of implementation. Nowadays, as the article points out, they are pretty moot, other than having to keep backwards-compatibility.)
I'm also rather bothered that on the bit on const execution in the article, there was no discussion on how to deal with functions that may not terminate or take rather long to execute. Especially considering the unit tests motivation, this seems like a rather blaring omission.
