
JuliaCon 2019 Videos - FranzFerdiNaN
https://www.youtube.com/playlist?list=PLP8iPy9hna6StY9tIJIUN3F_co9A0zh0H
======
eigenspace
If anyone is looking for video recommendations to get started: here’s a couple
that I thought were great and should be interesting and approachable to just
about anyone.

Steven G. Johnson’s keynote address. It’s longer format but really
interesting, informative, entertaining and well delivered. The main topic is
metaprogramming. [https://youtu.be/mSgXWpvQEHE](https://youtu.be/mSgXWpvQEHE)

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.
[https://youtu.be/kc9HwsxE1OY](https://youtu.be/kc9HwsxE1OY)

------
ThenAsNow
It would be great if Julia were to take a page from the Rust playbook and have
some focused initiatives around making the language more accessible to its
potential audience. I've been impressed with how introspective and
constructively self-critical the Rust stewardship has been. I don't get the
same sense from Julia, but maybe I'm missing things.

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.

~~~
krastanov
The documentation style (permanent TOC on the right) seems to copy python's
Sphinx style. And you are quite right about the lack of visible effort in
making error messages more useful.

~~~
StefanKarpinski
Until very recently, there have been higher priority issues such as complete
multithreading support. Now that we have that, error messages are now a top
priority (see my other comment). Some work has already been done but not yet
merged:
[https://github.com/JuliaLang/julia/pull/31954](https://github.com/JuliaLang/julia/pull/31954).

~~~
hyper0perator
Thanks for all the great effort and progress. Better error messages would be
awesome, but this composable multi-thread support makes Julia even more
absurdly powerful and versatile! The priority makes complete sense.

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.

------
fc_barnes
I'm glad Julia is continuing to make progress. There's certainly a learning
curve but that's how it goes with these powerful languages. I believe it's
inherently superior to the competition, and as long as the rough spots
continue to get filed down and the community remains engaged and willing to
help newcomers, it will meet with ultimate success.

------
Merrill
Julia: come for the syntax, stay for the speed

[https://www.nature.com/articles/d41586-019-02310-3](https://www.nature.com/articles/d41586-019-02310-3)

~~~
elcomet
I came for the speed, and I left because of the speed. It's impressive how the
interpreter is slow to start..

~~~
ddragon
That's mostly because Julia doesn't have yet an interpreter (outside of the
debugger), only a JIT compiler. Thankfully the "time to first plot" is the new
priority for the compiler team since the multithreading is already working.

~~~
reikonomusha
Most Common Lisp compilers survive well with incremental compilation. Build-
times and development are very fast, with no interpreter in sight.

~~~
6thaccount2
Yea, but common lisp is also missing nearly all the numerical libraries I need
like sparse matrices. Yes, I'm sure someone has a wrapper somewhere, but Julia
has native support for all of that and is really nice. It also has much better
support for a lot of things like plotting.

------
eigenspace
I was unfortunately unable to attend, but I really appreciate how many talks
were recorded for YouTube. Really great to see all the cool stuff people are
working on.

------
xvilka
I hope LibreOffice will consider[1] to support Julia in Calc too, along with
the current Python support.

[1]
[https://bugs.documentfoundation.org/show_bug.cgi?id=125728](https://bugs.documentfoundation.org/show_bug.cgi?id=125728)

------
wtdata
I have been willing to try Julia for a long time now.

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.

~~~
ChrisRackauckas
Use import instead of using if you don't want things in your namespace.

~~~
wtdata
Ah, thank you! That was a very rookie mistake from my part then.

