Hacker News Reader

Comment by Reubend | Hacker News Reader

On the one hand, I love seeing ways to make Python faster with low effort. It's awesome to see projects like this which can compile static executables. Nuitka is another cool project, but with a focus on compatibility instead of speed.

On the other hand, part of me laments the gargantuan effort people have collectively spent trying to make Python fast, rather than improving other languages to be competitive with it. Python's ecosystem is probably the biggest factor right now contributing to its popularity, but I think that without resorting to "tricks", it will never be fast (by tricks, I mean restricting usage to certain features, adding static types, forbidding the usage of popular libraries, etc)

View on HN

Talking about tricks to make python faster, there is an interesting one that is essentially exact polar opposite of what Nuitka does:

Micripython's "viper" just-in-time compiler. It can only be applied to one function at a time, restricts what you can do in such a JIT-ted function quite severely, but resulting speed is pretty much native:

https://docs.micropython.org/en/latest/reference/speed_pytho...

This is one of my favourite rants when people point to Instagram and bank python et al as evidence of people using Python being suitable for high performance use cases and those same posts amount to "we hired huge numbers of deep language Devs at likely huge cost to make an effectively custom version of python to partially address its baked in shortcomings". Its a very concrete example of the difference between "simple" and "easy" in software.

I have also seen some use case where python is use as a DSL to generate optimised C++/GPU code. For example Pythran can be use like that. This generated code will be use somewhere else like existing C++ codebase.

Which other language do you want them working on?

Compiled languages are out because you can't rebuild every time.

What is left?

>Compiled languages are out because you can't rebuild every time.

Can't really follow your argument. Any large project in a compiled language has higher compile times, that's true, but they become manageable if you don't use header copying as your include mechanism, as is common in C and C++, and if you use a build system that allows incremental builds.

Any large project in Python has a lack of compile-time guarantees leading to immense human effort in adding unit tests that would have been caught by the type system in most languages, huge debugging efforts for the resulting runtime errors that weren't caught at compile-time, etc.

Also even among the interpreted languages you could do a lot better with JIT.

In addition to rebuild times its often not possible to interact with symbols in the same way.

For example, in C++ it may not be possible to rerun a snippet of code in the debugger because those sources have been compiled out or not included.

Realistically this means that the interactive user experience is vastly reduced due to the compilation process filtering out and modifying the original code.

OP wants us to work on other languages but its hard to imagine a substantially different language that supports the same kind of user interaction. I guess we could expand on MATLAB or Octave but what would be the benefit from enabling a slightly different syntax? I think realistically the lack of advantage or differentiation from competing languages has made the proposition of contributing to other languages much less appealing.

Reply on news.ycombinator.com