An opposing viewpoint on the issues of Julia from a user of Julia:
"What's bad about Julia?"
https://viralinstruction.com/posts/badjulia/
Why We Use Julia, 10 Years Later
71–80 of 144 posts
Re: Why We Use Julia, 10 Years Later
#72Jose Storopoli (@storopoli): "I've made amazing friendships here, co-authored a free open access and open source Julia Data Science book with Rik Huijzer and Lazaro Alonso."
I just read this book. Every page was like, 'wow'.
A couple of questions I had afterwards:
* I saw the DateTime type, but it doesn't seem to have a timezone - how do you deal with timezones?
* How is it to work with async code?
* It's a garbage collected language, what are some techniques to avoid performance pitfalls due to that?
If there's other Julia programmers around, any answers would be much appreciated!
Re: Why We Use Julia, 10 Years Later
#73Earlier quoted context omitted.
For unix tools, I assume you mean command line tools? In which case how do you ameliorate the long startup time on each invocation?
Hehehe oh yeah, I almost forget about that because I stopped years ago bothering to actually make the tools into separate files that I start from the shell. It is more like Julia is my shell. I'll just have packages with common tools I use and launch them by calling functions from the REPL. I'll just have packages for doing doing image file conversions in batch, modifying source code, changing configuration files etc…
Aren't many bash programs written in C? So this is implying Julia is somehow faster than C? Obviously that can't quite be true, but I can definitely imagine that the algorithms implemented in Julia could be fast faster than other algorithms - since the community has such a heavy influence of very hardcore mathematicians that have a string stress towards speed. Probably most of the algorithms in Julia are state of the art and push the boundaries on time complexity.
Re: Why We Use Julia, 10 Years Later
#74Julia is a very pleasant language to work with. The type system, multiple dispatch, and package system all make it into top 10 of design. The only change I would recommend is to have a way to distinguish between creating and setting a variable. Without this distinction it is very easy (especially for someone with dyslexia) to misspell a variable and accidentally create a new one instead of assigning a value. Somethin…
Please, yes!
It may sound dumb, but such a "simple" change (simple conceptually, can't speak of the dev challenge involved) change would be an enormous quality of life increase to me. I've ended up looking into scoping rules and what not when bug-hunting because of this, but often just ended up going back to a language with stricter syntax around variable creation (goes for moving away from Python etc as well). The more the code, the bigger of an issue this becomes.
Re: Why We Use Julia, 10 Years Later
#75Make the package management more Cargo-like and I'd probably adopt it wholesale; whenever I've tried Julia in the past the user experience of just getting started has been the off-putting part.
Re: Why We Use Julia, 10 Years Later
#76I'm currently writing code with it. The language is really (really) nice to work with. - But the REPL lacks the ability to redefine structs on the go (which I can understand as it'd be tough to do, or simply not possible). But that, combined with the slow start up time makes life a bit harder than it should. Fortunately, one doesn't redefine its structs every day. - There are also lots of libraries but the quality of…
The C API for Julia also has almost no documentation. There is a getting started guide, which is great, but if you want to do anything more advanced (e.g. creating structs like in your example), you'll end up reading the source code to try to puzzle through which functions to use in julia.h. There's also an apparent limitation that whichever thread initializes Julia is the only one that can later eval code, which was…
I tried to integrate a Julia REPL into another application and the example on the website didn’t even compile.
Re: Why We Use Julia, 10 Years Later
#77Earlier quoted context omitted.
> There are also lots of libraries but the quality of the documentation is often sub par. One thing I think R does not get enough credit for is really strong enforcement of documentation. If you want to get a package in CRAN it is going to be more work to not document your library than to just document it correctly. As a result nearly every R package has very solid documentation, including a well formatted pdf manual…
R has superb documentation. I miss it with Python.
I don't know what libraries you're refering to. But most of the time, they barely document what they do. By barely I mean:
- parameters documentation can be understood only if you actually know the theory behind what the library documents. One may say that it's a good thing in the sense it prevents one to shoot himself in the foot but for discoverability, that's painful. I've done basic stuff such as GLM, LDA, PCA,... For example, there are several ways to do PCA's but which one do you choose ? Not everybody know the theory behind each PCA's formulation...
- examples are usually very limited and don't show what the library can do. For example, plots (the one from the base library) are really not well documented. Examples are really scarce and don't even show the graphics themselves.
- The package federation (not exactly documentation) is really bad : there are lots of library that overlap, that redefines symbols here and there without telling, etc.
So R documentation is so so... It feels like it suffers from lots of math explanation I've seen : a strong will to write the minimum possible which makes everything hard to get into.
I like R but documentation is not a strong point. Ecosystem is.
Re: Why We Use Julia, 10 Years Later
#78Earlier quoted context omitted.
" I mean, faster than r or Python (for which I could write fast code but that'd mean I'd have to change the way it is written)" You might benefit from numba. I've used it to speed my Python up enormously and completely painlessly just by adding decorators to critical functions. It's why I'm not considering moving to Julia.
There are so many ways to write R that can actually be very fast. R is a very different language as a whole and it has addressed a lot of problems these last 10 years. I might be biased but I really do like the functional side of R and how logical the libraries from Hadley Wickham have been designed. Python still doesn't feel like a natural fix for data science work. I am guessing it is more bias opinion but why base…
> There are so many ways to write R that can actually be very fast.
But it means that you have to work with arrays. For me it often means breaking the flow of my (code) explanation to migrate to other data structures. Sure it is then fast, but it gets less readable and harder to update.
Now, I'm a programmer at heart, so I think in the "functional" paradigm, not the array/signal one. There's some "impedance" I guess :-)
Re: Why We Use Julia, 10 Years Later
#79Earlier quoted context omitted.
R has superb documentation. I miss it with Python.
I don't know what libraries you're refering to. But most of the time, they barely document what they do. By barely I mean: - parameters documentation can be understood only if you actually know the theory behind what the library documents. One may say that it's a good thing in the sense it prevents one to shoot himself in the foot but for discoverability, that's painful. I've done basic stuff such as GLM, LDA, PCA,..…
> Not everybody know the theory behind each PCA's formulation...
It's a language meant for a specific domain. Expecting domain knowledge in said domain is not a failing - it's logical.
Re: Why We Use Julia, 10 Years Later
#80I'm currently writing code with it. The language is really (really) nice to work with. - But the REPL lacks the ability to redefine structs on the go (which I can understand as it'd be tough to do, or simply not possible). But that, combined with the slow start up time makes life a bit harder than it should. Fortunately, one doesn't redefine its structs every day. - There are also lots of libraries but the quality of…
All valid complaints. Regarding the first one, redefining structs, you can wrap them inside modules and reload the module. It's not as ergonomic since you will need to qualify the structs with the module name.