The rust programming language is increasingly popular, valued for it's zero cost memory management and concurrency guarantees. Rust is safe. And it's safe while providing a low level abstraction and compatibility with the C ABI.
Of course, it's not an easy language to write in, relative to (let's say) Ruby. The type system and borrowing in Rust are amazing, but it takes longer to write Rust code because what you are expressing encompasses a complex set of constructs (think borrowing). That's OK because Rust is used for different reasons. Programs written in Rust tend to be bigger investment of time and more likely to be reused or foundational. To write code in Rust, you have to invest more effort up front to learn and then develop code with Rust.
Ousterhout's dichotomy captures this idea pretty succinctly. The distribution of programmer intent is bimodal: Quick and dirty scripting languages can forgo a lot of the formalities of types and memory management, whereas more heavy duty systems code may require sophistication in language capability. You can do the same things in the same way with Ruby or Rust, but because they operate at different scales in Ousterhauts Dichotomy, so then pushes Rust away from "the small" and towards "the large". So some languages are appropriate for writing systems code and some for writing more lightweight applications, but it's worth noting that implicit in O's dichotomy, is that scripting languages depend on and leverage investments in 'heavier' systems. For example, consider that Ruby is implemented in C-- or that the omnipresent kernel through which you are leveraging networking etc, is written in C or C++. In turn, the user value of a particular application is that it exists when needed, e.g. is easy to bang out, like writing a quick script in Ruby.
Because of Rust's safety guarantees, mixing a systems language into projects is no longer scary. You can pass parameters between both sides of Ousterhout's Dichotomy, establishing a two tiered development pattern: Rust to glue in long developed, complex libraries, and Ruby/Elixir/Python for establishing the layout of the app.
It's possible that there is a language that solves both ends of the dichotomy. Maybe it's the Julia language. I have yet to learn that language, and I suppose one must learn to use it properly in order to reconcile Ousterhout's dichotomy. The software brutalist in me prefers resist a unifying ideal, and not to absorb the contradictions inherent in Ousterhauts. Rather I would prefer to let the irregularities of arbitrary circumstances play out, perhaps overfitting the use case of two languages rather than dying for utopian language design. But the question remains, if the software ecosystem will never converge to a single language, why would a moderately complex app?