4 ms·

Python is definitely more popular and its formats are naturally more widely spread. Python is also a very bad language for many of the things it is used for (a

Python is definitely more popular and its formats are naturally more widely spread. Python is also a very bad language for many of the things it is used for (anything to do with numerics, e.g. machine learning) and having a competing format from a language which is, at least in that regard, far superior seems like a good thing.

jstx1 3y ago
It's not competing if it's limited to Julia. And saving a dataframe isn't on anyone's list of technical concerns anyway. It's a big stretch to say that a tiny Julia library which does a thing we can already do well in Julia and Python and just about any other language has any impact on the language ecosystems and how they compare to each other.
- constantcrying 3y ago
  >It's not competing if it's limited to Julia. Sure, but it should.
keithalewis 3y ago
It is impossible to have an intelligent discussion with someone who only knows Python, FSVO know. Dunning-Kruger in action.
- tomrod 3y ago
  I have extensive work in Matlab, C, Fortran, R, Python, Julia, SAS (IML), and am learning Go and Rust. I have played with Java and Kotlin on non-serious projects. I typically use Python for data-related tasks. Julia is just okay. It lost its steam due to long beta, slow time to first plot after 1.0 release, and generally not being a strategically adopted language by ML innovation groups. A great example of what is versus what was hoped is John Myles White's work[0], where the headline is "worked on large community Python projects" but is one of the originators of Julia's fundamental data packages. I've had lots of intelligent people who use code as a tool instead of as a craft -- for data folks, their craft is working with data and not the tooling around it. For folks like this, Python is simply a better option in today's environment. [0] https://www.johnmyleswhite.com/about/ https://www.johnmyleswhite.com/about/
  - ssivark 3y ago
    The world is a very heterogeneous place, and we're all immersed in our own bubbles -- each with its own assumptions and needs. "Data related" is a fairly vague description. - It appears that there's substantial community effort invested in smoothing the pathway for scientific modeling and related ML. So that's one area where I expect anyone picking up Julia will see quick+substantial wins. - Recent Julia versions (1.9, 1.10 on the way) have made tremendous progress in TTFX: https://julialang.org/blog/2023/04/julia-1.9-highlights/ https://julialang.org/blog/2023/04/julia-1.9-highlights/ - I happen to work on problems (with more of a computation/simulation flavor, rather than "data related") where Python is extremely painful and Julia happens to be the best fit by far (and rapidly getting even smoother!). > I've had lots of intelligent people who use code as a tool instead of as a craft Agreed -- so there's no point being fanatical about it. Folks can keep an eye out and periodically re-evaluate whether the ecosystem has reached maturity for their needs. For those who want to "use libraries", it will take a bit longer than those who want to "write libraries". Julia aims to solve the two-language problem. If you live in Python and never have to touch another language like C or Fortran, then the value proposition of Julia is going to feel much more tenuous. But there are a set of people (library developers) who experience the ecosystem in the diametrically opposite way: https://twitter.com/dillonniederhut/status/1679140680679972864 https://twitter.com/dillonniederhut/status/16791406806799728... > and generally not being a strategically adopted language by ML innovation groups. I see the tremendous engineering effort being sunk to massage different (mutually incompatible) subsets of Python into some shape amenable for ML -- supporting new algorithms on top, and more efficient program execution at the bottom (translating from software to hardware). I've heard the claim that it's sometimes better to delay a solution and let the users feel the pain before they open their minds to the solution. That is what I'm reminded of when I think of ML and Julia. If ML users don't see the value of Julia yet, that's okay -- they might once they dig themselves in deeper. If they manage to solve all ML problems with Python (with C and what not), that's fine too! I think the world is a bigger place where there are also other interesting things going on, and Julia is helping a lot of people do things they couldn't accomplish otherwise :-) -- There's no fundamental reasons for languages to "age", unless they happen to be tied to some unsuitable assumptions in how they model the world -- aspects that cannot be rearchitected without fundamentally changing the language. Barring that problem, languages only get more mature. The problem with Python is not that it is three decades old, but that its revealed priorities (model of the world and software) is out of sync with many of today's needs. Even if we forget advanced things like ML, there's still a bunch of really basic stuff that make Python painful: https://twitter.com/dmimno/status/1679474354579488771 https://twitter.com/dmimno/status/1679474354579488771 I think the design of Julia is much more robust in those aspects, but we also need to see how multiple dispatch plays out for very large codebases+teams. Meanwhile, I expect Julia will keep improving rapidly in the use cases it supports.

jstx1 3y ago

It's not competing if it's limited to Julia. And saving a dataframe isn't on anyone's list of technical concerns anyway. It's a big stretch to say that a tiny Julia library which does a thing we can already do well in Julia and Python and just about any other language has any impact on the language ecosystems and how they compare to each other.

constantcrying 3y ago
>It's not competing if it's limited to Julia. Sure, but it should.

keithalewis 3y ago

It is impossible to have an intelligent discussion with someone who only knows Python, FSVO know. Dunning-Kruger in action.

tomrod 3y ago
I have extensive work in Matlab, C, Fortran, R, Python, Julia, SAS (IML), and am learning Go and Rust. I have played with Java and Kotlin on non-serious projects. I typically use Python for data-related tasks. Julia is just okay. It lost its steam due to long beta, slow time to first plot after 1.0 release, and generally not being a strategically adopted language by ML innovation groups. A great example of what is versus what was hoped is John Myles White's work[0], where the headline is "worked on large community Python projects" but is one of the originators of Julia's fundamental data packages. I've had lots of intelligent people who use code as a tool instead of as a craft -- for data folks, their craft is working with data and not the tooling around it. For folks like this, Python is simply a better option in today's environment. [0] https://www.johnmyleswhite.com/about/ https://www.johnmyleswhite.com/about/
- ssivark 3y ago
  The world is a very heterogeneous place, and we're all immersed in our own bubbles -- each with its own assumptions and needs. "Data related" is a fairly vague description. - It appears that there's substantial community effort invested in smoothing the pathway for scientific modeling and related ML. So that's one area where I expect anyone picking up Julia will see quick+substantial wins. - Recent Julia versions (1.9, 1.10 on the way) have made tremendous progress in TTFX: https://julialang.org/blog/2023/04/julia-1.9-highlights/ https://julialang.org/blog/2023/04/julia-1.9-highlights/ - I happen to work on problems (with more of a computation/simulation flavor, rather than "data related") where Python is extremely painful and Julia happens to be the best fit by far (and rapidly getting even smoother!). > I've had lots of intelligent people who use code as a tool instead of as a craft Agreed -- so there's no point being fanatical about it. Folks can keep an eye out and periodically re-evaluate whether the ecosystem has reached maturity for their needs. For those who want to "use libraries", it will take a bit longer than those who want to "write libraries". Julia aims to solve the two-language problem. If you live in Python and never have to touch another language like C or Fortran, then the value proposition of Julia is going to feel much more tenuous. But there are a set of people (library developers) who experience the ecosystem in the diametrically opposite way: https://twitter.com/dillonniederhut/status/1679140680679972864 https://twitter.com/dillonniederhut/status/16791406806799728... > and generally not being a strategically adopted language by ML innovation groups. I see the tremendous engineering effort being sunk to massage different (mutually incompatible) subsets of Python into some shape amenable for ML -- supporting new algorithms on top, and more efficient program execution at the bottom (translating from software to hardware). I've heard the claim that it's sometimes better to delay a solution and let the users feel the pain before they open their minds to the solution. That is what I'm reminded of when I think of ML and Julia. If ML users don't see the value of Julia yet, that's okay -- they might once they dig themselves in deeper. If they manage to solve all ML problems with Python (with C and what not), that's fine too! I think the world is a bigger place where there are also other interesting things going on, and Julia is helping a lot of people do things they couldn't accomplish otherwise :-) -- There's no fundamental reasons for languages to "age", unless they happen to be tied to some unsuitable assumptions in how they model the world -- aspects that cannot be rearchitected without fundamentally changing the language. Barring that problem, languages only get more mature. The problem with Python is not that it is three decades old, but that its revealed priorities (model of the world and software) is out of sync with many of today's needs. Even if we forget advanced things like ML, there's still a bunch of really basic stuff that make Python painful: https://twitter.com/dmimno/status/1679474354579488771 https://twitter.com/dmimno/status/1679474354579488771 I think the design of Julia is much more robust in those aspects, but we also need to see how multiple dispatch plays out for very large codebases+teams. Meanwhile, I expect Julia will keep improving rapidly in the use cases it supports.