The implementation technique is completely irrelevant. And the part of the comment that you quoted implies that the parent understands how it's implemented.

I'm not sure how implementation is "completely irrelevant"; if that were the case then the entire conversation is essentially irrelevant as we could potentially implement any compiled language as an interpreted language.

The piece I quoted indicates to me that the parent possibly does not understand this about JavaScript since they stated the compilation cost of JavaScript "is zero" that implies that JavaScript is not compiled. If there is a compilation step then some cost is incurred no matter how low.

It was further supported that the parent may not understand JavaScript is typically compiled when they followed on with "cost being completely amortized with everything happening directly at runtime". That would indicate that all of the cost is incurred/paid at runtime rather than in the compile step which is simply false.

The parent is talking about the costs and benefits of AOT compilation versus the lack. Whether the interpreted language uses a JIT has nothing to do with that trade-off. That's why it's irrelevant.

Also, that the parent bothered specifying "AOT" in the first place is proof enough the entire basis of your belief in their understanding of things is utterly groundless. This would be clearer to you if you understood that JIT compilation cost is amortized, as the parent alludes, and that it doesn't happen in "a" compilation step.

There is also a good transition story for porting code from Python 2 -> 3. The "problem" is largely a community issue: libraries with many dependents and a lack of authors to port them, institutions with large code-bases unwilling to port, and so forth.

The tooling hasn't been the problem. There are compatibility libraries (ie: six), source transformation tools (ie: 2to3), and plenty of books, blog posts, and talks on how to manage supporting both version of Python or doing a full port.

How is it straightforward? I tried porting a very small codebase from python 2 to 3 and ran into a bunch of issues which required manual workarounds. If it were easy to port, most library owners would have done so already.

I guess it depends on your idea of straight-forward. If you mean, "press a button and everything is done for me," then it's not very straight-forward.

If you want to port there's a well-tested and clear path. There are enough big libraries out there that have managed it. There is no real barrier as the OP suggested in their article.

My belief is that the effort os a linear function of your code base size. This means the larger the code base, the more effort required to port.

Also, porting is made more difficult by the fact that Python is a dynamic language, so a lot of errors that could be caught at compile time will only be catchable through a thorough testing suite. I have seen little evidence to suggest that porting from Python 2 to 3 is actually straightfoward in the sense of not requiring significant effort proportional to the size of the code base.

Believe what you will but the numbers suggest that it's not a technical problem to port a Python code base. It does take effort and work but it's "straight forward" in the sense that what is required is well known.

Aren't we past the tipping point? I think that at this point most old projects won't ever move to Python 3, but for new projects it's at least 50-50. If not >50 for Python 3.