>In the same interview he also mentions using python a lot lately and making the point that for the vast majority of code, performance really doesn't matter and productivity is more important.

Until it does matter. Then it *really* matters at which point you're normally looking at a bottom up rewrite and likely retooling and rehiring for new skills.

Ive been bitten by "oh it's just a prototype" a few too many times now.

I guess it might be my lack of experience, but why are rewrites bad ?

It's a prototype because when you start a project :

- you don't understand what the client wants

- the client themselves don't really understand what they need (and sometimes, not even what they want, which is magnified as soon as you have to deal with multiple people)

- you might not know how to achieve that

- you might have an idea how to achieve that, but not have practical experience in it

- reality (including funding limitations) restricts what solutions can be implemented

- the usual code entropy...

Given all of the above, why would you NOT do a bottom up rewrite at least once ?!

P.S.: And in the cases the performance critical bits can be isolated, Python can outsource those to performant languages like FORTRAN or C.

I am guessing the answer usually is : the funding doesn't come directly from the end user, and so the incentives are not aligned for a successful project - which also explains why software projects have such poor success rates (~10%) ?

“It’s just a prototype,” can be bad if you are doing half baked things to get them done quickly, telling yourself you will rewrite for production.

A pattern I’ve frequently seen is schedule pressure mounts and when you need to scale back on scope to meet a deadline, rewrites are the first to go.

I’d guess a good portion of the garbage people inherit from others fits into this category.

One could always create a native python module in Rust/other and call it from Python. It might not work for videogames, for instance, but ML seems to do fine with this approach, and they require a lot of performance from the GPU.

So spend the time doing the hard bit, then introduce some complexity and a software turducken for the sake of calling it from a "simple" language. At which point I'd then ask the question are we really so scared of someone accusing us of overengineering that we're creating more complicated solutions to appear simple and pretending the complexity doesn't exist?

This is basically how Python is useful, calling native modules.

It might not be aesthetically pleasant but it works.

If we think about it, most of the time you do not need to do that because some library author has already done it.

If one needs to write the native code it is not overengineering. It is only overengineering if it was not needed in the first place.

>Reading this article, he's making a great argument for Rust.

I think his points are related to an approach which generally reduces complexity and errors. Parts of that philosophy are embodied by Rust but are not exclusive to it.

I also don't know if Rust aligns well with the goal of reducing complexity. Programming in Rust gets really bogged down into thinking about programming language abstractions rather solving whatever problem you need to solve.

In the same interview he also says that he's not fit to pass judgment on Rust even though he's used it.