Hacker News
points by ModernMech 2 days ago | 0 comments
However because of this, Julia has has persistent problems with "time to first plot", which has gotten better, but they cannot fully ameliorate due to the way it fundamentally works. So there are tradeoffs -- the performance gets better, but the interpreted REPL experience is markedly worse.
[–] FacelessJim 2 days ago
By the way, the current nightly (especially if considering the optimized build) has a very substantial TTFX drop compared to the current release [1]

[1] https://perf.julialang.org/?tab=overview

[–] StefanKarpinski 22 hours ago
It's not unavoidable, it just hasn't yet been avoided. It could be avoided the same way as other JITs: by interpreting until a compiled version of the code is available. That's actually being worked on, but it adds considerable complexity. Among other things, it requires being able to jump out of an executing interpreter loop into an optimized, compiled version of the same function. Doable, but annoying to implement and requires compiling two versions of the function instead of one. It can also cause performance instability — see https://tratt.net/laurie/blog/2022/more_evidence_for_problem... and the older paper referenced there.
[–] pjmlp 2 days ago
It is overly exaggerated, especially when taken into account how long it takes to compile native libraries that people keep calling "Python" libraries, if there isn't a suitable wheel for the current environment.
[–] ModernMech 2 days ago
I think it's true that it's exaggerated, but that doesn't mean the tradeoff doesn't exist.
[–] pjmlp 2 days ago
A tradeoff that doesn't make sense to complain about, when the alternative is waiting for native libraries being compiled, in a mix of C, C++, Fortran and more recently Rust.

A pain point that is big enough that at least two programming languages, Julia and Mojo, were created to move beyond it.

Which would not even be an issue, if Lisp, Scheme and Prolog had not lost their aura among AI devs.

[–] ModernMech 2 days ago
Julia and Mojo are attempts at solving the "two language problem", which not every Python user actually has -- they're fine doing work exclusively in Python, not even using any of the libraries you're talking about.

Mojo in particular recognized to compete with Python they'd have to be a superset, then they backed of that goal when they realized it would be too hard.

So at the end of the day, Python has a value proposition and it cannot be entirely subsumed by other languages, because those languages make tradeoffs that move away from Python's value.

[–] pjmlp 2 days ago
Python's value is being a portable scripting language, a better Perl, unfortunately some try to do full blown applications with an interpreted language.
[–] necovek 2 days ago
Perhaps it's worse that some even succeed in building very complex systems that can handle a lot of load too (see eg. Instagram)? ;-)

Python has a known set of trade-offs, mostly related to loop performance. But if you understand the trade-offs and available mitigations, it should not stop you from building good software. You know, just like any other ecosystem.