> Hm. Ok. Tell it to my previous company running 12 million LoC of Python.
Just because it can be done, doesn't mean it should be done. Just my opinion.
> It was easier to make changes there than in the 500k loc c++ system I maintained later.
I don't consider C++ a good language in any way, shape, or form. Now had you claimed the same about OCaml, Kotlin, etc. I would have a harder time believing it.
> Language has nothing to do with success of large projects,
Of course it does, but they do not exist in isolation either - it is just one component. There are many factors that would play in.
> it’s everything around it. The culture of the company, the cicd systems, the release system, the build system, packaging, documentation , rollback, dependencies.
My point about python is that it literally _requires_ you to make up for language deficiencies (aka dynamic typing + unchecked exceptions) by testing insane amounts to even make it possible. The things that work against you at large scale, work for you at tiny scale (aka scripts).
Heheh company with 14 million LoC barely had tests :)
I don’t know what kind of companies you worked on, but let me tell you that the code that runs the world comes from an era before tests, and some of it is too complicated to even be tested.
Test it in production is the only way for a lot of it. Then you need observability and easy ways of rolling back. That’s about it. Regardless of the language.
Read the latest google book — code architects at google I think it’s called ? Has a couple of great chapters on testing at scale and how unittests are useless
Just because it can be done, doesn't mean it should be done. Just my opinion.
> It was easier to make changes there than in the 500k loc c++ system I maintained later.
I don't consider C++ a good language in any way, shape, or form. Now had you claimed the same about OCaml, Kotlin, etc. I would have a harder time believing it.
> Language has nothing to do with success of large projects,
Of course it does, but they do not exist in isolation either - it is just one component. There are many factors that would play in.
> it’s everything around it. The culture of the company, the cicd systems, the release system, the build system, packaging, documentation , rollback, dependencies.
My point about python is that it literally _requires_ you to make up for language deficiencies (aka dynamic typing + unchecked exceptions) by testing insane amounts to even make it possible. The things that work against you at large scale, work for you at tiny scale (aka scripts).