I agree with some of the things you say... mostly with the "use the right tool for the right job". In that sense, C might not be the most sensible choice for so

I agree with some of the things you say... mostly with the "use the right tool for the right job". In that sense, C might not be the most sensible choice for some things where you can end up with a solution that is twice as slow or more (and it's acceptable) but a lot easier to code and maintain. But if it several orders of magnitude slower? ... I just used C as an example of something that is obvious to reason about when comparing the alternative. Portability comes with a price. And the more you abstract away from hardware the less you will be able to use it to its full potential. Most of the code written in these times it's not designed around things like cache locality for example and we have code that is 100 times as slow as they should be... even in plain C! That said, we can agree that right now (more or less) you can reason about cache locality (for example) in "traditional" languages (even in Javascript... to some extent) and keep your distance from bare metal. But you lose the ability to reason about that and other things by using a PL so focused in writing beautiful mathematical expressions. For me, that's a deal breaker.