6 ms·

very exciting to see big things built in Julia! I use it for hobby projects and would love to see the language develop to broader audiences

WanderPanda 3y ago
I agree with the sentiment but "big things" != broader audience
pjmlp 3y ago
As language nerd,and given its relationship to Lisp and Dylan ideas, I enjoy it being adopted, even in a specific niche. Moreso I would enjoy that somehow pressures Python folks to care about having a JIT in the box. The only major mainstream scripting language left without one. There are still Perl, Tcl, and Awk, however their use isn't as widespread nowadays.
- phkahler 3y ago
  PyPy exists, just not in the box.
  - pjmlp 3y ago
    Which is a huge pain point regarding adoption, as proven by how long it has been largely ignored on the Python community.
  - xvilka 3y ago
    It's not scalable because it's a resource hog. Other languages JIT require much less. I think that's the biggest obstacle to its wider adoption.
    - eigenspace 3y ago
      That's not the problem with PyPy. The relevant problems problems with PyPy are that it 1. Only offers a performance benefit relative to CPython. Compared to other languages, it's still VERY slow 2. Breaks the ABIs that Python libraries written in C rely on. This means that PyPy is incompatible with almost every major Python package worth using, since nobody writes serious python packages in Python (because it's too slow).
- eigenspace 3y ago
  Having a JIT is not a magic bullet. The reason so many different JITs for Python have been developed, yet none have seen widespread adoption is that Python's semantics are anathema to optimizing compilers. Julia was designed specifically to have language semantics that would make compiler optimizations as easy as possible without sacrificing usability. Bolting an efficient, all-language compiler onto Python post-hoc is essentially impossible without fundamental changes to the language.
  - gugagore 3y ago
    I would like to understand why JavaScript semantics have allowed for a lot of performance, but Python semantics hasn't.
    - eigenspace 3y ago
      I'm actually not very experienced with JavaScript, but my understanding is that it comes down to that Python's foreign function interface is tightly bound up with the implementation details of CPython. This means that unless you want to lose access to the whole Python ecosystem, your JIT compiler needs to jump through an impossible series of hoops to support existing libraries As far as I understand, in practice, JavaScript code relies less on foreign function interfaces to code that's written in other languages (because you can't reliably do that in a browser). This point makes it so that important JavaScript packages tend to be written in JavaScript, whereas important Python packages tend to be written in C or Fortran or Rust or whatever. If a JIT compiler for Javascript changes how FFI works, then that's less big of a deal. Again though, not very knowledgable about JavaScript, so if someone wants to come and correct me, or offer additional context, I'd be very appreciative.
  - pjmlp 3y ago
    The usual argument from those that never saw Common Lisp, Smalltalk and SELF JITs, languages that are even more dynamic than Python, with constructs that can change the meaning of object instances across all application space and image, and their actual structure is dynamically constructed via metaclasses, much more powerful than what Python metaclasses can do. It is getting tired by now.

WanderPanda 3y ago

I agree with the sentiment but "big things" != broader audience

pjmlp 3y ago

As language nerd,and given its relationship to Lisp and Dylan ideas, I enjoy it being adopted, even in a specific niche. Moreso I would enjoy that somehow pressures Python folks to care about having a JIT in the box. The only major mainstream scripting language left without one. There are still Perl, Tcl, and Awk, however their use isn't as widespread nowadays.

phkahler 3y ago
PyPy exists, just not in the box.
- pjmlp 3y ago
  Which is a huge pain point regarding adoption, as proven by how long it has been largely ignored on the Python community.
- xvilka 3y ago
  It's not scalable because it's a resource hog. Other languages JIT require much less. I think that's the biggest obstacle to its wider adoption.
  - eigenspace 3y ago
    That's not the problem with PyPy. The relevant problems problems with PyPy are that it 1. Only offers a performance benefit relative to CPython. Compared to other languages, it's still VERY slow 2. Breaks the ABIs that Python libraries written in C rely on. This means that PyPy is incompatible with almost every major Python package worth using, since nobody writes serious python packages in Python (because it's too slow).
eigenspace 3y ago
Having a JIT is not a magic bullet. The reason so many different JITs for Python have been developed, yet none have seen widespread adoption is that Python's semantics are anathema to optimizing compilers. Julia was designed specifically to have language semantics that would make compiler optimizations as easy as possible without sacrificing usability. Bolting an efficient, all-language compiler onto Python post-hoc is essentially impossible without fundamental changes to the language.
- gugagore 3y ago
  I would like to understand why JavaScript semantics have allowed for a lot of performance, but Python semantics hasn't.
  - eigenspace 3y ago
    I'm actually not very experienced with JavaScript, but my understanding is that it comes down to that Python's foreign function interface is tightly bound up with the implementation details of CPython. This means that unless you want to lose access to the whole Python ecosystem, your JIT compiler needs to jump through an impossible series of hoops to support existing libraries As far as I understand, in practice, JavaScript code relies less on foreign function interfaces to code that's written in other languages (because you can't reliably do that in a browser). This point makes it so that important JavaScript packages tend to be written in JavaScript, whereas important Python packages tend to be written in C or Fortran or Rust or whatever. If a JIT compiler for Javascript changes how FFI works, then that's less big of a deal. Again though, not very knowledgable about JavaScript, so if someone wants to come and correct me, or offer additional context, I'd be very appreciative.
- pjmlp 3y ago
  The usual argument from those that never saw Common Lisp, Smalltalk and SELF JITs, languages that are even more dynamic than Python, with constructs that can change the meaning of object instances across all application space and image, and their actual structure is dynamically constructed via metaclasses, much more powerful than what Python metaclasses can do. It is getting tired by now.