React's dangerouslySetInnerHTML is indeed a good way of handling this kind of thing. Rust's `unsafe` is another example of the same approach.
Rust's "unsafe" is a pretty bad name and completely different reasoning behind using it. It doesn't mark something as "dangerously unsafe, don't use", to a consumer it indicates "exercise caution" and to a compiler it just allows 5 things:
Dereference a raw pointer
Call an unsafe function or method
Access or modify a mutable static variable
Implement an unsafe trait
Access fields of unions
`dangerouslySetInnerHTML` is literally dangerous and allows XSS if used with outside input.
It also is faster than the other variant. The same is true for `random()`. Both can be used when you know what are you doing to gain some performance.
Meanwhile, `unsafe` rust by itself is not different from safe rust in terms of speed. You have no choice, but to use it places it supposed to be used.
Likewise `unsafe` marks areas where you need to be really careful that you upholding the safety invariants yourself, whereas in normal Rust code you don't need to think about that at all.
The word 'safe' in Rust has a very specific, technical meaning. 'unsafe' is simply code that is not automatically 'safe' in the Rust sense.
A non-Rust developer sees safe/unsafe and gets worked up, but that just means that he should put his rust-colored glasses [*] on.
This is not unusual in ICT, known for its colorful language. A non-ICTer hears 'black hat' and thinks about how cool and stylish the hat is. An ICTer hears 'hacker' and thinks about how cool and stylish the hack is.
[*] Thanks, Raymond!