6 ms·

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

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.
    - pansa2 6y ago
      > prototyped in Python, then ported to C++ This need to rewrite, of course, is what Julia is trying to avoid. My workflow is exactly the same, and I’d love to be able to write code in a high-level language like Python and then use that directly instead of having to rewrite. However, in my case the reason for rewriting isn’t just performance, but also to be able to build compiled binaries. Julia aims to be as high-level as Python but faster - is there a language that’s as high-level as Python but AOT-compiled?
      - oefrha 6y ago
        Nim? I know it has Python-like syntax and aims to be performant, but don’t know much beyond that.
        0-_-0 6y ago
        Indeed, the Julia autodiff implementation linked above would look very similar in Nim as well.
      - mlthoughts2018 6y ago
        Cython - in fact I think in 2021 if you want to write a pure C or pure C++ program, Cython is the best way to go, and just disable use of CPython. The “need to rewrite” is actually a sort of advantage with Cython. You only target small pieces of your program to be compiled to C or C++ for optimization, and the rest where runtime is already fast enough or otherwise doesn’t matter, you seamlessly write in plain Python. Using extension modules is just a time-tested, highly organized, modular, robust design pattern. Julia and others do themselves a disservice by trying to make “the whole language automatically optimized” which counter-intuitively is worse than make the language overall optimized for flexibility instead of speed, yet with an easy system to patch optimization modules anywhere they are needed.
        szemet 6y ago
        > Using extension modules is just a time-tested, highly organized, modular, robust design pattern. I really don't get this. I'am fully on the side that limitations may increase design quality. E.g I accept the argument that Haskell immutability often leads to good design, I also believe the same true for Rust ownership rules (it often forces a design where components have a well defined responsibility: this component only manages resource X starting from { until }.) But having a performance boundary between components, why would that help? E.g. This algorithm will be fast with floats but will be slow with complex numbers. Or: You can provide X,Y as callback function to our component, it will be blessed and fast, but providing your custom function Z it will be slow. So you should implement support for callback Z in a different layer but not for callback X,Y, and you should rewrite your algorithm in a lower level layer just to support complex numbers. Will this really lead to a better design?
- pjmlp 6y ago
  First Go needs to offer comparable stacks to .NET and Java offerings, not only their platforms languages, but also their guest ones. And yes, there are ways to AOT compile as well.
  - oblio 6y ago
    It's all about which "bubble" you're in. Many people posting here work for startups using micro services (for which Go is a decent fit) and for companies close to the whole Docker/Kubernetes ecosystem, which is based on Go. So naturally they assume Go is huge. My anecdata kind of tells me that Go is reasonably big, but it's not yet near .NET and Java, worldwide. But it could get there in a few years, I've seen/heard about some enterprises adopting it.
    - pjmlp 6y ago
      You don't need to write C or C++ when using a SQL RDMS, likewise .NET and Java shops don't need to write Go when using Docker/Kubernetes.
      - oblio 6y ago
        True, but I'm not talking about simple users. I'm talking about companies extending Kubernetes or building adjacent software. Even if their service doesn't necessarily integrate with Kubernetes, there is frequently a temptation to "follow your heroes". Look at the whole Cloud Native Foundation thing, I think most of their projects are developed using Go. So if you're using that stack, it's easy to assume that all new development everywhere is in Go. It will probably balance out once the newness wears off Go (I think this is already happening).
        pjmlp 6y ago
        Actually Rust in what concerns Microsoft. https://deislabs.io/posts/still-rusting-one-year-later/ https://deislabs.io/posts/still-rusting-one-year-later/ I should also note that after creating the initial support for Go on VSCode, they have given it away to Google to maintain it.
physicsguy 6y ago
It's not overtaking at all. It's seen growth in some areas. The issue with regards to web programming/other programming is important, because sometimes it's useful to make a website/build another tool as a scientist. Python can do both easily.
- amkkma 6y ago
  So can Julia: https://github.com/plotly/Dash.jl https://github.com/plotly/Dash.jl https://www.youtube.com/watch?v=uLhXgt_gKJc https://www.youtube.com/watch?v=uLhXgt_gKJc https://github.com/GenieFramework/Genie.jl https://github.com/GenieFramework/Genie.jl
  - physicsguy 6y ago
    They're not exactly mature frameworks yet though, which is more the point I'm making. Of course, you can do most things in Julia, but does it provide a good experience for it yet?
- oxinabox 6y ago
  there are so many tools coming up around this in julia that it is arguably a problem. THere was a whole session last juliacon that was just on web-dashboard tools like Dash.jl and Stipple.jl and several others. And there was another half-session worth of other talks about web related things.
fnord123 6y ago
>Julia has the focus on scientific and numerical computing, and is overtaking the python/numpy combo in that niche\ I agree. In fact if Julia hasn't overtaken Python in numerical computing by January 2022 I will consider it a huge failure.
- evgen 6y ago
  Seriously?!? Julia has no hope of overtaking Python in numerical computing by 2032, expecting movement by 2022 is just delusional. Here is a better prediction: by 2022 people using Python for numerical computing who started doing so in the previous year will exceed the number of people who have ever downloaded Julia since it was first released.
  - kazinator 6y ago
    Not people that matter, though, mostly just redundant copies of the same person.
  - fnord123 6y ago
    No, not seriously. But also seriously. The article is based on % change which is of course ridiculous because the % increase of a small population isn't at all interesting. And GP also has a ridiculous claim. So I'm offering a stake in the ground to determine if Julia is on the track that GP claims. If GP wants to come back and discuss where the stake should be, it will be an interesting conversation.

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.
  - pansa2 6y ago
    > prototyped in Python, then ported to C++ This need to rewrite, of course, is what Julia is trying to avoid. My workflow is exactly the same, and I’d love to be able to write code in a high-level language like Python and then use that directly instead of having to rewrite. However, in my case the reason for rewriting isn’t just performance, but also to be able to build compiled binaries. Julia aims to be as high-level as Python but faster - is there a language that’s as high-level as Python but AOT-compiled?
    - oefrha 6y ago
      Nim? I know it has Python-like syntax and aims to be performant, but don’t know much beyond that.
      - 0-_-0 6y ago
        Indeed, the Julia autodiff implementation linked above would look very similar in Nim as well.
    - mlthoughts2018 6y ago
      Cython - in fact I think in 2021 if you want to write a pure C or pure C++ program, Cython is the best way to go, and just disable use of CPython. The “need to rewrite” is actually a sort of advantage with Cython. You only target small pieces of your program to be compiled to C or C++ for optimization, and the rest where runtime is already fast enough or otherwise doesn’t matter, you seamlessly write in plain Python. Using extension modules is just a time-tested, highly organized, modular, robust design pattern. Julia and others do themselves a disservice by trying to make “the whole language automatically optimized” which counter-intuitively is worse than make the language overall optimized for flexibility instead of speed, yet with an easy system to patch optimization modules anywhere they are needed.
      - szemet 6y ago
        > Using extension modules is just a time-tested, highly organized, modular, robust design pattern. I really don't get this. I'am fully on the side that limitations may increase design quality. E.g I accept the argument that Haskell immutability often leads to good design, I also believe the same true for Rust ownership rules (it often forces a design where components have a well defined responsibility: this component only manages resource X starting from { until }.) But having a performance boundary between components, why would that help? E.g. This algorithm will be fast with floats but will be slow with complex numbers. Or: You can provide X,Y as callback function to our component, it will be blessed and fast, but providing your custom function Z it will be slow. So you should implement support for callback Z in a different layer but not for callback X,Y, and you should rewrite your algorithm in a lower level layer just to support complex numbers. Will this really lead to a better design?
pjmlp 6y ago
First Go needs to offer comparable stacks to .NET and Java offerings, not only their platforms languages, but also their guest ones. And yes, there are ways to AOT compile as well.
- oblio 6y ago
  It's all about which "bubble" you're in. Many people posting here work for startups using micro services (for which Go is a decent fit) and for companies close to the whole Docker/Kubernetes ecosystem, which is based on Go. So naturally they assume Go is huge. My anecdata kind of tells me that Go is reasonably big, but it's not yet near .NET and Java, worldwide. But it could get there in a few years, I've seen/heard about some enterprises adopting it.
  - pjmlp 6y ago
    You don't need to write C or C++ when using a SQL RDMS, likewise .NET and Java shops don't need to write Go when using Docker/Kubernetes.
    - oblio 6y ago
      True, but I'm not talking about simple users. I'm talking about companies extending Kubernetes or building adjacent software. Even if their service doesn't necessarily integrate with Kubernetes, there is frequently a temptation to "follow your heroes". Look at the whole Cloud Native Foundation thing, I think most of their projects are developed using Go. So if you're using that stack, it's easy to assume that all new development everywhere is in Go. It will probably balance out once the newness wears off Go (I think this is already happening).
      - pjmlp 6y ago
        Actually Rust in what concerns Microsoft. https://deislabs.io/posts/still-rusting-one-year-later/ https://deislabs.io/posts/still-rusting-one-year-later/ I should also note that after creating the initial support for Go on VSCode, they have given it away to Google to maintain it.

physicsguy 6y ago

It's not overtaking at all. It's seen growth in some areas. The issue with regards to web programming/other programming is important, because sometimes it's useful to make a website/build another tool as a scientist. Python can do both easily.

amkkma 6y ago
So can Julia: https://github.com/plotly/Dash.jl https://github.com/plotly/Dash.jl https://www.youtube.com/watch?v=uLhXgt_gKJc https://www.youtube.com/watch?v=uLhXgt_gKJc https://github.com/GenieFramework/Genie.jl https://github.com/GenieFramework/Genie.jl
- physicsguy 6y ago
  They're not exactly mature frameworks yet though, which is more the point I'm making. Of course, you can do most things in Julia, but does it provide a good experience for it yet?
oxinabox 6y ago
there are so many tools coming up around this in julia that it is arguably a problem. THere was a whole session last juliacon that was just on web-dashboard tools like Dash.jl and Stipple.jl and several others. And there was another half-session worth of other talks about web related things.

fnord123 6y ago

>Julia has the focus on scientific and numerical computing, and is overtaking the python/numpy combo in that niche\ I agree. In fact if Julia hasn't overtaken Python in numerical computing by January 2022 I will consider it a huge failure.

evgen 6y ago
Seriously?!? Julia has no hope of overtaking Python in numerical computing by 2032, expecting movement by 2022 is just delusional. Here is a better prediction: by 2022 people using Python for numerical computing who started doing so in the previous year will exceed the number of people who have ever downloaded Julia since it was first released.
- kazinator 6y ago
  Not people that matter, though, mostly just redundant copies of the same person.
- fnord123 6y ago
  No, not seriously. But also seriously. The article is based on % change which is of course ridiculous because the % increase of a small population isn't at all interesting. And GP also has a ridiculous claim. So I'm offering a stake in the ground to determine if Julia is on the track that GP claims. If GP wants to come back and discuss where the stake should be, it will be an interesting conversation.