@adamslc , I am curious. Did your advisor transition to Julia at the end? In either case what was the reasons (pro/cons)?
1 Like
Thanks. Its really beyond me, looking through the Apache parquet codebase. Maybe you could help out here? Its the Julia community that really makes the language shine.
1 Like
I already maintain like 40 packages, and don’t use Parquet, so probably thats a no 
It was all beyond me at some stage too.
(Julia packages are surprisingly easy to start or contribute to, and should be much cleaner than the apache codebase in other languages)
20 Likes
Today is your lucky day: [ANN] New tools for fixing performance problems in Julia. It still may not be easy, but hopefully it’s a lot easier!
13 Likes
Yes, me too…
If you never want your code to break, pin the versions. If you like new features, API improvements, and better internals, things break some times. I view that as an advantage, not a problem - new breaking versions often bring awesome features, and fix stuff that seems inconsistent and ankward. It makes me sad whenever a package luggs around some clearly bad/wrong way to do/define something for too long to avoid tagging a breaking release.
I just wanted to express this view, as I feel that the “this update broke my code and that is bad” view is overrepresented on forums like this.
12 Likes
He retired! So inconclusive I guess?
1 Like
Maybe we dont communicate enough on the pinning possibilities. Maybe the most read tutorials could show-case this possibility, so that more people know how to do it properly (commit manifest file, pin versions when updating other packages, etc).
For a personal return of experience, the first serious project I did in Julia, learning the language, I did not take care of that. I knew from the tutorials that the packages management tools were capable of increased stability, but i did not make the appropriate operations. Thus, a few months later, I broke something by installing another package or just updating something (I think I updated Julia itself from 1.5.x to 1.6.x). I did not know how to restore what I had before and ended up loosing previously saved runs (serialization was updated and not backward-compatible if I recall correctly). Nothing really important, just a lot of cluster runtime.
3 Likes
What are the odds of adding mandatory declaring of variables before use to the Julia syntax in v2.0? 
Or is there a way to find a typo in a variable- or field name in any other way than having 100% code coverage in the tests?
Use JET.jl.
5 Likes
After trying out JET.jl thoroughly in a larger project, I find that it doesn’t really help much. I still find a lot of “not found” errors only by covering the specific code (i.e., JET.jl missed them) that in C/C++ would have lighted up while I type… 
3 Likes
Hmm, maybe you can try CodeSpell for VSCode (I think that’s what it’s called) or some other spell checker? I think @Lilith just added one to Julia’s CI.
-
distributing stand-alone applications.
-
a culture of terrible documentation. The recent randn() discussion was a good example.
What discussion? Any link ?
2 Likes
They’re probably referring to this one:
1 Like
Perhaps How do we Julians win big when the situation is so unfair? - #63 by sylvaticus, given that this was about documenting randn