> Projects whose V1 is written in Go/Rust/C++ don't normally go out and re-write V2 in Python.
That's because you would usually rewrite your Python program in something like C++ if you realise that it's too slow and you need the speed of a compiled language, despite the enormous extra complexity to create and maintain it that way.
You wouldn't go back the other way because it's very rare to go to all that extra effort writing in a more efficient language only to realise that the slower performance of Python would've been adequate after all. And, thanks to sunk cost fallacy, even someone that does realise it is unlikely to make the switch back.
There's no way you could convince me that writing your program in C++ is easier to code in, even for a very large system, than Python. C# maybe.
> Even many famous Python packages are now Python wrappers.
Of course! That's precisely because Python is much simpler to code in. If your Python libraries are wrappers around native code then you get the speed benefit without having to drop into those languages. (Plus they can release the GIL, allowing true multithreaded Python.)
If native coding languages were good enough then there would be no need for Python wrappers - you'd just call into the native library directly.
I dont know if the reasoning for a rewrite is purely for maintainability though. Ive used python at scale and its fine if you have reasonably good code hygiene. The reason I'd want to rewrite in any of those languages is they're significantly faster _and_ are maintainable at scale.
Python is faster to write so obviously you'll see things built in Python first more often than the reverse. What's that quote -- "Better to remain silent and be thought a fool..."
Software engineers drastically underestimates GUI - Web layouts, mobile app layouts, and even PDF layouts are non-trivial pieces of work to get right in all circumstances.
Nobody who has actually worked on those things think that. You might want to qualify if you're only talking about people who have never worked in this area.
In my experience it's the NON software engineers who tend to underestimate the complexity
Yep, they (can) rarely enter your domain... so it's easy to assume its going to be trivial (maybe because things like .md or .txt files are trivial, so it's easy to think there's not much of a delta)
> At least 80% of what you’re describing would be satisfied by trains and buses. It’s wild that Americans are so obsessed with self-driving cars while ignoring public transit that solves most of the problems. It’s reliable, more efficient, better for the environment, and less stressful for you.
So, let's say you take public transport from SF to Yosemite/Los Angeles.
Now, how do I cover the last mile (or even multiple points)?
Take more public transport? Hitchhike?
The reason long-distance public transport works well in Europe is that there is good local public transport in both the source and the destination cities. When that does not exist, you are better off driving.
I'd argue it's not only not inconvenient, but also a great way of keeping your system clean of all the random system-wide dependencies you'll end up accumulating over the years.
I wrote this[1] for myself last year.
It only gives access to the current directory (and a few others - see README).
So, it drastically reduces the attack surface of running third-party Python/Go/Rust/Haskell/JS code on your machine.
Python is terrible for writing big systems.
Projects whose V1 is written in Go/Rust/C++ don't normally go out and re-write V2 in Python.
The reverse is really common.
Even many famous Python packages are now Python wrappers.
https://ashishb.net/programming/python-in-production/
reply