I am the only one that found the choice of dark blue for the links over a black background the greatest problem of the blog post? It is basically illegible, I had to select the text to be able to read it.
- Updates sometimes deinstalled some Julia packages. This is bad if you run
pacman -Syu
, then hop on the train only to find that you cannot work on your code, because you cannot reinstall the packages without internet connection.
Iâm donât understand this point. First of all I donât understand how pacman
is related with Julia packages at all. Then, updating julias package can remove other packages no longer required in the environment, so why is that a problem? Also, packages are actually not removed from disk unless you run Pkg.gc()
, so you can still add them to your environment without having to redownload them. BTW, do you know the package manager has on offline mode which you can enable by either setting the environment variable JULIA_PKG_OFFLINE=true
or running Pkg.offline()
.
The only possible problem I can see is that Pkg.gc
is now run automatically every 7 days, but you can disable that by setting Pkg._auto_gc_enabled[] = false
in your startup file. Am I missing anything else?
Letâs say you want to know the methods to modify a Dict. In e.g. rust you can find those methods in the documentation of the Dict datatype. But if you execute apropos(âDictâ) in Julia you find both functions like Base.mergewith, but also stuff like Base.setenv or Base.Cmd.
This is a really good point. I would like a way to connect Dict
to mergewith
but not to setenv
. I canât think of an objective criterion that distinguishes them so it might have to be manual opt in. Can anyone think of a good way to do this?
Edit: Moved to another thread
- If you fail - fail loudly. Julia routinely ignores this guideline.
What does this refer to?
Is that how it looks like on your machine? Seems bright enough for me. That being said, I never thought about link color in the dark theme.
All languages have a way to split code among multiple files. In Julia there seems to be no good way.
Files are not a semantic unit in julia, so I think of everything in a module as being one big file. Some people like this, others donât and use FromFile.jl. I havenât found it to be much of an impediment, but I think it would get a lot less complaints if Julia had better static analysis (jump-to-definition).
Contrast is considered an accessibility issue, there are guidelines and automatic site checkers to help publishers choose colors with readable contrast.
I have trouble remembering what exactly happened.
Should have written this post half a year ago.
But anyways, thanks for pointing the Pkg.offline
option out.
Yes, it is how it looks like. I use my notebook with moderate brightness because high brightness tire my eye very fast (and I spend a lot of time in front of it), and I often prefer black backgrounds (I always chose the dark themes when possible) but I never had a reading problem like with this tone of blue for the links.
fixed
Out of curiosity: is that meant to be your âgoodbyeâ to Julia?
Edit: or in other words: did you have at least some fun with it as I sometimes have?
Moved to Declare functions of type
A bunch of smaller things, I donât remember everything. One thing being that @includeonce does raise a second error if a bad file is included twice. Another thing is that dynamic typing (without lots of type assertions) is kind of a violation of this guideline. Another thing is this
Fun: Not really, Rust owns my heart.
But I might use it again If I find myself in a situation where Julia is useful.
That being said, I am currently leaving the beautiful world of Physics behind and am trying to find a job as a programmer outside of Physics. So I donât know if I will find myself in a situation where Julia is useful, as its primarily science focussed.
This is a pretty good blog post. In my opinion, you hit on some sore points in Julia. You also mention some problems that are easily solvable, though.
Real problems
- We donât have good autogenerated docs, like
cargo doc
. It should be possible to create a program that reads Julia code, lists exported functions and types, which functions operate on types, etc, and links them together and create a HTML file. That would be a really nice addition to Julia. - Error messages could be better in Julia
- TTFP is really bad, nearly everyone agrees
- I wish it was possible to redefine structs using
Revise
. It can be a real pain if you work with something stateful to have to recover the state after a forced restart - I would also agree tooling could be better. Itâs a bit hard to debate because itâs such a broad statement. But I often run into bugs in:
-
Base
âs code introspection functions like@code_native
- JET.jl
- Julia extension for VSCode
-
Things that are not so bad
- Having
typeof(x)
give the whole type with tonnes of type parameters is not a problem, IMO. You can always just ask for the base type. See alsohttps://github.com/JuliaLang/julia/issues/35543
-
apropos("Dict")
is not the way to ask for methods withDict
. The right way isâŚmethodwith
. - You can redefine functions using
Revise
- âIf you fail - fail loudly. Julia routinely ignores this guideline.â - Iâm not sure what that means. Julia is pretty strict, usually, I think.
-
.=
behaving differently than=
is not a bug or a misfeature IMO. I donât think itâs confusing that changing all the elements in-place of a vector changes the content outside the scope where you did it. Python works the same way (with+
vs+=
). - I donât understand the problems you mention with modules. You can just include it once in the top module, then have
using
, right? That is, the top moduleinclude
s everything, and all the other modules simply useusing
. That works. - If your OSâs package manager uninstalls Julia, then yeah, it might also remove packages. That seems like fine behaviour to me - and also, itâs the package manager, not Julia
I think youâre hitting on a real problem but I disagree with the diagnosis as a âsilent failuresâ problem.
That looks like a loud failure with an unhelpful error message. As you rightly pointed out in another bullet-point above, this is a common problem in Julia.
Likewise there is a problem here, but I donât think dynamic typing is a silent-failure problem per se, but rather a late failure problem. That is, I want to know early rather than late that my code is broken, and Julia doesnât really offer tools to avoid that (even JET) as of 2022.
Thanks. While small I think this will make your message reach more people. If I was really interested in what you had to say I would surely have abandoned the text when I started struggling to read it.
From where this comes from? Is it Base
Julia?
This is kinda of a good point but moot. The way Julia is designed asks for you to be as lax as possible with type restrictions in function signatures, what does go against the âfail as soon as possibleâ school of thought. It is not a problem without workarounds, but these workarounds must be explicitly written instead of just using the type system to do the job. All in all, it is the trade-off that any dynamic language makes at some level.
When I wrote âfail loudlyâ, I meant âfail loudly and fail earlyâ. I updated my article.
Nice, so you are that kind of guy (as I am or was?). Try some dependent type programming and you might come back to Julia someday to have some fun, as I did.