Julia 1.8(julialang.org)
julialang.org
Julia 1.8
https://julialang.org/blog/2022/08/julia-1.8-highlights/
101 comments
By the way, the allocation profiler visualization is a cherry on top of all the improvements to VS Code for Julia [https://www.julia-vscode.org/] that make for a really good development environment now. (See the JuliaCon talk "Julia in VS Code - What's New" [https://www.youtube.com/watch?v=Okn_HKihWn8] for details on others.)
I never thought I'd move away from Vim, but the ease of use and polish here make it worth switching (with maybe Neovim as the backend at some point), rather than try to recreate it in Vim.
I never thought I'd move away from Vim, but the ease of use and polish here make it worth switching (with maybe Neovim as the backend at some point), rather than try to recreate it in Vim.
Great improvements! Congrats on the release.
I don't like the ergonomics of `mutable struct` vs (immutable) `struct`. Adding `const` seems like another step in the wrong direction. Right now, there's `struct` + `Ref{T}` fields for having a immutable struct with fields that can be mutated VS `mutable struct` + `const` fields for a mutable struct with fields that can't be mutated. And defining mutability at the `struct` level is kind of painful.
Sometimes I want to accept user input in a type checked manner (i.e. not storing them in dictionaries and using typed struct fields) and then pass that struct into a core algorithm where execution needs to be fast (i.e. aligned memory, immutable structs etc). Rust does this by making the mutability declared at an individual function level or during access to the struct value. In Julia, I have to decide ahead of time and that changes how users would use a library of mine.
I also dislike that syntax `a.b += 1` is not allowed for fields in immutable structs. I would love it if `@immutable_mutate a.b += 1` de-sugared to `a = A(b = a.b + 1, a...)` or the equivalent. If this existed I think I would just use immutable structs ALL the time. If a macro for that existed in Base Julia that would be amazing. (I don't want to use third party libraries for this.)
I'm (cautiously?) optimistic that Julia will be absolutely awesome in like 5 years. Currently, 90% of my work in Julia is painful because of poor developer workflow / tools. But when I need to do the remaining 10% (performance / optimization of code), Julia is amazing. Right now, it is probably easier to write code in Python (with type hints) and drop down to Rust or Go whenever performance is needed, than to start with Julia in the first place.
I don't like the ergonomics of `mutable struct` vs (immutable) `struct`. Adding `const` seems like another step in the wrong direction. Right now, there's `struct` + `Ref{T}` fields for having a immutable struct with fields that can be mutated VS `mutable struct` + `const` fields for a mutable struct with fields that can't be mutated. And defining mutability at the `struct` level is kind of painful.
Sometimes I want to accept user input in a type checked manner (i.e. not storing them in dictionaries and using typed struct fields) and then pass that struct into a core algorithm where execution needs to be fast (i.e. aligned memory, immutable structs etc). Rust does this by making the mutability declared at an individual function level or during access to the struct value. In Julia, I have to decide ahead of time and that changes how users would use a library of mine.
I also dislike that syntax `a.b += 1` is not allowed for fields in immutable structs. I would love it if `@immutable_mutate a.b += 1` de-sugared to `a = A(b = a.b + 1, a...)` or the equivalent. If this existed I think I would just use immutable structs ALL the time. If a macro for that existed in Base Julia that would be amazing. (I don't want to use third party libraries for this.)
I'm (cautiously?) optimistic that Julia will be absolutely awesome in like 5 years. Currently, 90% of my work in Julia is painful because of poor developer workflow / tools. But when I need to do the remaining 10% (performance / optimization of code), Julia is amazing. Right now, it is probably easier to write code in Python (with type hints) and drop down to Rust or Go whenever performance is needed, than to start with Julia in the first place.
The syntax sugar you are looking for "mutating" the immutable stricts is basically what Accessors.jl does.
I don't really see a reason to bring it into Base Julia if it doesn't need special things to work. The compiler can and will optimize out the stack allocation
Very welcome changes. Well done to the team.
The 'typed non-const globals' are a welcome syntax update for the sake of consistency with the rest of the language ... but it's worth pointing out that const globals effectively had the same effect, since you actually were allowed to redefine a const-labelled variable, and you were only prohibited from changing their type. Earlier versions of Julia silently ignored such redefinitions, but a warning was added later on whenever a redefinition of a const variable was detected. So I guess the only difference between the two now is that one will issue a warning and the other will not? I don't know if the two also have some hidden performance differences that are not obvious from this post. Regardless, still a small but welcome change nonetheless.
The 'typed non-const globals' are a welcome syntax update for the sake of consistency with the rest of the language ... but it's worth pointing out that const globals effectively had the same effect, since you actually were allowed to redefine a const-labelled variable, and you were only prohibited from changing their type. Earlier versions of Julia silently ignored such redefinitions, but a warning was added later on whenever a redefinition of a const variable was detected. So I guess the only difference between the two now is that one will issue a warning and the other will not? I don't know if the two also have some hidden performance differences that are not obvious from this post. Regardless, still a small but welcome change nonetheless.
The warning on redefining const globals is important. It's there because when you change a const global, that change may not get picked up in functions that use the variable (since you declared it as const). Using the type annotation prevents the compiler from saving the value of the global in other code and makes it do a lookup at runtime.
Functions can inline global const values and these will not be updated when you change it in a way that emits the warning. So it is not the same, the warning is not there for no reason.
>> A new tool has been added to provide insight into the way that loading dependencies contribute to the load time of a package.
That doesn't sound like an improvement to the dependencies loading... Which for me happens every time I change a struct and must reload Julia (which happens a lot when I'm prototyping code, which is what I do 90% of the time)...
That doesn't sound like an improvement to the dependencies loading... Which for me happens every time I change a struct and must reload Julia (which happens a lot when I'm prototyping code, which is what I do 90% of the time)...
> That doesn't sound like an improvement to the dependencies loading...
This gives the package authors a tool to basically "profile" the loading time of their package, which will help them optimize the loading time. So there _will_ be downstream improvement to package loading for us users too.
> Which for me happens every time I change a struct and must reload Julia (which happens a lot when I'm prototyping code, which is what I do 90% of the time)
The workaround involving `MyClass = MyClass1` that a sibling comment mentions comes from [this Revise.jl manual page](https://timholy.github.io/Revise.jl/stable/limitations/). Revise in general enables a few different ways to work around this, and it's useful to integrate into your workflow (as much as it feels weird at first to go from full REPL to half REPL-half editor).
This gives the package authors a tool to basically "profile" the loading time of their package, which will help them optimize the loading time. So there _will_ be downstream improvement to package loading for us users too.
> Which for me happens every time I change a struct and must reload Julia (which happens a lot when I'm prototyping code, which is what I do 90% of the time)
The workaround involving `MyClass = MyClass1` that a sibling comment mentions comes from [this Revise.jl manual page](https://timholy.github.io/Revise.jl/stable/limitations/). Revise in general enables a few different ways to work around this, and it's useful to integrate into your workflow (as much as it feels weird at first to go from full REPL to half REPL-half editor).
I saw this beautiful hack to get around this:
```
struct MyClass1
MyClass = MyClass1
```
Then, whenever you need to change MyClass, just add 1 to the version number of MyClass in those two or three instances, and the repl will just compile MyClass2 as a new class to be used for all future calls in the repl.
```
struct MyClass1
...
MyClass = MyClass1
```
Then, whenever you need to change MyClass, just add 1 to the version number of MyClass in those two or three instances, and the repl will just compile MyClass2 as a new class to be used for all future calls in the repl.
Not good if you want to also know stuff about the algorithms performance as that assignment is now accessing a global vs accessing a const.
That is not dependency loading.
About your issue, things you can do: - Put the struct inside another module. - Use this package: https://github.com/BeastyBlacksmith/ProtoStructs.jl . It gives you a simple @proto macro that you can prepend to the struct definition and makes all changes immediate.
About your issue, things you can do: - Put the struct inside another module. - Use this package: https://github.com/BeastyBlacksmith/ProtoStructs.jl . It gives you a simple @proto macro that you can prepend to the struct definition and makes all changes immediate.
It seems to address my problem of constantly restarting REPL (and yes, it triggers dependencies reloads; although not an issue with dependencies directly).
If it was stackoverflow, I would have accepted this answer with a kind comment :-) Thanks !
If it was stackoverflow, I would have accepted this answer with a kind comment :-) Thanks !
> > This gives the package authors a tool to basically "profile" the loading time of their package, which will help them optimize the loading time. So there _will_ be downstream improvement to package loading for us users too.
It lead to https://github.com/SciML/RecursiveArrayTools.jl/pull/217 . 6228.5 ms to 292.7 ms isn't too shabby.
It lead to https://github.com/SciML/RecursiveArrayTools.jl/pull/217 . 6228.5 ms to 292.7 ms isn't too shabby.
You can use a macro for your structs to make them changeable while prototyping. I think it is called @prototype or soemthing. You need a package for it. Google it.
There is RedefStructs: https://juliahub.com/ui/Packages/RedefStructs/nrk8Q/0.1.2
and ProtoStructs: https://github.com/BeastyBlacksmith/ProtoStructs.jl
I’ve never tried them, but they’re advertised as doing the job.
and ProtoStructs: https://github.com/BeastyBlacksmith/ProtoStructs.jl
I’ve never tried them, but they’re advertised as doing the job.
+1 for these packages; I’ve used both at different points.
Addendum for those who are new to this, the idea is to use these macros during development, and then get rid of them once the types stabilize (since they tend to have a performance cost).
Addendum for those who are new to this, the idea is to use these macros during development, and then get rid of them once the types stabilize (since they tend to have a performance cost).
Had it ever occurred to you - if this was a real issue how would anyone ever get any work done?
The answer is modules.
module X struct etc... end end #module
Change without reloading.
module X struct etc... end end #module
Change without reloading.
But doesn't defining a new module lead to code recompilation because all the functions in the module are new? Or does Revise.jl have some way around this?
yes, but it will only recompile the code in the module. All the dependents will already be compiled.
Right, but there is a separate new feature which caches more lowered code.
https://julialang.org/blog/2022/08/julia-1.8-highlights/#imp...
The core devs also said that they are aiming to cache native code in the next year or so.
https://julialang.org/blog/2022/08/julia-1.8-highlights/#imp...
The core devs also said that they are aiming to cache native code in the next year or so.
It is useful in determining which packages are dominating a given package’s load times, allowing for a better understanding of where to invest effort to reduce runtimes. This has already helped in directing efforts towards a number of common dependencies that increase load times…
This is very annoying but they recommend working in the REPL
Maybe I'm wrong, but I do work in the REPL. Each time I update a struct, I need to restart the REPL, hence reload dependencies... Of course, I could make my own sysimage, but it's a bit painful...
Is Julia "doomed" on this issue or is it just that they prefer to work on other use cases first ?
Is Julia "doomed" on this issue or is it just that they prefer to work on other use cases first ?
Julia's 1.8's load times are dramatically better than Julia 1.0's.
It keeps getting a bit better with every release.
But there is a project to cache native code (without needing to build a sysimage) that may make a huge difference...
But there is a project to cache native code (without needing to build a sysimage) that may make a huge difference...
It's not doomed, no. It's possible to have a low-latency Julia. It's just been happening slower that one could have hoped, especially for the users who started using Julia and could tolerate the latency because they expected it would be better soon.
* It's been reduced by like 75% (roughly, not sure about the real number) since Julia 1.0, so material progress has been made.
* In the future (I'm guessing 1-2 years, of course uncertain), native code caching could make a huge difference.
* On a similar timescale, Julia could allow compilation into static binaries. This could possibly be done for some dependencies that does not need to be generic, which would take another chunk of the compilation need off.
* It's been reduced by like 75% (roughly, not sure about the real number) since Julia 1.0, so material progress has been made.
* In the future (I'm guessing 1-2 years, of course uncertain), native code caching could make a huge difference.
* On a similar timescale, Julia could allow compilation into static binaries. This could possibly be done for some dependencies that does not need to be generic, which would take another chunk of the compilation need off.
Yes and no. There are ways around that for development like https://github.com/BeastyBlacksmith/ProtoStructs.jl.
But changing the definition of actual structs isn't very feasable because what happens with the structs that use the old definition, i.e an array of them.
No, you can use a macro which makes your structs slower but changeable. There are several Julia packages offering this functionality.
my go-to strategy is to just make a module and write code there, and then if I need to change a struct definition, I just change the name of the module and re-run it.
ReplMaker.jl can make this process more convenient, but in version 1.9, there’ll be a facility for that built into the regular REPL.
ReplMaker.jl can make this process more convenient, but in version 1.9, there’ll be a facility for that built into the regular REPL.
Every time I try Julia on my computer, there is so much lag between input and output, I just go back to R.
Startup time is not the only issue with Julia. Its error messages are long-winded and cryptic, and its manpages can be quite sketchy.
Even so, Julia is a good tool for intensive computation, and I think it will continue to replace Fortran for some such work.
Balance is the key. I use R all day long for data analysis, and don't really see Julia as competitive for such work. However, when it comes to numerical modelling, Julia competes well with Fortran and C/C++.
I think Julia should be thought of as a Fortran replacement for overnight/overweek jobs, not an R replacement for interactive work.
Even so, Julia is a good tool for intensive computation, and I think it will continue to replace Fortran for some such work.
Balance is the key. I use R all day long for data analysis, and don't really see Julia as competitive for such work. However, when it comes to numerical modelling, Julia competes well with Fortran and C/C++.
I think Julia should be thought of as a Fortran replacement for overnight/overweek jobs, not an R replacement for interactive work.
YMMV. For me, Julia is a wonderful replacement of Python/numpy/scipy/pandas/Jax/Tensorflow/cython/sympy that I use mainly for interactive work. I am a fairly competent Python developer and know how to do idiomatic high-performance Python. I needed to learn new idioms and workflows when switching to Julia, but I am drastically more productive in it, both in interactive and in batch work.
Can you give an example?
I will attempt to, but do let me know if this is not the type of examples you meant:
Julia idioms: Multimethods and multiple dispatch instead of python/java style OOP; Loops are fast, with zero-cost-abstractions and automatic SIMD, unlike python's need for vectorized libraries; "type-inferability" is incredibly important for good performance, which is quite different from python's duck typing (but the language is dynamic, so it is still an option); measuring how often your code allocates is the most trivial way to increase its performance by an order of magnitude.
Julia workflow: you *have* to change your workflow, compared to coming from python, otherwise the latency of the compiler would cause you deep enraging frustration: e.g. use Revise.jl/Pluto.jl/REPL, organize your code so that small pieces can be recompiled without having to restart your session; keep your workspace clean and your computational pipeline organized, so that reproducibility testing is easy.
Julia idioms: Multimethods and multiple dispatch instead of python/java style OOP; Loops are fast, with zero-cost-abstractions and automatic SIMD, unlike python's need for vectorized libraries; "type-inferability" is incredibly important for good performance, which is quite different from python's duck typing (but the language is dynamic, so it is still an option); measuring how often your code allocates is the most trivial way to increase its performance by an order of magnitude.
Julia workflow: you *have* to change your workflow, compared to coming from python, otherwise the latency of the compiler would cause you deep enraging frustration: e.g. use Revise.jl/Pluto.jl/REPL, organize your code so that small pieces can be recompiled without having to restart your session; keep your workspace clean and your computational pipeline organized, so that reproducibility testing is easy.
I'm curious what made you more productive. Was it not having to use those vectorized libraries?
I write machine learning code, so anything compute intensive is done with specialized libraries and the Python glue code usually has little overhead. Sometimes when writing complicated pipelines I spend a lot of effort on optimizing data transfers (between CPU and GPUs, between GPUs on the same server, between GPUs on different servers in a cluster, etc), but that effort has little to do with Python limitations (or so I think).
I write machine learning code, so anything compute intensive is done with specialized libraries and the Python glue code usually has little overhead. Sometimes when writing complicated pipelines I spend a lot of effort on optimizing data transfers (between CPU and GPUs, between GPUs on the same server, between GPUs on different servers in a cluster, etc), but that effort has little to do with Python limitations (or so I think).
A couple of things that made a difference for me:
- I actually like vectorized code, I find it easier to read, but especially in python, vectorized code still has some fixed overhead that can be prohibitive for smallish vectors.
- Some of the numerical code I run is not easy to batch, so tools like tensorflow are cumbersome. With Julia it is easy to make fast non-allocating code while writing in easy to read style like in Python. In Python you need to use C/Cython/Numba to achieve this, but then you lose interoperability with other Python packages. E.g. auto-diff through fast cython code does not work, while autodiff through my equally fast non-batched Julia code is trivial.
- Ecosystem: I work with differential equations a lot. Julia's SciML library (and its DifferentialEquations.jl sub-library) is light years ahead compared to any other tool in Python/R/Mathematica/Matlab/Maple. Speaking of python, solving differential equations in python feels like I am using technology that is quarter of a century old.
- In python I might write a nice and legible slowish implementation of something and then piece by piece I will start replacing it with cython. That requires a lot of boilerplate. In Julia I just write the slowish implementation with the same ease with which I would do it in python, but then I need to perform extremely minimal profile-guided changes with zero boilerplate to achieve the cython/numba type of performance. And again, I do not lose interoperability with other parts of the ecosystem when I do that.
- It is trivial to inspect the actual machine code that was generated for every single function you write. It is trivial to inspect exactly where allocations happen. Most of the ecosystem is in pure Julia, so it is trivial to edit fairly foundational pieces of the ecosystem and submit patches. On the other hand, the levels of abstraction in something like Jax/Tensorflow/Numba makes it relatively difficult to contribute.
- It is wild how much code reuse you can have with the multiple dispatch paradigm. Say I find someone's pet project on performing a complicated linear algebra algorithm. That code was probably written just to work with Float64, but thanks to multiple dispatch the compiler can generate specializations for esoteric higher-precision real number representations, or real numbers with error bars, or unitful numbers. I still need to do some sanity checks, because hidden assumptions might be problematic, but this level of interoperability is possible only with multiple dispatch (thinking of it as one of the "standard solutions" for the Expression Problem[1] really helped; [2] was also informative). I think the GPU libraries for Julia are a good example of multiple dispatch working well in that sense.
[1]: https://en.wikipedia.org/wiki/Expression_problem [2]: https://www.youtube.com/watch?v=kc9HwsxE1OY
- I actually like vectorized code, I find it easier to read, but especially in python, vectorized code still has some fixed overhead that can be prohibitive for smallish vectors.
- Some of the numerical code I run is not easy to batch, so tools like tensorflow are cumbersome. With Julia it is easy to make fast non-allocating code while writing in easy to read style like in Python. In Python you need to use C/Cython/Numba to achieve this, but then you lose interoperability with other Python packages. E.g. auto-diff through fast cython code does not work, while autodiff through my equally fast non-batched Julia code is trivial.
- Ecosystem: I work with differential equations a lot. Julia's SciML library (and its DifferentialEquations.jl sub-library) is light years ahead compared to any other tool in Python/R/Mathematica/Matlab/Maple. Speaking of python, solving differential equations in python feels like I am using technology that is quarter of a century old.
- In python I might write a nice and legible slowish implementation of something and then piece by piece I will start replacing it with cython. That requires a lot of boilerplate. In Julia I just write the slowish implementation with the same ease with which I would do it in python, but then I need to perform extremely minimal profile-guided changes with zero boilerplate to achieve the cython/numba type of performance. And again, I do not lose interoperability with other parts of the ecosystem when I do that.
- It is trivial to inspect the actual machine code that was generated for every single function you write. It is trivial to inspect exactly where allocations happen. Most of the ecosystem is in pure Julia, so it is trivial to edit fairly foundational pieces of the ecosystem and submit patches. On the other hand, the levels of abstraction in something like Jax/Tensorflow/Numba makes it relatively difficult to contribute.
- It is wild how much code reuse you can have with the multiple dispatch paradigm. Say I find someone's pet project on performing a complicated linear algebra algorithm. That code was probably written just to work with Float64, but thanks to multiple dispatch the compiler can generate specializations for esoteric higher-precision real number representations, or real numbers with error bars, or unitful numbers. I still need to do some sanity checks, because hidden assumptions might be problematic, but this level of interoperability is possible only with multiple dispatch (thinking of it as one of the "standard solutions" for the Expression Problem[1] really helped; [2] was also informative). I think the GPU libraries for Julia are a good example of multiple dispatch working well in that sense.
[1]: https://en.wikipedia.org/wiki/Expression_problem [2]: https://www.youtube.com/watch?v=kc9HwsxE1OY
some of the error messages are about to get much better (see https://github.com/JuliaLang/julia/pull/46372).
I find Julia to be pretty good for interactive work, but there definitely are some rough edges that still need smoothing.
I find Julia to be pretty good for interactive work, but there definitely are some rough edges that still need smoothing.
I'm kind of on the fence with Julia, never used it in anger. But to me it seems much more of a Matlab or Python replacement than a Fortran replacement? Meaning that (in my perhaps limited view) it's main usefulness is in making algorithm development much faster and smoother.
However, once a new very fast algorithm has been discovered and tested and everyone agrees it is good, someone will probably implement it in Fortran or C or even assembly and optimize the shit out of it.
One thing that supports this view is that there are several Julia packages that are wrappers around existing C/Fortran/C++ libraries, and basically no examples (that I know) of people porting existing libraries to Julia.
However, once a new very fast algorithm has been discovered and tested and everyone agrees it is good, someone will probably implement it in Fortran or C or even assembly and optimize the shit out of it.
One thing that supports this view is that there are several Julia packages that are wrappers around existing C/Fortran/C++ libraries, and basically no examples (that I know) of people porting existing libraries to Julia.
For some examples of people porting existing C++ Fortran libraries to julia, you should check out https://github.com/JuliaLinearAlgebra/Octavian.jl, https://github.com/dgleich/GenericArpack.jl, https://github.com/apache/arrow-julia (just off the top of my head). These are all ports of C++ or Fortran libraries that match (or exceed) performance of the original, and in the case of Arrow.jl is faster, more general, and 10x less code.
As with the others, I'll strongly disagree and chime in with a few examples off the top of my head:
- ITensors.jl : They started moving from a C++ to Julia a couple years ago and now their webpage doesn't even mention their original C++ implementation on its homepage anymore https://itensor.org/
- DifferentialEquations.jl : This has many state of the art differentiatial equation solving facilities in it, many of which are improvements over old Fortran libraries.
- SpecialFunctions.jl, Julia's own libm, Bessels.jl, SLEEFPirates.jl : Many core math functions have ancient Fortran or C implementations from OpenLibm or whatever, and they're being progressively replaced with better, faster versions written in pure julia that outperform the old versions.
- ITensors.jl : They started moving from a C++ to Julia a couple years ago and now their webpage doesn't even mention their original C++ implementation on its homepage anymore https://itensor.org/
- DifferentialEquations.jl : This has many state of the art differentiatial equation solving facilities in it, many of which are improvements over old Fortran libraries.
- SpecialFunctions.jl, Julia's own libm, Bessels.jl, SLEEFPirates.jl : Many core math functions have ancient Fortran or C implementations from OpenLibm or whatever, and they're being progressively replaced with better, faster versions written in pure julia that outperform the old versions.
> One thing that supports this view is that there are several Julia packages that are wrappers around existing C/Fortran/C++ libraries
That's an understandable misconception. But the reason these packages use C/Fortran libraries is because they're already there, and writing a wrapper is much easier than rewriting the library in Julia. It's not a performance thing, it's a person-hours thing and wanting to use the libraries right now.
On the one hand, this means you have binary dependencies and FFI you have to manage.
On the other hand, it saves you a lot of niggly optimization work and dealing with edge cases, which the C/Fortran libraries have already gone through and done for you.
Once the former starts to outweight the latter and/or more person-hours become available, the libraries start to get ported to be fully in Julia. And the tools available in the ecosystem and the compiler codegen are good enough that there's no artifical performance ceiling due to being in Julia i.e. you do get performance equivalent to being in C or Fortran.
That's an understandable misconception. But the reason these packages use C/Fortran libraries is because they're already there, and writing a wrapper is much easier than rewriting the library in Julia. It's not a performance thing, it's a person-hours thing and wanting to use the libraries right now.
On the one hand, this means you have binary dependencies and FFI you have to manage.
On the other hand, it saves you a lot of niggly optimization work and dealing with edge cases, which the C/Fortran libraries have already gone through and done for you.
Once the former starts to outweight the latter and/or more person-hours become available, the libraries start to get ported to be fully in Julia. And the tools available in the ecosystem and the compiler codegen are good enough that there's no artifical performance ceiling due to being in Julia i.e. you do get performance equivalent to being in C or Fortran.
> One thing that supports this view is that there are several Julia packages that are wrappers around existing C/Fortran/C++ libraries, and basically no examples (that I know) of people porting existing libraries to Julia.
This is totally off-base :-) There’s even discussion of implementing a lot of linear algebra stuff in Julia, instead of just falling back to BLAS (for very good reasons), see eg https://youtu.be/KQ8nvlURX4M
Those wrappers are just to bootstrap the ecosystem for immediate usefulness.
So, over time, I expect Julia to become better and better for everything from exploratory development to workhorse numerical computing infrastructure. Once compiled binaries are feasible, I wouldn’t be surprised if other languages start wrapping algorithms implemented in Julia.
This is totally off-base :-) There’s even discussion of implementing a lot of linear algebra stuff in Julia, instead of just falling back to BLAS (for very good reasons), see eg https://youtu.be/KQ8nvlURX4M
Those wrappers are just to bootstrap the ecosystem for immediate usefulness.
So, over time, I expect Julia to become better and better for everything from exploratory development to workhorse numerical computing infrastructure. Once compiled binaries are feasible, I wouldn’t be surprised if other languages start wrapping algorithms implemented in Julia.
The "right" way to use Julia is to connect to a REPL. Once you pay the cost of compiling, it's insanely fast. As long as you keep your REPL open your compilations will remain valid and cached, and you won't have to repay the cost of compilation until you restart your REPL (which you should do very rarely).
There's a well-known concept in Julia, [time-to-first-plot](https://discourse.julialang.org/t/time-to-first-plot-clarifi...), which encapsulates the large lag the first time you call a function. But there is no such thing as time-to-second-plot — the second plot is always fast.
There's a well-known concept in Julia, [time-to-first-plot](https://discourse.julialang.org/t/time-to-first-plot-clarifi...), which encapsulates the large lag the first time you call a function. But there is no such thing as time-to-second-plot — the second plot is always fast.
Yes, I have heard that. I'm used to frequently restarting R to ensure that codes are reproducible and can run in a clean environment. That's a best practice in technical research that seems at odds with the Julia workflow.
I disagree with the conclusion. I agree on the best practices you mentioned, and I follow them when working in Julia (and the Julia Manifest.toml files provides for much better reproducibility compared to e.g. conda). Avoiding recompilation of code that has not changed is not at odds with rerunning your computational pipeline often to ensure reproducibility. It is true though that you can not translate the muscle memory you have in R to Julia.
Also, I would say actual best practices would be to have CI, not to be rerunning your code manually.
Also, I would say actual best practices would be to have CI, not to be rerunning your code manually.
As someone who does work in similar domains as yourself, I find that making a main function which contains all of the code I want to be reproducible is a good way to achieve both high speed and running code in a clean environment.
Writing .jl files in VSCode and sending code to the integrated REPL with shift-return for playing around is great and then when I want to run code properly I just comment out my testing code, wrap my important code in a main() function (which is sometimes everything apart from the imports) and then just make sure that I'm not referring to any variables or function methods defined that are now commented. This is made relatively easy as VSCode will immediately complain about possible method errors.
It's not a perfect substitution for having fast startup and when I go back to Python or R for things like the holy grail called Tidyverse then it feels like a weight off my back, but the benefit of doing things the Julia way is that your code has a clear starting point and it helps readability as you can see what every script is supposed to do.
Writing .jl files in VSCode and sending code to the integrated REPL with shift-return for playing around is great and then when I want to run code properly I just comment out my testing code, wrap my important code in a main() function (which is sometimes everything apart from the imports) and then just make sure that I'm not referring to any variables or function methods defined that are now commented. This is made relatively easy as VSCode will immediately complain about possible method errors.
It's not a perfect substitution for having fast startup and when I go back to Python or R for things like the holy grail called Tidyverse then it feels like a weight off my back, but the benefit of doing things the Julia way is that your code has a clear starting point and it helps readability as you can see what every script is supposed to do.
I cannot edit my note, but to explain a bit more, I do know that Julia is a compiled language, and is fast for some workflows. But for my data science and statistics workflow, it is slower than R. And I have a pretty standard workflow: clean data, plot data, maybe fit a linear regression model or something like that.
it's called JIT, comparing to R, it probably would speed up some moderately complex calculation by 100x to 1000x, but if you don't have the type of workload, feel free to use R -- people should use whatever suits them the best!
That is one of the things this update specifically addresses (and the next 1.9 will do more of). There's a tangible difference in the REPL, things feel snappier. I'm sure there will still be lags in the odd place, and there's still a first time compilation, but that compiled result is cached a lot more, and so when you restart session as you mention below, that cache will be preserved.
Feels like yesterday when I saw the same post for 1.7. Very happy things are coming along!
Wish julia would get some decent packages on main distros at least for the latest stable release. The tooling is slowly but surely improving, but that's hard to do when you're always 1/2 versions behind the latest release.
Take a look at `juliaup`. It's allows you to manage multiple Julia versions and makes you independent of the distribution.
Wow, thanks a lot. I'm kind of surprised I didn't knew this because I recall searching quite a bit for such a tool/script. In my defense it was around when 1.6 got released ... if anything this shows how fast the julia community grows(or how slow I keep up).
It's fairly new. It was announced at JuliaCon last month (early this month? I forget) that it will soon be the default recommended way to install Julia moving forward. I'm personally hugely excited about it (Julia's been my main squeeze since v0.3-alpha). They just need to work on non-interactive installs so it's easy to incorporate juliaup in a docker container (this may actually be fixed, haven't checked in a couple weeks).
A few months back this article[0] was posted here (Why I no longer recommend Julia). Does anyone following the Julia community know if the situation is getting better?
[0] https://yuri.is/not-julia/
[0] https://yuri.is/not-julia/
In my view, yes, it's getting better, but only slowly. There has not been a decisive "let's fix this issue" moment.
Recent releases have had longer cycles with more thorough testing. Julia's CI has expanded. Static analysis is improving. The linter is improving. That all adds together to a more stable Julia with fewer bugs.
However, there has been made little progress on actually improving Julia's tests, or documenting abstract types, or on formalizing interfaces, nor have there been a big dedicated "fix bugs" push.
So yes: It's getting better, but slowly and not yet by leaps and bounds.
Recent releases have had longer cycles with more thorough testing. Julia's CI has expanded. Static analysis is improving. The linter is improving. That all adds together to a more stable Julia with fewer bugs.
However, there has been made little progress on actually improving Julia's tests, or documenting abstract types, or on formalizing interfaces, nor have there been a big dedicated "fix bugs" push.
So yes: It's getting better, but slowly and not yet by leaps and bounds.
I mean if you go through them yourself and you'll see most (if not all) of those are closed. And the majority of the others dealt with composability issues between custom packages/libraries and not base Julia. Honestly it's a tooling + linter problem, and the lack of progress there (plus the general adversarial/celebratory tenor of that thread) made me pretty glad I've just moved onto Rust + python again. It's just too demoralizing from a dev's perspective to see.
Don't get me wrong, I love multiple dispatch and Julia's composability + speed make it a no brainer for science/quant econ teams to adopt (and using it to train models on TPUs is a actually a sneaky way to save time + $), but they've lost the "culture" war and I can't see the entrenched masses here or elsewhere changing their minds on it. Not sure whether it's for job security sake or they got sick of all the "Julia is faster than/will replace X" evangelism or Plots loaded too slowly the one time they tried it years ago or a combination.
Don't get me wrong, I love multiple dispatch and Julia's composability + speed make it a no brainer for science/quant econ teams to adopt (and using it to train models on TPUs is a actually a sneaky way to save time + $), but they've lost the "culture" war and I can't see the entrenched masses here or elsewhere changing their minds on it. Not sure whether it's for job security sake or they got sick of all the "Julia is faster than/will replace X" evangelism or Plots loaded too slowly the one time they tried it years ago or a combination.
So you've decided to abandon a technology stack because of an unfavorable discussion thread on HN?
No, because of lack of progress in areas I care about. It's just a tool that currently doesn't fit my most crucial needs, so I picked up other tools.
The discussion was further evidence of the reality that I'd already come to terms with; the lack of inroads in building a larger community and general ecosystem is partly because of a lack of focus on things like tooling, linting, documentation standards, etc and partly because of a weird amount of disdain for the language. I can help with the former, but I don't have the time or energy for the latter because it's actually a set of large, long-term marketing, organizational, and psychological problems to overcome. Maybe someday down the road I'll be back, but I've given it a shot for about 8-9 years now.
The discussion was further evidence of the reality that I'd already come to terms with; the lack of inroads in building a larger community and general ecosystem is partly because of a lack of focus on things like tooling, linting, documentation standards, etc and partly because of a weird amount of disdain for the language. I can help with the former, but I don't have the time or energy for the latter because it's actually a set of large, long-term marketing, organizational, and psychological problems to overcome. Maybe someday down the road I'll be back, but I've given it a shot for about 8-9 years now.
> Does anyone following the Julia community know if the situation is getting better?
Which situation exactly? The linked article lacks a salient point, so there's really no way to know what you're referring to.
Which situation exactly? The linked article lacks a salient point, so there's really no way to know what you're referring to.
I disagree with that completely, and I'm deep into the Julia community. The article is very, very clear that the author considers Julia's level of bugginess to be unacceptable.
IMO, it has a clear salient point:
“My conclusion after using Julia for many years is that there are too many correctness and composability bugs throughout the ecosystem to justify using it in just about any context where correctness matters.”
“My conclusion after using Julia for many years is that there are too many correctness and composability bugs throughout the ecosystem to justify using it in just about any context where correctness matters.”
[deleted]
I’m waiting for interfaces in Julia 2.0…
I’m impressed with all that they’ve done, but for finding new talent and dealing with such a strange tool and with multiple dispatch being such an awkward paradigm compared to traditional OOP, I still don’t think it’s worth the trouble yet.
Additionally, everybody I’ve met thus far for interviews who knew Julia, also knew either Python or R, so it’s sort of a “why bother?” scenario.
I’m impressed with all that they’ve done, but for finding new talent and dealing with such a strange tool and with multiple dispatch being such an awkward paradigm compared to traditional OOP, I still don’t think it’s worth the trouble yet.
Additionally, everybody I’ve met thus far for interviews who knew Julia, also knew either Python or R, so it’s sort of a “why bother?” scenario.
IMHO multiple dispatch feels more awkward compared to OOP only because we’re far more used to the latter. And if that’s what you want to stick to, I guess you could program in that style by making the “object” the first method argument, and wrapping the functions along with the struct definition in a module.
> Additionally, everybody I’ve met thus far for interviews who knew Julia, also knew either Python or R, so it’s sort of a “why bother?” scenario.
Well, if it isn’t substantially improving on a pain point that makes you really want to switch, then why bother? :-)
Eg: For a problem I happened to be working on yesterday, I probably could have reduced ~1000 lines of Python code to ~100 lines of Julia code (all because of multiple dispatch… not just by calling some library) and cut through a lot of the not just tedious but also error-prone boilerplate (lots of little indexing details).
> Additionally, everybody I’ve met thus far for interviews who knew Julia, also knew either Python or R, so it’s sort of a “why bother?” scenario.
Well, if it isn’t substantially improving on a pain point that makes you really want to switch, then why bother? :-)
Eg: For a problem I happened to be working on yesterday, I probably could have reduced ~1000 lines of Python code to ~100 lines of Julia code (all because of multiple dispatch… not just by calling some library) and cut through a lot of the not just tedious but also error-prone boilerplate (lots of little indexing details).
OOP is nice to stumble through because what's possible for a given object is spelled out. Your IDE can suggest a list of possible methods and you pick the one that sounds good. Whereas in Julia there's an infinite number of potential functions that can operate on the value you have, and I haven't seen a good way to list them.
Fair point. I wonder whether this is a good reason to rethink the UI of autocomplete.
1. Instead of operating sequentially as you type, maybe one could type out the variable(s) one wants to use, select them and then have the ask the language analyzer to suggest functions?
2. Another change (possibly more effective) is to stop thinking in terms of data (and completing with functions) and instead start thinking in terms of functions (and completing with data). Just thinking out loud what might be a different thought process… The language (and types/classes) are not there to constrain you; write down the code/functionality you would like, and then find/construct the types you need to have that code be true :-?
1. Instead of operating sequentially as you type, maybe one could type out the variable(s) one wants to use, select them and then have the ask the language analyzer to suggest functions?
2. Another change (possibly more effective) is to stop thinking in terms of data (and completing with functions) and instead start thinking in terms of functions (and completing with data). Just thinking out loud what might be a different thought process… The language (and types/classes) are not there to constrain you; write down the code/functionality you would like, and then find/construct the types you need to have that code be true :-?
> rethink the UI of autocomplete ... maybe one could type out the variable(s) one wants to use, select them and then have the ask the language analyzer to suggest functions?
This wasn't mentioned in this blog post, but the NEWS.md with a more complete changelog mentions a new feature in the REPL
> ?(x, y followed by TAB displays all methods that can be called with arguments x, y, .... (The space at the beginning prevents entering help-mode.) MyModule.?(x, y limits the search to MyModule.
There's long been discussion of this kind of redesigned autocomplete UI that's suitable for this paradigm, in the Julia community. I really like this solution that they ultimately went with.
This wasn't mentioned in this blog post, but the NEWS.md with a more complete changelog mentions a new feature in the REPL
> ?(x, y followed by TAB displays all methods that can be called with arguments x, y, .... (The space at the beginning prevents entering help-mode.) MyModule.?(x, y limits the search to MyModule.
There's long been discussion of this kind of redesigned autocomplete UI that's suitable for this paradigm, in the Julia community. I really like this solution that they ultimately went with.
Your #2 makes much more sense to me than your #1 or the GP’s comment. Suppose my data or variable is a floating-point number. How does it help me to have my editor listing the thousands of functions that can operate on a float? Say what you want to do by writing the verb (function) that does what you want, then give it the arguments that you want it to act upon.
> And if that’s what you want to stick to, I guess you could program in that style by making the “object” the first method argument, and wrapping the functions along with the struct definition in a module.
You might not even need to do that. This package was released recently, implementing OOP: https://github.com/Suzhou-Tongyuan/ObjectOriented.jl
You might not even need to do that. This package was released recently, implementing OOP: https://github.com/Suzhou-Tongyuan/ObjectOriented.jl
An odd take by the GP, as the usual version of OOP (I assume “traditional OOP” doesn’t mean Smalltalk, but the class-based horror used in Python or Java) is an awkwardly constrained, special case of multiple dispatch where we can only dispatch on the first argument.
I was thinking about this recently, in the context of why it feels so weird to explain multiple dispatch. It's because it's the natural way to think about functions, once you unlearn the "awkwardly constrained , special case" as you put it. So it starts to feel obvious, a way of doing things that would need no explanation.
It's just that unlearning things like this is a hard process that not a lot of people have experience with, especially compared with learning things in a purely additive sense.
It's just that unlearning things like this is a hard process that not a lot of people have experience with, especially compared with learning things in a purely additive sense.
I agree, but I can also understand that the familiarity of OOP patterns really helps “grease the wheels” for a lot of people. With something new (even if strictly superior in capability) they now need to re-think questions of architecture and code organization every time they sit down to write code. Personally, I found multiple dispatch (and Julia) to be a breath of fresh air because I never found classes/OOP too natural (for the kinds of problems I’m most interested in) and hated the amount of boilerplate & repetition. But if someone comes in with a different perspective, the radical modularity and code reuse can take some time to get used to :-)
> … doesn’t mean Smalltalk, but the class-based horror used in Python or Java…
If you're suggesting Smalltalk is not class-based then what do you mean by "class-based" ?
If you're suggesting Smalltalk is not class-based then what do you mean by "class-based" ?
I was trying, clumsily, to bring to mind the differences between Smalltalk’s object/message model and the class/method model of Python, etc.
In the first case, program + program changes; in the second case, program definitions.
Smalltalk language implementations provide a prototype program and we make our software by making changes to that prototype — by sending messages to instantiated objects — not by writing definitions.
Smalltalk language implementations provide a prototype program and we make our software by making changes to that prototype — by sending messages to instantiated objects — not by writing definitions.
I did some dynamical systems stuff in Julia that absolutely blew Python and Matlab out of the water, both in terms of speed and ergonomics, so that's what baited the hook for me.
Multiple dispatch is odd. It took me a while to get used to it, but it turns out to be pretty useful for a lot of math-y things where there are speed-ups for special cases (symmetric matrix, etc) or you need to wrangle data into a common structure first (one variance, list of variances, covariance matrix, etc).
Multiple dispatch is odd. It took me a while to get used to it, but it turns out to be pretty useful for a lot of math-y things where there are speed-ups for special cases (symmetric matrix, etc) or you need to wrangle data into a common structure first (one variance, list of variances, covariance matrix, etc).
Interfaces/Traits can be done with macros today.
macOS on ARM is still tier 2 and not tier 1?
Not related to this but I think Julia is too ambitious too succeed, at least in a normal timeframe. Languages like Rust and even Python managed to improve a lot more compared to their goals than Julia compared to the goal "a modern language, a modern top edge research level scientific library rewritten from scratch".
I enjoy the community that is backing it, really, but there is still no solid core. A lot of research level cool functions and algorithms, yes. But you still suffer from lagginess, inexact calculations and language idiosyncrasies. In short too much dispersion and divergence in this project. It's almost like this language was designed by academics...
Not related to this but I think Julia is too ambitious too succeed, at least in a normal timeframe. Languages like Rust and even Python managed to improve a lot more compared to their goals than Julia compared to the goal "a modern language, a modern top edge research level scientific library rewritten from scratch".
I enjoy the community that is backing it, really, but there is still no solid core. A lot of research level cool functions and algorithms, yes. But you still suffer from lagginess, inexact calculations and language idiosyncrasies. In short too much dispersion and divergence in this project. It's almost like this language was designed by academics...
Rust is keeping macOS Arm as Tier 2 as well, mostly not because of lack of interest but because CI platforms can’t support all the demand for Arm builds. MacStadium, Azure, AWS and others keep adding extra capacity but the build queues are still too long.
So you either promote Arm Mac as tier 1, but now every PR takes extra hours to get merged, or you keep it at tier 2 for now and only build on Arm, say, once a day. Rust developers choose the later, because with their commit traffic they can’t afford such delays.
As the build machines capacity increases arm macOS will be promoted to Tier 1. Don’t read too much into tiers. Tier 2 is still pretty well supported from a language user perspective. Julia situation is pretty much the same.
So you either promote Arm Mac as tier 1, but now every PR takes extra hours to get merged, or you keep it at tier 2 for now and only build on Arm, say, once a day. Rust developers choose the later, because with their commit traffic they can’t afford such delays.
As the build machines capacity increases arm macOS will be promoted to Tier 1. Don’t read too much into tiers. Tier 2 is still pretty well supported from a language user perspective. Julia situation is pretty much the same.
We actually have a stack of M1 mac minis on top of a refrigerator to run CI. It's working pretty well for how janky it is.
You might be right that Julia's sky high ambitions make it seem like a failure no matter what it does. I mean, it could have strived for just being a pleasant dynamic language with a fast amortized running time, and then it would have succeeded in 2018.
But is it not better to both achieve you mediocre goals and also have extremely ambitious goals that may still be achieved, than merely having mediocre goals?
I don't really agree that Julia right now doesn't have anything to show for its huge amibitions. In my opinion it's already the best language for science by quite a large margin. I understand it still lacks some tooling, reliability and deployment options to be attractive for many industrial clients (though Julia is already making inroads in industry - I have an old friend from college who uses Julia in production). It's also understandable that some people used it and found the latency unacceptable. The thing is - there is no reason to believe that tooling, reliability and deployment options won't come around. The stuff is being built. It's just happening "too" slowly right now.
But is it not better to both achieve you mediocre goals and also have extremely ambitious goals that may still be achieved, than merely having mediocre goals?
I don't really agree that Julia right now doesn't have anything to show for its huge amibitions. In my opinion it's already the best language for science by quite a large margin. I understand it still lacks some tooling, reliability and deployment options to be attractive for many industrial clients (though Julia is already making inroads in industry - I have an old friend from college who uses Julia in production). It's also understandable that some people used it and found the latency unacceptable. The thing is - there is no reason to believe that tooling, reliability and deployment options won't come around. The stuff is being built. It's just happening "too" slowly right now.
MacOS on ARM is technically tier 2, but we expect to promote it to tier 1 within a month or so. Basically we just want to make sure that 1.8 is as stable on M1 as we think it is. Until you have thousands of users testing everything, it's hard to declare confidently that everything works perfectly.
You may have a particular measure of success in mind, but it seems to me that Julia has already succeeded: it is a new language for scientific computing that met its goals of providing high level abstractions and an expressive syntax while not compromising on performance. Its public release was in 2012 and it’s already one of only four languages used in high-performance scientific computing. Of course, in many areas its ecosystem is immature; but in others, such as differential equation solving, it’s a leader.
What the heck?
Before making a claim like this you better define what you mean by "succeed" and what you mean by "normal timeframe".
Julia has been around since 2010-ish. The equivalent timeframe for python was late-90s.
The federal reserve bank uses (used?) Julia to model economics... Jokes about whether that is a succeed or fail for society at large, aside, it's hard to argue that adoption by at least one very significant player doesn't constitute success for a PL.
Before making a claim like this you better define what you mean by "succeed" and what you mean by "normal timeframe".
Julia has been around since 2010-ish. The equivalent timeframe for python was late-90s.
The federal reserve bank uses (used?) Julia to model economics... Jokes about whether that is a succeed or fail for society at large, aside, it's hard to argue that adoption by at least one very significant player doesn't constitute success for a PL.
I don't think such a defensive response is necessary. Julia's claims have been rather lofty since the beginning and the degree to which they have been achieved is different to everyone.
Without defining more precisely what succeeding and the timeframe means it is difficult to know what OP was after but the fed example stands well on its own.
Without defining more precisely what succeeding and the timeframe means it is difficult to know what OP was after but the fed example stands well on its own.
This. I was hoping Julia would be a quicker and more pleasant R. Instead it's turning into a super ambitious language that wants to be as fast as C++ but that makes it slightly less pleasant and useful than R. And if I need C++ speed I can just write C++...
> And if I need C++ speed I can just write C++...
Maybe I'm being pedantic here, but surely you can't "just write C++". If you could, why would you ever use R, which is way slower, less backwards compatible and can't be shipped as a binary?
I'm guessing you use R because it's easier to use than C++, interactive, and quicker to get stuff done in. That sounds to me like a list of criteria where Julia should aspire to beating R - if we can.
Maybe I'm being pedantic here, but surely you can't "just write C++". If you could, why would you ever use R, which is way slower, less backwards compatible and can't be shipped as a binary?
I'm guessing you use R because it's easier to use than C++, interactive, and quicker to get stuff done in. That sounds to me like a list of criteria where Julia should aspire to beating R - if we can.
With RCpp writing a function in C++ that you can then use from R is easy. So you do as much as you can in R, then if you reach a bottleneck, use a lil CPP, then R. It's still nice.
Same with python. But then you have the following problem: How do you use tools that were designed to exploit the introspection of these languages when you have C++ submodules?
This is called "the two language problem", and it is not just about ergonomics (e.g. you do not seem to have issues with the ergonomics of this approach). Rather the issue is that now I can not have a library that introspects my R code and performs automatic differentiation or some other advanced compile pass over my code, because not all of the code is written in R. This is also why most of the advanced SciPy functionality can not be used with Tensorflow, or use Jax's autodiff feature with Pandas dataframes or Pillow images.
In many cases this might not matter, but when creating sophisticated large computational packages, the level of interoperability that Julia provides is both incredibly empowering and as of yet unsurpassed.
This is called "the two language problem", and it is not just about ergonomics (e.g. you do not seem to have issues with the ergonomics of this approach). Rather the issue is that now I can not have a library that introspects my R code and performs automatic differentiation or some other advanced compile pass over my code, because not all of the code is written in R. This is also why most of the advanced SciPy functionality can not be used with Tensorflow, or use Jax's autodiff feature with Pandas dataframes or Pillow images.
In many cases this might not matter, but when creating sophisticated large computational packages, the level of interoperability that Julia provides is both incredibly empowering and as of yet unsurpassed.
> when creating sophisticated large computational packages, the level of interoperability that Julia provides is both incredibly empowering and as of yet unsurpassed
It's difficult for outsiders to know what to think when confronted with so divergent opinions:
"I would hit bugs of this severity often enough to make me question the correctness of any moderately complex computation in Julia.
This was particularly true when trying a novel combination of packages or functions — composing together functionality from multiple sources was a significant source of bugs."
It's difficult for outsiders to know what to think when confronted with so divergent opinions:
"I would hit bugs of this severity often enough to make me question the correctness of any moderately complex computation in Julia.
This was particularly true when trying a novel combination of packages or functions — composing together functionality from multiple sources was a significant source of bugs."
That is a very reasonable complaint, and I think the core devs (of the language and of the flagship ecosystem projects) take it fairly seriously. For me personally, it has been incredibly empowering to be able to mix and match very diverse packages, but maybe I am just used to defensive coding: I start with tests, including randomized tests and contract tests.
On the other hand, though, I have not encountered more bugs in the Julia ecosystem than in the Sympy or Theano (deprecated now) or Tensorflow or Pytorch systems when I was using them to build "sophisticated large computational packages".
Maybe the happy users are just not as vocal, but that is a silly excuse.
On the other hand, though, I have not encountered more bugs in the Julia ecosystem than in the Sympy or Theano (deprecated now) or Tensorflow or Pytorch systems when I was using them to build "sophisticated large computational packages".
Maybe the happy users are just not as vocal, but that is a silly excuse.
Both opinions go hand in hand, in fact.
Julia allows packages to interoperate in a way most other mainstream languages simply don't, due to the combination of its multiple dispatch and the type hierarchy. The fact that the language allows this interoperability to such level is very useful and empowering. But making proper use of this interoperablity means writing careful generic code that doesn't make narrow assumptions based only on currently known uses of it.
Different parts of the ecosystem do this with different degress of care and success, with newer ones being better at it as lessons are learned and implemented. Yuri happened to work on parts of the ecosystem that were not-so-new, and made combinations that hadn't been commonly attempted. That doesn't mean that these weren't issues that need fixing and preventing in the future, for sure. But hitting bugs of this severity often isn't the typical experience for the average user - if it was, Julia would hardly have as many users, much less ones like NASA.
Julia allows packages to interoperate in a way most other mainstream languages simply don't, due to the combination of its multiple dispatch and the type hierarchy. The fact that the language allows this interoperability to such level is very useful and empowering. But making proper use of this interoperablity means writing careful generic code that doesn't make narrow assumptions based only on currently known uses of it.
Different parts of the ecosystem do this with different degress of care and success, with newer ones being better at it as lessons are learned and implemented. Yuri happened to work on parts of the ecosystem that were not-so-new, and made combinations that hadn't been commonly attempted. That doesn't mean that these weren't issues that need fixing and preventing in the future, for sure. But hitting bugs of this severity often isn't the typical experience for the average user - if it was, Julia would hardly have as many users, much less ones like NASA.
physicsguy(3)
`status --outdated` is something I've wished for many times, nice!
Typed globals will, at the least, make life easier for people new to Julia (and those teaching them).