5 ms·

Honestly, this is truly amazing. I will take a quick moment to thank the Julia developers (and all the contributors) for such an awesome language—honestly, if y

Honestly, this is truly amazing. I will take a quick moment to thank the Julia developers (and all the contributors) for such an awesome language—honestly, if you do any kind of scientific computing (at all) I really and truly recommend trying out Julia. The REPL and development loop are each a little different than the usual Python/R/etc., but it's such a cool language and it's so fast that it will feel like an incredible breath of fresh air. It's amazing to realize that writing down the first thing that comes to your head is usually like 80% as fast as a good, performant implementation. (As someone who has done a decent amount of work in performance engineering for embedded platforms, I really enjoy squeezing out the last drop of performance from most programs, but doing this for every single first-pass at a program, like in Python, is rather annoying if this is what is needed to get a usable implementation.) Anyways, big props to the developers and contributors, even if this is just a "minor" release. I'm extraordinarily excited for the future of Julia and hope it continues to grow and be as awesome of a community as it is! :)

mfsch 6y ago
One thing to note is that it’s worth learning a little bit about how to write performant code in Julia and how to correctly measure its performance when evaluating the language. It’s common for people to underestimate the performance benefits in their first experiments. There are a few common issues: 1) You measure compilation plus execution instead of just execution. 2) Your code relies on global values that limit optimizations. 3) Your code doesn’t allow the compiler to determine all the types. 4) Your code forces allocations for intermediate values. Especially 4) makes a big difference when you’re coming from NumPy or MATLAB. If you have a chain of vectorized operations (e.g. “X = α * A + β * B + γ * C”), the performance is quite similar between the languages, but in Julia you can enforce that these happen in-place with a single fused loop and zero allocations (e.g. adding “@.” in front). This can often give you another ~2x–10x speedup and make the difference between “similar to NumPy/MATLAB” and “similar to C/Fortran”.
fermienrico 6y ago
Personally, every time I try to delve into Julia, I am reminded by the massive ecosystem that exists around Python. Speed takes a backseat, instead enormous ecosystem makes Python indispensable and Julia a fringe language despite of its growing popularity. Say you have a database, and need pull data, do some heavy math computation, then present this data in a pdf report with a QR code, pulling images and processing them in the report. In Python, it is without bells and whistles: psycopg2, numpy/pandas, reportlab and may be use PIL. Wanna stick this on S3? boto3. In Julia, it's all very fragmented. LibPQ is immature, DataFrames.jl is nice, ??? (what pdf conversion tool?), images.jl (300 stars), qr code generator? The problem is not the speed with most tasks. The problem is availability of tools. I am sure that will come with it, but why not just use Python at that point? I am not a fan of Julia and that's nothing to do with its features. It has immature ecosystem, with terrible IDE support (Atom/Juno raises my blood pressure), debugging is painful if non existent, error messages are all over the place, everything falls apart as the immature dependencies change and error messages don't help at all. Julia is fun in your jupyter notebook. If you try to build apps in production environment in my team, expect push back if not straight up refusal to initiate such a project in the first place. Syntax was amazing around 0.4v and it went downhill from there. I am sure someone is going to nitpick my comment and provide a way to do it in Julia, but that's missing the point. The point is Python is miles ahead of what it does. In production systems, robustness + maturity matters. Also, don't forget ancillary aspects of a programming language. When we put a python repo together, I am rewarded by an endless supply of developers that I can hire and immediately work on it. With Julia, the supply of engineers is limited and it is such a pain to train people to use it, learn its quirks, spend nights and weekends fighting with it and the business doesn't give a fuck about it.
- EricForgy 6y ago
  I am not going to try to change your mind, but I'll just point out that one of the highlights, in my mind, of the recent JuliaCon was the merging of the Juno and VS Code teams. All IDE development for these teams going forward will be focused VS Code. Have a look at the VS Code presentations available on YouTube. It is pretty amazing to see where they are now and the future is even brighter.
  - bananaquant 6y ago
    Do they have a usable debugger now? My last experience was 2 years ago, and launching it even on some trivial code took over 10 seconds.
    - eigenspace 6y ago
      The Debugger has come a long way, here's it running in 1.5.0 on my machine: julia> @time using Debugger 0.115907 seconds (202.08 k allocations: 13.215 MiB) julia> @time @run sin(1) 1.438537 seconds (1.85 M allocations: 90.376 MiB, 0.80% gc time) 0.8414709848078965 julia> @time @run sin(1) 0.003900 seconds (23.39 k allocations: 1.057 MiB) 0.8414709848078965
      - bananaquant 6y ago
        Whoa. This looks really promising now.
- pdeffebach 6y ago
  Sure, Julia doesn't have an industry-tested QR code maker (though if you google you will find some options). But it's worth noting that CSV.jl is a file that was entirely re-written in the past 6 months and has probably the fastest performance of any CSV parser currently used. It was written using pure julia and takes advantage of tons of Base-julia features as well as multi-purpose packages. Julia's design makes it incredible easy to write the kinds of tools you want in a flexible way.
- 6y ago
tastyminerals 6y ago
Julia is fast but not faster and very memory hungry. If you care about squeezing every bit of performance you generally go to C++. If you too lazy for C++ you go D. Hence to me, Julia is an odd tool. Interesting but more as a language with some cool scientific libs that Python might not yet have.
- LolWolf 6y ago
  This is what I meant when I stated > It's amazing to realize that writing down the first thing that comes to your head is usually like 80% as fast as a good, performant implementation. (As someone who has done a decent amount of work in performance engineering for embedded platforms, I really enjoy squeezing out the last drop of performance from most programs, but doing this for every single first-pass at a program, like in Python, is rather annoying if this is what is needed to get a usable implementation.) Yes, Julia is not necessarily faster than a good C implementation (that doesn't leak, etc), but, like Python, what would be a 300-line C implementation, where one has to somewhat carefully manage typing and the abstraction is really rather complicated for something that is mathematically simple, we can usually write 20 lines of very performant Julia that is 95% as fast. Attempting to do something relatively similar in Python is often slow enough that giving a practical implementation essentially needs to be coded in C and interfaced with Python, where we return (again!) back to the same problem we had before: writing a 300+ line C file for something that should be rather simple, mathematically speaking.
- miles7 6y ago
  Another important consideration is library development. As someone developing a large library, when we were previously developing in C++ we would encounter large barriers where some design goal we had either couldn't be done in the language in a practical sense or would require hours of tweaking things like template constraints to work correctly. Our users also had such a hard time extending our library's features they usually gave up and just waited for us to add features for them. Now that we're developing in Julia we can realize our designs as we envisioned them with very little code. Features like multiple dispatch have been a lifesaver for us. And we are getting performance that is quite close to C++. Now we're looking forward to using features like composable multithreading. One could wonder "why not use python?" but for performance reasons one ends up with the 'two-language problem' which we wanted to avoid.

mfsch 6y ago

One thing to note is that it’s worth learning a little bit about how to write performant code in Julia and how to correctly measure its performance when evaluating the language. It’s common for people to underestimate the performance benefits in their first experiments. There are a few common issues: 1) You measure compilation plus execution instead of just execution. 2) Your code relies on global values that limit optimizations. 3) Your code doesn’t allow the compiler to determine all the types. 4) Your code forces allocations for intermediate values. Especially 4) makes a big difference when you’re coming from NumPy or MATLAB. If you have a chain of vectorized operations (e.g. “X = α * A + β * B + γ * C”), the performance is quite similar between the languages, but in Julia you can enforce that these happen in-place with a single fused loop and zero allocations (e.g. adding “@.” in front). This can often give you another ~2x–10x speedup and make the difference between “similar to NumPy/MATLAB” and “similar to C/Fortran”.

fermienrico 6y ago

Personally, every time I try to delve into Julia, I am reminded by the massive ecosystem that exists around Python. Speed takes a backseat, instead enormous ecosystem makes Python indispensable and Julia a fringe language despite of its growing popularity. Say you have a database, and need pull data, do some heavy math computation, then present this data in a pdf report with a QR code, pulling images and processing them in the report. In Python, it is without bells and whistles: psycopg2, numpy/pandas, reportlab and may be use PIL. Wanna stick this on S3? boto3. In Julia, it's all very fragmented. LibPQ is immature, DataFrames.jl is nice, ??? (what pdf conversion tool?), images.jl (300 stars), qr code generator? The problem is not the speed with most tasks. The problem is availability of tools. I am sure that will come with it, but why not just use Python at that point? I am not a fan of Julia and that's nothing to do with its features. It has immature ecosystem, with terrible IDE support (Atom/Juno raises my blood pressure), debugging is painful if non existent, error messages are all over the place, everything falls apart as the immature dependencies change and error messages don't help at all. Julia is fun in your jupyter notebook. If you try to build apps in production environment in my team, expect push back if not straight up refusal to initiate such a project in the first place. Syntax was amazing around 0.4v and it went downhill from there. I am sure someone is going to nitpick my comment and provide a way to do it in Julia, but that's missing the point. The point is Python is miles ahead of what it does. In production systems, robustness + maturity matters. Also, don't forget ancillary aspects of a programming language. When we put a python repo together, I am rewarded by an endless supply of developers that I can hire and immediately work on it. With Julia, the supply of engineers is limited and it is such a pain to train people to use it, learn its quirks, spend nights and weekends fighting with it and the business doesn't give a fuck about it.

EricForgy 6y ago
I am not going to try to change your mind, but I'll just point out that one of the highlights, in my mind, of the recent JuliaCon was the merging of the Juno and VS Code teams. All IDE development for these teams going forward will be focused VS Code. Have a look at the VS Code presentations available on YouTube. It is pretty amazing to see where they are now and the future is even brighter.
- bananaquant 6y ago
  Do they have a usable debugger now? My last experience was 2 years ago, and launching it even on some trivial code took over 10 seconds.
  - eigenspace 6y ago
    The Debugger has come a long way, here's it running in 1.5.0 on my machine: julia> @time using Debugger 0.115907 seconds (202.08 k allocations: 13.215 MiB) julia> @time @run sin(1) 1.438537 seconds (1.85 M allocations: 90.376 MiB, 0.80% gc time) 0.8414709848078965 julia> @time @run sin(1) 0.003900 seconds (23.39 k allocations: 1.057 MiB) 0.8414709848078965
    - bananaquant 6y ago
      Whoa. This looks really promising now.
pdeffebach 6y ago
Sure, Julia doesn't have an industry-tested QR code maker (though if you google you will find some options). But it's worth noting that CSV.jl is a file that was entirely re-written in the past 6 months and has probably the fastest performance of any CSV parser currently used. It was written using pure julia and takes advantage of tons of Base-julia features as well as multi-purpose packages. Julia's design makes it incredible easy to write the kinds of tools you want in a flexible way.
6y ago

tastyminerals 6y ago

Julia is fast but not faster and very memory hungry. If you care about squeezing every bit of performance you generally go to C++. If you too lazy for C++ you go D. Hence to me, Julia is an odd tool. Interesting but more as a language with some cool scientific libs that Python might not yet have.

LolWolf 6y ago
This is what I meant when I stated > It's amazing to realize that writing down the first thing that comes to your head is usually like 80% as fast as a good, performant implementation. (As someone who has done a decent amount of work in performance engineering for embedded platforms, I really enjoy squeezing out the last drop of performance from most programs, but doing this for every single first-pass at a program, like in Python, is rather annoying if this is what is needed to get a usable implementation.) Yes, Julia is not necessarily faster than a good C implementation (that doesn't leak, etc), but, like Python, what would be a 300-line C implementation, where one has to somewhat carefully manage typing and the abstraction is really rather complicated for something that is mathematically simple, we can usually write 20 lines of very performant Julia that is 95% as fast. Attempting to do something relatively similar in Python is often slow enough that giving a practical implementation essentially needs to be coded in C and interfaced with Python, where we return (again!) back to the same problem we had before: writing a 300+ line C file for something that should be rather simple, mathematically speaking.
miles7 6y ago
Another important consideration is library development. As someone developing a large library, when we were previously developing in C++ we would encounter large barriers where some design goal we had either couldn't be done in the language in a practical sense or would require hours of tweaking things like template constraints to work correctly. Our users also had such a hard time extending our library's features they usually gave up and just waited for us to add features for them. Now that we're developing in Julia we can realize our designs as we envisioned them with very little code. Features like multiple dispatch have been a lifesaver for us. And we are getting performance that is quite close to C++. Now we're looking forward to using features like composable multithreading. One could wonder "why not use python?" but for performance reasons one ends up with the 'two-language problem' which we wanted to avoid.