[ameliaquining]

I think in this scenario it's totally germane to mention Rust because the problem described in the linked post is exactly the problem that Rust was designed to solve: providing sufficiently precise control over low-level runtime behavior that you never hit a "sorry, it's not possible to do that optimization in this language" situation, while still (arguably? hopefully?) qualifying as a "higher-level language" in the relevant sense. In particular, every problem with Java that the post describes has a straightforward solution in Rust, and this kind of thing is why Rust exists instead of, e.g., Mozilla just rewriting Firefox in an existing managed language with a garbage collector.

That being said, GP seems to imply that Rust should be the default choice for basically every problem, which goes way too far. Not every application needs this kind of low-level control. Maybe even most don't (although I look forward to a future where it's easy to drop into Rust from a managed language when you hit a performance wall; I think this has been mostly achieved for Python, but not yet for other languages). But some do, and it sure sounds like Git's one of them.

[kaba0]

Rust is a low level language no matter how productive it may be.

The memory layout will simply leak into the program architecture and will have to be altered on refactors — something which is transparent with managed languages.

[enedil]

What do you mean here by memory layout? For instance, the order of fields in a rust struct can (theoretically) change by recompiling. It's not defined by the order of fields in the definition.

[kaba0]

On a language level, high level APIs will necessarily contain details to things like (mut) reference, Box whatever. Which is not a problem at all, given the problem domain, but in my opinion it is not possible to make a both low and high level language at the same time (and it is not really needed either)

[drainyard]

Unless you add a repr(C) attribute for C interop.