Blog post about my experiences with Julia

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.

1 Like
  • 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?

1 Like

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.
Screenshot from 2022-04-25 20-31-47

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.

1 Like

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.

1 Like


1 Like



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 also
  • apropos("Dict") is not the way to ask for methods with Dict. 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 module includes everything, and all the other modules simply use using. 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.

1 Like

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.