9 ms·

Julia is a nice language, it's just tough to compete with Python. - The beginner experience in Julia is still much worse than it is in Python. Stuff that shoul

Julia is a nice language, it's just tough to compete with Python. - The beginner experience in Julia is still much worse than it is in Python. Stuff that should work intuitively sometimes doesn't, and when you get a cryptic error message, it's difficult to find relevant help online. And when you do find help, some of it is out of date because the language has changed over the past few years. - You can squeeze a lot of performance out of Python and the ecosystem of libraries is hard to beat. - Julia has to be way better than Python to give people an incentive to switch. Being just marginally better in some aspects of the language isn't enough. And it's very difficult to be much better than Python especially in useability and ecosystem.

ForHackernews 6y ago
You can call Python directly from Julia https://github.com/JuliaPy/PyCall.jl https://github.com/JuliaPy/PyCall.jl so much of the Python library ecosystem (say, matplotlib) is available to be used in Julia programs. That helps the adoption story quite a bit. You can do the number-crunching in Julia where performance counts, and then analyse and present the results using Python.
- superbcarrot 6y ago
  - Using Python directly is a better experience than calling Python from Julia - I've never run into unsolveable performance issues with Python So I guess I'm not in the target audience unless I just happen to be curious about a new language? That's kind of my overall point - even if Julia is a good language on its own and I work in data science, I don't have reasons to pick it over Python.
  - pjmlp 6y ago
    Except when Python fails, the option is to write C, in Julia I can carry on writing Julia.
  - galangalalgol 6y ago
    If you haven't hit a brick wall with python, it is just because you haven't run into the right problem. I was doing something that required lots of conditional operations on small matrices. The FFI into numpy's native library really bogged it down. I didn't have permission to install a compiler on that machine so I wrote it in vba in excel. It was 11x faster.
alephnil 6y ago
Julia has the focus on scientific and numerical computing, and is overtaking the python/numpy combo in that niche. In addition to being considerably faster than python, it also has quite some innovative libraries in the area. This can also extend into machine learning, where python has been the go to language, despite its limitations. For other areas, like web programming, there is no sign of Julia replacing Python in the forseable future.
- superbcarrot 6y ago
  > and is overtaking the python/numpy combo in that niche No, it's isn't. Julia is growing but it's far from overtaking Python at this point. > For other areas, like web programming, there is no sign of Julia replacing Python in the forseable future. That's where Go comes in.
  - bsdubernerd 6y ago
    I second this. Python is actually starting to get significant traction in the scientific community. Depending on the field, R, Fortran and Matlab (and even C++) still have a huge lead. It's nice that Julia is getting noticed, but it's a distant blip in the radar. The sci community is really hard to move from existing battle-tested and performant libraries.
    - oefrha 6y ago
      I don’t have much insight on the scientific computing landscape in general, but here’s one notable data point: I worked on the CMS experiment of LHC (Large Hadron Collider) for a while, which is one of the highest profile experiments in experimental physics. The majority of CMS code is C++, which you can check for yourself at https://github.com/cms-sw/cmssw https://github.com/cms-sw/cmssw (yes, much/most? of the code is open source). What I worked on specifically was prototyped in Python, then ported to C++ and plugged into the massive data processing pipeline where performance is critical due to the sheer amount of data. So I probably wouldn’t put C++ in parentheses.
      - 6y ago
shiftingleft 6y ago
I think this is a fair assessment, and would like to add that the "time to first plot" is also quite the usability issue. Julia is using LLVM for code-gen has to compile a lot of code before you can actually use stuff like plots. It takes ages to get a Pluto Notebook up and running, while a jupyter notebook is available instantly.
- enriquto 6y ago
  Wait, why can't you use a regular jupyter notebook for julia? The "ju" in "jupyter" stands for what, then?
  - jakobnissen 6y ago
    You can, but Pluto is (I would argue) a better notebook than Jupyter. Regardless, the latency experienced with Julia applies equally whether you use Pluto, Jupyter, or any other front-end.
    - carterschonwald 6y ago
      Pluto is a notebook design the world needs. It’s nice enough for it to motivate me to use Julia for some new prjects. But yeah latency kills :)
  - spacedome 6y ago
    You absolutely can use regular jupyter notebooks for julia! Pluto has some advantages, like being stored as a normal julia file. The julia startup time issues affect both.
    - enriquto 6y ago
      > being stored as a normal julia file. Oh, man, this is indeed a major feature. My main point of friction with jupyter notebooks is the stupid json ipynb format. Why can't it be just a regular language file with comments?
bluenose69 6y ago
This is an insightful and level-headed comment that applies equally to R. Although Julia is a growing alternative to Fortran/C/etc for long-running computations, it remains awkward and unpleasant for interactive analysis. Users familiar with Python/R/etc must weight the benefits of Julia against its slow library startup, its cryptic error messages, and its thin documentation. Also, the lack of a community repository for well-vetted Julia libraries can limit uptake by professional researchers who must be able to trust their tools. A real strength of R (in comparison not just to Julia but also to python) is that such a repository exists, and that it has automated testing across a range of computer architectures and versions of R, including not just unit testing within individual libraries, but also testing of related libraries.
- disgruntledphd2 6y ago
  Yeah, the R community owes a lot of it's stability to Uwe Ligges, and his (sometimes annoying) insistence on CRAN package quality.
- BadInformatics 6y ago
  > Julia is a growing alternative to Fortran/C/etc for long-running computations, it remains awkward and unpleasant for interactive analysis Did you mean to write short-running scripts? If anything, the Julia dev workflow is biased towards interactive analysis in a REPL a la R or IPython/Jupyter. I don't mean to imply that there's no startup overhead, but how often are you restarting the REPL when doing EDA? Unless it's more than once every few minutes (which is a very odd workflow), then startup overhead is effectively amortized. > A real strength of R (in comparison not just to Julia but also to python) is that such a repository exists CRAN is certainly a cut above many other package repos here, but I'm not sure "trust their tools" can apply to all packages on there. Anecdotally, I've had a lot of issues with compiled dependencies and missing/out of date external assets on less well-trodden packages. There's a reason MRAN, Conda and JuliaBinaryWrappers exist after all. For whatever reason, Julia package maintainers also seem more receptive to making their work compatible with other libraries as well. This goes beyond just multiple dispatch as well--imagine if tidyverse/non-tidyverse wasn't such a hard split.
ptero 6y ago
I think your "ecosystem of python libraries" is the key point. Python got a lot of mileage for a mass adoption from ML. Its libraries provided an "easy ML" for masses at the time ML got popular in science and job market, which quickly brought it into mainstream and built up its network effect. A similar enabler in a new field could help Julia burst in as a general language. My 2c.
- chalst 6y ago
  Autodiff is a place where there is a gulf between Julia and Python, one that I think can't be bridged well: JuliaDiff is astonishingly flexible and performant. https://www.juliadiff.org/ https://www.juliadiff.org/
  - oxinabox 6y ago
    Urg that website is so incredibly out of date. Julia has amazing things for autodiff. But like not the things listed on that website. Also python is still doing great with Jax and PyTorch.
    - chalst 6y ago
      I linked to the website (which was updated in May, but its contents could do with more work) because it has examples of how well the suite fits together. I don't know much about Jax. I've seen competent benchmarks showing an order of magnitude benefit for using ReverseDiff from the AutoDiff suite over Autograd, which is what Pytorch uses for reverse-mode autodiff
      - oxinabox 6y ago
        It was update in May to fix that the CDN changed. The actual content hasn't been updated in 7 years. It really should be updated to have basically the content of this thread https://discourse.julialang.org/t/state-of-automatic-differentiation-in-julia/43083 https://discourse.julialang.org/t/state-of-automatic-differe...
melling 6y ago
Python used to be tough to compete with Perl. But then times change... It’s usually the tooling and libraries. Now I don’t want to go back to Perl. And I’d certainly be willing to give Julia a try.
- canadianfella 6y ago
  Did you know Perl is only 4 years older than Python? I found that to be unexpected.
uncrex 6y ago
> way better People like to substitute "10x better" here but I think the real number is 100,000x better, aka it's not possible by default. Q: What it would take to replace Windows? A: iPhone was a new product category that targetted a new market.
- jakobnissen 6y ago
  It does happen, though. C has mostly replaced FORTRAN for scientific applications. Not entirely, FORTRAN is (infamously) still used, but I don't know anyone who has started a new project with FORTRAN. Just 6 years ago, I was taught Perl in my Introduction to Bioinformatics course. The teachers were still using Perl because it used to be the go-to language for bioinformaticians. The year after, and every year since, they've taught using Python.
  - evgen 6y ago
    The idea that people were being forced to learn perl just for bioinfomatics as recently as 6 years ago fascinates me. Python has gotten exceptionally lucky. I am sure the two or three remaining perl users on the planet are also on HN and ready to jump to its defense, but to me this just goes to show you how heavy the switching cost is for something like this is and also how lucky python was to have been the best language to switch to at this point. It was in the right place at the right time for a lot of these switches away from older languages in obvious decline and then it was able to leverage numpy and scikit to pick up a lot of additional momentum in ML and data science tasks. It is almost never the 'best' language for the job, but coming in as second choice on most tasks is a huge win. Jack of all trades, master of none, but oftentimes better than some are at one.
  - Loic 6y ago
    We started a very large computational intensive project in Fortran. It is still easier to do maths in Fortran than in C/C++ and now, Fortran has a wonderful C binding system allowing direct call into C .so/.dll if you want to do some SQL or other kind of data input/output.
  - Bostonian 6y ago
dan-robertson 6y ago
I found the beginner installation/package installation experience a million times better than python (except that it’s tricky to explain that you type ] to enter the package manager but you don’t see the ] that you typed)
- jakobnissen 6y ago
  You can "using PKG" and then type "pkg"add MyPackage""
chalst 6y ago
There are warts with the beginner experience with Python, principally the awful situation with packaging. If you care about performance in code that mixes together several packages in nontrivial ways, Julia is way better than Python. There's a far broader range of libraries in Python than Julia, but none of them are going to prevent adoption of Julia when its performance advantages are crucial, because of the excellent facilities for using Python from Julia.
- watwatinthewat 6y ago
  I'm not sure the package problem is really a problem for beginners. Just within the last year firsthand I've seen people in undergraduate classes, in graduate classes, and at work try Python the first time, and the default install of Anaconda worked for them in every case. The classes were taught by different professors, and they all suggested Anaconda independently and were not Python programmers. It is overkill/brute force to install all the Anaconda default packages when a beginner is not going to use over maybe 5-10 libraries, but it's a solution that has worked flawlessly for beginners from my experience watching non-software engineers and "non-technical" people using Linux, Windows, and MacOS try Python for the first time in math and data science classes.
  - deleted 6y ago
    [deleted]
veddox 6y ago
> Julia has to be way better than Python to give people an incentive to switch. A language doesn't necessarily have to give all the old programmers an incentive to switch, if it can position itself as a good language for new programmers to learn. For example: at our institute (computational biology), we had a PhD student who was an early Julia adopter and wrote his model in that. Several students have since joined the project he started, so obviously they're now writing Julia too. That project's experiences with the language were so good, it soon became obvious that for our use case, Julia was superior to any other language we'd used so far. So pretty much the whole research group has now shifted to Julia, and that's what we teach new students. Slowly, other groups in our institute became interested, and more and more people are adopting it, which in turn means that their new students will also end up learning it in future.
- CoolGuySteve 6y ago
  If you work with a lot of data, Julia is already a 10-100x improvement over Python. Being able to iterate and mangle huge columns with real lambdas and without having to marshal arguments to/from C++ is a huge advantage. Where I used to spend hours in aggregate searching through docs for pandas/numpy, for stupid shit like "how do I shift but also skip NaNs", now I just write a for-loop in a couple minutes and get on with my work. There's a whole subclass of tasks in R/pandas to work around the interpreter that just aren't needed in Julia. For me at least it's well worth the syntactical warts and slow interpreter.
  - VHRanger 6y ago
    As an experienced python/data science user, this (creating fast complex column-wise transforms) is rarely a problem for me. The truly huge advantage for Julia is how it plays with parralelism. The GIL makes it an absolute pain to do parallelism in python. Always ends up in threading hacks with numba or joblib, or multiprocessing, which has its own unfixable flaws
- oblio 6y ago
  Examples: Basic, C (both Basic and C, to a degree), Visual Basic, PHP, Javascript, Python. I'm probably missing some. These displaced older languages just by being adopted by newbies.
Grimm1 6y ago
I said something similar in another thread, but for me it doesn't have to be better than Python, as that is largely going to be subjective, the package ecosystem just has to grow and have some offering, at all, for the things that I do. https://fluxml.ai/Flux.jl/stable/ https://fluxml.ai/Flux.jl/stable/ Is still very barebones compared to Torch/TF/Flax and I would be hamstringing myself by switching to Julia even if I find the language otherwise attractive.
- huitzitziltzin 6y ago
  Maybe keep an eye on this issue: https://github.com/FluxML/Flux.jl/issues/1431 https://github.com/FluxML/Flux.jl/issues/1431 They are going for feature parity with pytorch hopefully in the near term.
  - Grimm1 6y ago
    Thanks for this, I will definitely follow along there. Yeah if they can just check a few of those boxes I'm much more likely to at least try to more regularly work with Julia.
- macawfish 6y ago
  But can Torch/TF/Flax do autodifferentiation on constants ordinary functions? No they cannot!
  - komuher 6y ago
    Flax/jax can :)
    - ChrisRackauckas 6y ago
      If it's a pure function. Oh and if you have state-based control flow you have to turn off the JIT. Etc. If you take a standard library like some thermodynamics simulator and throw Jax on it do you expect it to work without modification? Most of the time it'll fail right at the start by using the wrong implementation of Numpy. So no, that's not "ordinary functions": those are functions where people consciously put in the effort to rewrite years of work onto Jax which is very different.
oxinabox 6y ago
I remember in ~2005 people said almost the exact same thing about Python and Perl.
- evgen 6y ago
  I think you are confusing 1995 with 2005. Perl was in decline by 2000 and by 2005 it was terminal; you could probably count the number of perl shops of any consequence in that year on the fingers of one hand.
  - oxinabox 6y ago
    I don't think that is the case. Sure Perl may have been in decline for ages, but people were not comparing Perl to Python for that long. Simply because python hasn't existed that long. Python 2.0 was released in 2000. Python 1.0 was 1994, and Python 0.9 (first public release?) was 1991. Check the google trends. https://trends.google.com/trends/explore?date=all&geo=US&q=perl,python https://trends.google.com/trends/explore?date=all&geo=US&q=p... Its unclear when perl peaked since it has been in decline since before 2004 But it wasn't til late 2007 that Python overtook Perl in google searches Even while it was in decline people were still making that argument.

ForHackernews 6y ago

You can call Python directly from Julia https://github.com/JuliaPy/PyCall.jl https://github.com/JuliaPy/PyCall.jl so much of the Python library ecosystem (say, matplotlib) is available to be used in Julia programs. That helps the adoption story quite a bit. You can do the number-crunching in Julia where performance counts, and then analyse and present the results using Python.

superbcarrot 6y ago
- Using Python directly is a better experience than calling Python from Julia - I've never run into unsolveable performance issues with Python So I guess I'm not in the target audience unless I just happen to be curious about a new language? That's kind of my overall point - even if Julia is a good language on its own and I work in data science, I don't have reasons to pick it over Python.
- pjmlp 6y ago
  Except when Python fails, the option is to write C, in Julia I can carry on writing Julia.
- galangalalgol 6y ago
  If you haven't hit a brick wall with python, it is just because you haven't run into the right problem. I was doing something that required lots of conditional operations on small matrices. The FFI into numpy's native library really bogged it down. I didn't have permission to install a compiler on that machine so I wrote it in vba in excel. It was 11x faster.

alephnil 6y ago

Julia has the focus on scientific and numerical computing, and is overtaking the python/numpy combo in that niche. In addition to being considerably faster than python, it also has quite some innovative libraries in the area. This can also extend into machine learning, where python has been the go to language, despite its limitations. For other areas, like web programming, there is no sign of Julia replacing Python in the forseable future.

superbcarrot 6y ago
> and is overtaking the python/numpy combo in that niche No, it's isn't. Julia is growing but it's far from overtaking Python at this point. > For other areas, like web programming, there is no sign of Julia replacing Python in the forseable future. That's where Go comes in.
- bsdubernerd 6y ago
  I second this. Python is actually starting to get significant traction in the scientific community. Depending on the field, R, Fortran and Matlab (and even C++) still have a huge lead. It's nice that Julia is getting noticed, but it's a distant blip in the radar. The sci community is really hard to move from existing battle-tested and performant libraries.
  - oefrha 6y ago
    I don’t have much insight on the scientific computing landscape in general, but here’s one notable data point: I worked on the CMS experiment of LHC (Large Hadron Collider) for a while, which is one of the highest profile experiments in experimental physics. The majority of CMS code is C++, which you can check for yourself at https://github.com/cms-sw/cmssw https://github.com/cms-sw/cmssw (yes, much/most? of the code is open source). What I worked on specifically was prototyped in Python, then ported to C++ and plugged into the massive data processing pipeline where performance is critical due to the sheer amount of data. So I probably wouldn’t put C++ in parentheses.
    - 6y ago

shiftingleft 6y ago

I think this is a fair assessment, and would like to add that the "time to first plot" is also quite the usability issue. Julia is using LLVM for code-gen has to compile a lot of code before you can actually use stuff like plots. It takes ages to get a Pluto Notebook up and running, while a jupyter notebook is available instantly.

enriquto 6y ago
Wait, why can't you use a regular jupyter notebook for julia? The "ju" in "jupyter" stands for what, then?
- jakobnissen 6y ago
  You can, but Pluto is (I would argue) a better notebook than Jupyter. Regardless, the latency experienced with Julia applies equally whether you use Pluto, Jupyter, or any other front-end.
  - carterschonwald 6y ago
    Pluto is a notebook design the world needs. It’s nice enough for it to motivate me to use Julia for some new prjects. But yeah latency kills :)
- spacedome 6y ago
  You absolutely can use regular jupyter notebooks for julia! Pluto has some advantages, like being stored as a normal julia file. The julia startup time issues affect both.
  - enriquto 6y ago
    > being stored as a normal julia file. Oh, man, this is indeed a major feature. My main point of friction with jupyter notebooks is the stupid json ipynb format. Why can't it be just a regular language file with comments?

bluenose69 6y ago

This is an insightful and level-headed comment that applies equally to R. Although Julia is a growing alternative to Fortran/C/etc for long-running computations, it remains awkward and unpleasant for interactive analysis. Users familiar with Python/R/etc must weight the benefits of Julia against its slow library startup, its cryptic error messages, and its thin documentation. Also, the lack of a community repository for well-vetted Julia libraries can limit uptake by professional researchers who must be able to trust their tools. A real strength of R (in comparison not just to Julia but also to python) is that such a repository exists, and that it has automated testing across a range of computer architectures and versions of R, including not just unit testing within individual libraries, but also testing of related libraries.

disgruntledphd2 6y ago
Yeah, the R community owes a lot of it's stability to Uwe Ligges, and his (sometimes annoying) insistence on CRAN package quality.
BadInformatics 6y ago
> Julia is a growing alternative to Fortran/C/etc for long-running computations, it remains awkward and unpleasant for interactive analysis Did you mean to write short-running scripts? If anything, the Julia dev workflow is biased towards interactive analysis in a REPL a la R or IPython/Jupyter. I don't mean to imply that there's no startup overhead, but how often are you restarting the REPL when doing EDA? Unless it's more than once every few minutes (which is a very odd workflow), then startup overhead is effectively amortized. > A real strength of R (in comparison not just to Julia but also to python) is that such a repository exists CRAN is certainly a cut above many other package repos here, but I'm not sure "trust their tools" can apply to all packages on there. Anecdotally, I've had a lot of issues with compiled dependencies and missing/out of date external assets on less well-trodden packages. There's a reason MRAN, Conda and JuliaBinaryWrappers exist after all. For whatever reason, Julia package maintainers also seem more receptive to making their work compatible with other libraries as well. This goes beyond just multiple dispatch as well--imagine if tidyverse/non-tidyverse wasn't such a hard split.

ptero 6y ago

I think your "ecosystem of python libraries" is the key point. Python got a lot of mileage for a mass adoption from ML. Its libraries provided an "easy ML" for masses at the time ML got popular in science and job market, which quickly brought it into mainstream and built up its network effect. A similar enabler in a new field could help Julia burst in as a general language. My 2c.

chalst 6y ago
Autodiff is a place where there is a gulf between Julia and Python, one that I think can't be bridged well: JuliaDiff is astonishingly flexible and performant. https://www.juliadiff.org/ https://www.juliadiff.org/
- oxinabox 6y ago
  Urg that website is so incredibly out of date. Julia has amazing things for autodiff. But like not the things listed on that website. Also python is still doing great with Jax and PyTorch.
  - chalst 6y ago
    I linked to the website (which was updated in May, but its contents could do with more work) because it has examples of how well the suite fits together. I don't know much about Jax. I've seen competent benchmarks showing an order of magnitude benefit for using ReverseDiff from the AutoDiff suite over Autograd, which is what Pytorch uses for reverse-mode autodiff
    - oxinabox 6y ago
      It was update in May to fix that the CDN changed. The actual content hasn't been updated in 7 years. It really should be updated to have basically the content of this thread https://discourse.julialang.org/t/state-of-automatic-differentiation-in-julia/43083 https://discourse.julialang.org/t/state-of-automatic-differe...

melling 6y ago

Python used to be tough to compete with Perl. But then times change... It’s usually the tooling and libraries. Now I don’t want to go back to Perl. And I’d certainly be willing to give Julia a try.

canadianfella 6y ago
Did you know Perl is only 4 years older than Python? I found that to be unexpected.

uncrex 6y ago

> way better People like to substitute "10x better" here but I think the real number is 100,000x better, aka it's not possible by default. Q: What it would take to replace Windows? A: iPhone was a new product category that targetted a new market.

jakobnissen 6y ago
It does happen, though. C has mostly replaced FORTRAN for scientific applications. Not entirely, FORTRAN is (infamously) still used, but I don't know anyone who has started a new project with FORTRAN. Just 6 years ago, I was taught Perl in my Introduction to Bioinformatics course. The teachers were still using Perl because it used to be the go-to language for bioinformaticians. The year after, and every year since, they've taught using Python.
- evgen 6y ago
  The idea that people were being forced to learn perl just for bioinfomatics as recently as 6 years ago fascinates me. Python has gotten exceptionally lucky. I am sure the two or three remaining perl users on the planet are also on HN and ready to jump to its defense, but to me this just goes to show you how heavy the switching cost is for something like this is and also how lucky python was to have been the best language to switch to at this point. It was in the right place at the right time for a lot of these switches away from older languages in obvious decline and then it was able to leverage numpy and scikit to pick up a lot of additional momentum in ML and data science tasks. It is almost never the 'best' language for the job, but coming in as second choice on most tasks is a huge win. Jack of all trades, master of none, but oftentimes better than some are at one.
- Loic 6y ago
  We started a very large computational intensive project in Fortran. It is still easier to do maths in Fortran than in C/C++ and now, Fortran has a wonderful C binding system allowing direct call into C .so/.dll if you want to do some SQL or other kind of data input/output.
- Bostonian 6y ago

dan-robertson 6y ago

I found the beginner installation/package installation experience a million times better than python (except that it’s tricky to explain that you type ] to enter the package manager but you don’t see the ] that you typed)

jakobnissen 6y ago
You can "using PKG" and then type "pkg"add MyPackage""

chalst 6y ago

There are warts with the beginner experience with Python, principally the awful situation with packaging. If you care about performance in code that mixes together several packages in nontrivial ways, Julia is way better than Python. There's a far broader range of libraries in Python than Julia, but none of them are going to prevent adoption of Julia when its performance advantages are crucial, because of the excellent facilities for using Python from Julia.

watwatinthewat 6y ago
I'm not sure the package problem is really a problem for beginners. Just within the last year firsthand I've seen people in undergraduate classes, in graduate classes, and at work try Python the first time, and the default install of Anaconda worked for them in every case. The classes were taught by different professors, and they all suggested Anaconda independently and were not Python programmers. It is overkill/brute force to install all the Anaconda default packages when a beginner is not going to use over maybe 5-10 libraries, but it's a solution that has worked flawlessly for beginners from my experience watching non-software engineers and "non-technical" people using Linux, Windows, and MacOS try Python for the first time in math and data science classes.
- deleted 6y ago
  [deleted]

veddox 6y ago

> Julia has to be way better than Python to give people an incentive to switch. A language doesn't necessarily have to give all the old programmers an incentive to switch, if it can position itself as a good language for new programmers to learn. For example: at our institute (computational biology), we had a PhD student who was an early Julia adopter and wrote his model in that. Several students have since joined the project he started, so obviously they're now writing Julia too. That project's experiences with the language were so good, it soon became obvious that for our use case, Julia was superior to any other language we'd used so far. So pretty much the whole research group has now shifted to Julia, and that's what we teach new students. Slowly, other groups in our institute became interested, and more and more people are adopting it, which in turn means that their new students will also end up learning it in future.

CoolGuySteve 6y ago
If you work with a lot of data, Julia is already a 10-100x improvement over Python. Being able to iterate and mangle huge columns with real lambdas and without having to marshal arguments to/from C++ is a huge advantage. Where I used to spend hours in aggregate searching through docs for pandas/numpy, for stupid shit like "how do I shift but also skip NaNs", now I just write a for-loop in a couple minutes and get on with my work. There's a whole subclass of tasks in R/pandas to work around the interpreter that just aren't needed in Julia. For me at least it's well worth the syntactical warts and slow interpreter.
- VHRanger 6y ago
  As an experienced python/data science user, this (creating fast complex column-wise transforms) is rarely a problem for me. The truly huge advantage for Julia is how it plays with parralelism. The GIL makes it an absolute pain to do parallelism in python. Always ends up in threading hacks with numba or joblib, or multiprocessing, which has its own unfixable flaws
oblio 6y ago
Examples: Basic, C (both Basic and C, to a degree), Visual Basic, PHP, Javascript, Python. I'm probably missing some. These displaced older languages just by being adopted by newbies.

Grimm1 6y ago

I said something similar in another thread, but for me it doesn't have to be better than Python, as that is largely going to be subjective, the package ecosystem just has to grow and have some offering, at all, for the things that I do. https://fluxml.ai/Flux.jl/stable/ https://fluxml.ai/Flux.jl/stable/ Is still very barebones compared to Torch/TF/Flax and I would be hamstringing myself by switching to Julia even if I find the language otherwise attractive.

huitzitziltzin 6y ago
Maybe keep an eye on this issue: https://github.com/FluxML/Flux.jl/issues/1431 https://github.com/FluxML/Flux.jl/issues/1431 They are going for feature parity with pytorch hopefully in the near term.
- Grimm1 6y ago
  Thanks for this, I will definitely follow along there. Yeah if they can just check a few of those boxes I'm much more likely to at least try to more regularly work with Julia.
macawfish 6y ago
But can Torch/TF/Flax do autodifferentiation on constants ordinary functions? No they cannot!
- komuher 6y ago
  Flax/jax can :)
  - ChrisRackauckas 6y ago
    If it's a pure function. Oh and if you have state-based control flow you have to turn off the JIT. Etc. If you take a standard library like some thermodynamics simulator and throw Jax on it do you expect it to work without modification? Most of the time it'll fail right at the start by using the wrong implementation of Numpy. So no, that's not "ordinary functions": those are functions where people consciously put in the effort to rewrite years of work onto Jax which is very different.

oxinabox 6y ago

I remember in ~2005 people said almost the exact same thing about Python and Perl.

evgen 6y ago
I think you are confusing 1995 with 2005. Perl was in decline by 2000 and by 2005 it was terminal; you could probably count the number of perl shops of any consequence in that year on the fingers of one hand.
- oxinabox 6y ago
  I don't think that is the case. Sure Perl may have been in decline for ages, but people were not comparing Perl to Python for that long. Simply because python hasn't existed that long. Python 2.0 was released in 2000. Python 1.0 was 1994, and Python 0.9 (first public release?) was 1991. Check the google trends. https://trends.google.com/trends/explore?date=all&geo=US&q=perl,python https://trends.google.com/trends/explore?date=all&geo=US&q=p... Its unclear when perl peaked since it has been in decline since before 2004 But it wasn't til late 2007 that Python overtook Perl in google searches Even while it was in decline people were still making that argument.