Steven G. Johnson’s keynote address. It’s longer format but really interesting, informative, entertaining and well delivered. The main topic is metaprogramming.
Stefan Karpinski’s talk on the unreasonable effectiveness of multiple dispatch. He discusses the fact that Julia has such dramatic code re-use and sharing between libraries and he discusses some reasons why he thinks multiple dispatch is uniquely able to offer this.
The "time to first plot" issue bothers me far less than the weak documentation and low-friendliness error messages. I'm not sure where this documentation style comes from that the official Julia docs use, where the left side of the page is permanently taken up with a low information density TOC and the detailed discussion in any real content section is either terse or somewhat superficial, but that imbalance is very frustrating. Try for example to find where in the Multi-Dimensional Array section the eachrow() iterator is introduced. There doesn't seem to be an attempt to develop something equivalent to the Klabnik & Nichols Rust book.
There are some awesome packages in the Julia ecosystem, but the "slap something onto GitHub in one night" style of documentation definitely hurts.
Making error messages more approachable will also help driving toward Julia as the technical computing lingua franca for engineering students.
There's already work in progress to improve Documenter.jl (the package that generates Julia docs) to change the TOC style to something less annoyingly detailed and different from Sphinx . Julia's own manual has grown incrementally, written by various people and definitely needs a once-over by someone who is good at clear technical writing; it's hard to find the time when there's so much other work to be done.
 can't find the PR now but part of a GSoC project
The Julia team and community are constantly advancing the frontiers of language design while grounding it in real number crunching applications. I wouldn't be too concerned about trying to have the same documentation and content approach as the Rust community as their goals were to usurp the mindshare of systems programmers (C/C++) with a novel ownership paradigm.
Looking forward to the progress on error messages.
The one that people would probably appreciate the most would be an AoT alternative (allowing you to create a runnable/linkable binary with a function/module without embedding the compiler, at the cost of the dynamic features such as eval).
Yesterday I finally put time aside to port some stuff I have been doing in Python to Julia.
1st: install Julia - used a snap on Ubuntu, fine
2nd: get jupyter to work with Julia: a bit complex, but achievable
3rd: install Julia support for vscode: Julia kernel keeps crashing in vscode
4th: Port a routine from Python to Julia: some nice language features, some scary: importing a package exposes all its functions to the all namespace - this seems quite awful! (EDIT: Thank you for pointing out that I should use `import` instead of `use`, in order not to put everything in the same namespace).
5th: Try to read a Parquet file - doesn't work because it was compressed with zstd (something all 3 libraries for parquet in Python support)
6th: realize that there is no package in Julia that even allows to write parquet files
Conclusion: maybe in a few years Julia will be my go-to language, but right now, it's too underdeveloped in order to be able to do real work with it.
When doing `using SomePackage` it only imports the names that are explicitly exported by `SomePackage`. Even collisions don't cause problems very often because exported type names tend to be fairly unique and when two packages use the same name for a function, there's a strong chance it's actually the same generic function shared between the packages so there's no collision. When that's not the case and the name is fairly generic, e.g. `connect`, then it's quite common to use the API as `SomePackage.connect` rather than as just `connect`. This is quite a bit different from class-based object-oriented languages, so it takes a little while to get used to.
The issues with Parquet files are likely to get sorted out in the near future (a few months), so try again soon.