1.0 annoyances and Matlab comparison

We probably need a better web server to search packages in both browser and terminal. But currently you can use Julia.jl and juliaobserver to find what you need. Besides, algorithms are developing, one cannot ensure a package is always the best choice.

As far as I know, making them to Base will cause slow start time and nobody wants to waste their time on things they don’t need. Only those who rely on language syntax, like types, arrays, etc. should be included as default. MATLAB is a product, not a language, therefore, they will allow you to install everything by default, and in fact, Julia has something similar: JuliaPro. Besides, you could probably find that a full-installed MATLAB has quite slow start time.

Besides MATLAB and Fortran, I believe Julia has learnt a lot from Python, another popular language in scientific programming. There is also no LinearAlg in Python’s stdlib, which is a nice feature. You should choose what you need and save some start time, which could be annoying when you try to run something frequently (like tests).


Also I have missed MATLAB’s automatic loading of non-default features when starting with Julia, where rather an explicit “using” of modules is required. Of course, Julia is here following many other languages, and MATLAB is more the exception.

How about adding an automatic loading/“using” of modules as a feature? For example

shat = FFTW.fft(s)

would be equivalent to

using FFTW
shat = FFTW.fft(s)

(only the first time when an FFTW function is used)?

You can already do that. In version 0.6 you can add that to the .juliarc.jl file. And, as I understand it, in version 0.7-> the file will be called startup.jl, just like Matlab’s startup.m file.

Yes, but it is not quite what I mean:

In MATLAB my pathdef.m includes for example '/home/stephan/code/matlab/stuff:', and under this folder I put my own programs as well as stuff that others have written and kindly share (and MATLAB adds many more folders to the pathdef for its own “Base” plus toolboxes). Functions that I add under .../stuff will so be found and get automatically loaded when called, I don’t need to touch the pathdef.m any more.

In Julia I write my own modules and add packages, but need to add explicitely

using …

whereever I need to use them (and modules needed really a lot I can add to .juliarc.jl). Not a big deal, but Julia could be a bit more friendly, if

… Modx.funcy(…)

would effectively try to load Modx automatically, if not already loaded.

I vaguely remember there used to be an Autoload.jl package, that was perhaps providing something like this. It might well be that my suggestion is difficult to implement, colliding with Julia’s metaprogramming or other features that MATLAB does not have,

If all your performance-critical code only involves linear algebra and similar vectorized operations on large arrays, then the language performance is mostly[*] irrelevant to you — all that matters is which BLAS library etcetera you link.

The cases where your own code’s performance matters are those where you have to write your own “inner loop” code. This, therefore, is the only situation worth benchmarking when comparing languages for performance.

(And if you do enough scientific/technical computing, you will eventually run into a case where someone hasn’t written the critical code for you already. In Matlab or Python, this means dropping down to a lower-level language via mex, Cython, etc.)

[*] Caveat: Even if your problem vectorizes well, writing your own specialized code can still sometimes be faster than composing many generic vectorized operations. More Dots: Syntactic Loop Fusion in Julia


I am normally a Matlab user, and I don’t really see a functional difference between adding paths in startup.m vs directly editing the path. Actually, I think adding all those paths inside startup.m is more convenient.

In other words, I don’t think there is any missing functionality in Julia in that regard. If, in Matlab, you want to use some code, you somehow need to load it, by adding it to the path, and you can equally well achieve that in an automatic way by editing .juliarc.jl/startup.jl.

This doesn’t work in Matlab either. Either Modx is in the path, or it isn’t.

Maybe at install time pop up a dialogue asking which packages you want “installed” and create startup.jl will avoid some complaints?


What if there were a simple function that added a package to juliarc automatically?

It seems it’d be relatively easy to create a function such as Pkg.onstartup(“LinearAlgebra”) that would append the appropriate “using LinearAlgebra” to the juliarc file. This could make it easier for newer users to always have the packages they want without having to dig into the startup file. More advanced users could of course always customize rc as needed.

Another alternative would be a function such as edit_startup() that would simply open the startup/juliarc file for editing, preventing a new user from having to go and find it. It can be tricky to find sometimes.


Hmm, ok, I guess that what you mean is, whenever a folder is in the path, you can just dump m-files in it, and they will be available. They are sort of automatically included.

In MATLAB, if I write newfunc.m and put this file in a folder that is already in the path, then it will be found, no need to fiddle with startup.m or pathdef.m. newfunc(...) will be available automatically throughout my MATLAB code.

In Julia there are two options:

  1. I edit an an already existing and used file Modx.jl and add newfunc(...) there. Yes, then Modx.newfunc(...) becomes available automatically (via Require.jl). The disadvantage is, that the Modx.jl becomes with time large and difficult to edit with relatively unrelated code for different functions.

  2. I start with a new file for the new function (having this habit from MATLAB) and create Newm.jl:

module Newm
function newfunc(…)


Now, to have Newm.newfunc(...) available in the rest of my Julia code, I need to add

using Newm

either in .juliarc.jl which would then with time load a lot of modules, or add this in all the different files where it is needed.

shell> subl ~/.julia/config/startup.jl


shell> subl ~/.julia/config/startup.jl
/bin/bash: subl: command not found

:troll: :troll:

More seriously, providing a command which works everywhere (including across platforms) is very helpful for tutorials and documentation.


This is what makes installing “packages” in MATLAB terrifying.


FWIW I much prefer requiring using Package as it makes intention explicit, and it is hardly a big burden. Of all the possible issues with Julia (which are quickly diminishing), I really struggle to understand how this one is so important?!


This could be solved easily with yet another package IMHO, ie. KitchenSink.jl, here you import and Reexport.jl the packages you need, then in you other packages and in your .juliarc.jl/startup.jl you just install KitchenSink and do using KitchenSink (here you could take care of versions compatibility, making sure there are no name collisions and define some aliases, etc.)

I have one setup for my .juliarc.jl that is a package I’ve used as an example for teaching, how to take care of your .juliarc.jl file, also creating and managing a package at the same: JuliaRC.jl, though I haven’t used Reexport yet in that one.

These are my very important aliases: :stuck_out_tongue:

[@eval $🔣() = run($🔡) for (🔣, 🔡) ∈ (:🐍 => `python`, :🐙 => `hy`, :λ => `clojure`, :💎 => `irb`, :💻 => `cling`, :🎮 => `nethack`)]

People are probably referring to working on the REPL, where it is indeed annoying having to type using MyPackage.

I don’t think anyone is complaining about doing this in modules (where startup.jl won’t help).

1 Like

This suggestion has got to be one of the best suggestions of 2018!

Pkg.onstartup("LinearAlgebra") FTW!


I dare say that LinearAlgebra is probably the one thing that absolutely everybody will agree should be included on startup, always. It just seems somehow “sacred”.

1 Like

Isn’t it just some special matrix types? Most linear algebra is in Base still?

1 Like

Nope - it’s the very first thing that I want to get rid of.
For general-purpose computing, or having small scripts, having all of that overhead is the last thing I want.