5 ms·

I think the Julia people underestimate how many people, and how much those people, like the syntax of Python. If they'd stuck more to that they might have been

I think the Julia people underestimate how many people, and how much those people, like the syntax of Python. If they'd stuck more to that they might have been able to have won more people over.. (white space, plus many other things).

jarbus 4y ago
As someone who switched from python to Julia, Julia syntax supports things like list comprehensions, but also many better things like broadcasting that python really needs. The only thing python has over Julia is that Julia requires an “end” keyword where python uses indentation. But julia has so much more than python (like macros) that it’s just better syntax wise.
- BerislavLopac 4y ago
  Python has macros too.
  - adgjlsfhk1 4y ago
    as of 2020 (PEP 638), python has macros (but they're still slightly janky). Before that there were decorators which look kind of similar but are a lot less powerful.
    - nerpderp82 4y ago
      Are they implemented anywhere? It looks like the PEP is draft. You can do all the macro like things you want using framehacks and eval at the top level. Where they are hard to apply w/o direct support is down inside some function. Then you have to bytecode patch the result on first execution.
    - mathisfun123 4y ago
      > as of 2020 (PEP 638) >> Reference Implementation >> None as yet. > but they're still slightly janky maybe you're from the future?
    - BerislavLopac 4y ago
      Not just decorators, but all kinds of functionalities that allowed types to be constructed at runtime.
  - xiaodai 4y ago
    well. python has ALOT of stuff but alot of it is garbage compared to how they should be done. like python's lambda, you literally have to write the word lambda. it's ugly af i bet the python macros will be ugly af too. also walrus operator = bdfl no more.
acmj 4y ago
It is not just syntax. While python has Java-like OOP from a far, Julia has a distinct language design. It doesn't have a concept of "class" in the traditional sense. It instead has multiple dispatch, which is very flexible but sometimes too flexible to control. I found Julia harder to write for an averaged programmer. Furthermore, the time-to-first-plot problem had pissed off many early adopters (I know a few and they won't come back) and apparently remains a problem for some [1]. Julia is a great niche language for what it is good at. It will survive but won't gain much popularity. [1] https://discourse.julialang.org/t/very-slow-time-to-first-plot-2022/88968/60 https://discourse.julialang.org/t/very-slow-time-to-first-pl...
- emcemc 4y ago
  Time to first plot should be all but solved as of v1.9.0 (first stable release ~two days ago).
  - adgjlsfhk1 4y ago
    Technically we've only released the first release candidate for 1.9. There's still a few bugs in it, and we'll probably have at least 1 more release candidate before 1.9.0 is released.
  - jakobnissen 4y ago
    It's not going to be solved. Stop saying this. It's a great step forward and a real user experience improvement, but it doesn't solve it. Packages need to precompile, and they don't. They need to fix invalidations, and they don't. They need to fix inference issues in their packages and they don't. "Using" time remains quite high.
  - xiaodai 4y ago
    "solved" is a big claim. better to just let the speed speaks for itself. ttfp is still somewhat of an issue
- jakobnissen 4y ago
  There are even more issues with Julia than you mention there. But the point is there are _many issues_ with _every_ programming language: Python is slow, its package management story is a dumpster fire, its object model is bizarre and confusing, its typechecking mechanism sucks. Also, its documentation is terrible (docstrings and documentation of functions) and the built-in REPL is basically useless. Rust has slow compile times, too much macro magic leading to unreadable code, the 90% of what the borrow checker rejects is perfectly fine code, its trait coherence rules are too restrictive, async sucks, and it's totally unsuitable for quick experimentation. These are all real limitations, but users of these languages learn to live with them. Rustacenans learn to start a build, then so something else while it builds. That is, on its face, totally unacceptable to a Pythonista. Pythonistas learn to always ship performance sensitive applications with _another language_ doing all the hard work: Totally unacceptable for a Rustacean. If someone tries out Python, spends five minutes getting package management to work and fails, they have not seriously thought about Python as a language. I feel people do just that with Julia: Try it out, then reject it on the first rough edge. Fair enough: There are many people for whom lack of static type checking or Julia's latency is a showstopper, making the language unsuitable. But I'm still firmly convinced that for scientists/engineers at least, Julia, on balance, offers a better language than Python. I hope you're wrong that it won't gain much popularity.
amval 4y ago
One of the features that I dislike the most abiout Julia is how list comprehensions have been directlly ported from Python. This was a conscious choice they made out of pragmatism, not because of the merits of the design. I don't doubt that what you say it's true, but to me, it comes down more to lack of familiarity with other languages than any actual merits of Python syntax and semantics. Frankly, I am glad the didn't take more from Python.

jarbus 4y ago

As someone who switched from python to Julia, Julia syntax supports things like list comprehensions, but also many better things like broadcasting that python really needs. The only thing python has over Julia is that Julia requires an “end” keyword where python uses indentation. But julia has so much more than python (like macros) that it’s just better syntax wise.

BerislavLopac 4y ago
Python has macros too.
- adgjlsfhk1 4y ago
  as of 2020 (PEP 638), python has macros (but they're still slightly janky). Before that there were decorators which look kind of similar but are a lot less powerful.
  - nerpderp82 4y ago
    Are they implemented anywhere? It looks like the PEP is draft. You can do all the macro like things you want using framehacks and eval at the top level. Where they are hard to apply w/o direct support is down inside some function. Then you have to bytecode patch the result on first execution.
  - mathisfun123 4y ago
    > as of 2020 (PEP 638) >> Reference Implementation >> None as yet. > but they're still slightly janky maybe you're from the future?
  - BerislavLopac 4y ago
    Not just decorators, but all kinds of functionalities that allowed types to be constructed at runtime.
- xiaodai 4y ago
  well. python has ALOT of stuff but alot of it is garbage compared to how they should be done. like python's lambda, you literally have to write the word lambda. it's ugly af i bet the python macros will be ugly af too. also walrus operator = bdfl no more.

acmj 4y ago

It is not just syntax. While python has Java-like OOP from a far, Julia has a distinct language design. It doesn't have a concept of "class" in the traditional sense. It instead has multiple dispatch, which is very flexible but sometimes too flexible to control. I found Julia harder to write for an averaged programmer. Furthermore, the time-to-first-plot problem had pissed off many early adopters (I know a few and they won't come back) and apparently remains a problem for some [1]. Julia is a great niche language for what it is good at. It will survive but won't gain much popularity. [1] https://discourse.julialang.org/t/very-slow-time-to-first-plot-2022/88968/60 https://discourse.julialang.org/t/very-slow-time-to-first-pl...

emcemc 4y ago
Time to first plot should be all but solved as of v1.9.0 (first stable release ~two days ago).
- adgjlsfhk1 4y ago
  Technically we've only released the first release candidate for 1.9. There's still a few bugs in it, and we'll probably have at least 1 more release candidate before 1.9.0 is released.
- jakobnissen 4y ago
  It's not going to be solved. Stop saying this. It's a great step forward and a real user experience improvement, but it doesn't solve it. Packages need to precompile, and they don't. They need to fix invalidations, and they don't. They need to fix inference issues in their packages and they don't. "Using" time remains quite high.
- xiaodai 4y ago
  "solved" is a big claim. better to just let the speed speaks for itself. ttfp is still somewhat of an issue
jakobnissen 4y ago
There are even more issues with Julia than you mention there. But the point is there are _many issues_ with _every_ programming language: Python is slow, its package management story is a dumpster fire, its object model is bizarre and confusing, its typechecking mechanism sucks. Also, its documentation is terrible (docstrings and documentation of functions) and the built-in REPL is basically useless. Rust has slow compile times, too much macro magic leading to unreadable code, the 90% of what the borrow checker rejects is perfectly fine code, its trait coherence rules are too restrictive, async sucks, and it's totally unsuitable for quick experimentation. These are all real limitations, but users of these languages learn to live with them. Rustacenans learn to start a build, then so something else while it builds. That is, on its face, totally unacceptable to a Pythonista. Pythonistas learn to always ship performance sensitive applications with _another language_ doing all the hard work: Totally unacceptable for a Rustacean. If someone tries out Python, spends five minutes getting package management to work and fails, they have not seriously thought about Python as a language. I feel people do just that with Julia: Try it out, then reject it on the first rough edge. Fair enough: There are many people for whom lack of static type checking or Julia's latency is a showstopper, making the language unsuitable. But I'm still firmly convinced that for scientists/engineers at least, Julia, on balance, offers a better language than Python. I hope you're wrong that it won't gain much popularity.

amval 4y ago

One of the features that I dislike the most abiout Julia is how list comprehensions have been directlly ported from Python. This was a conscious choice they made out of pragmatism, not because of the merits of the design. I don't doubt that what you say it's true, but to me, it comes down more to lack of familiarity with other languages than any actual merits of Python syntax and semantics. Frankly, I am glad the didn't take more from Python.