JuliaCon 2019 Videos | Hacker News Reader

JuliaCon 2019 Videos

youtube.com

144 pointsFranzFerdiNaN25 comments

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

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

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.

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.

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.

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.

I agree. More focus on differential equations! :)

Thank you, this is great constructive feedback. Now that fully working composable multithreading has been merged to master (that was the top compiler team priority previously), the next two priorities are "time to first plot" and friendlier error messages. The specific plan for better error messages is to use the Julia-native CSTParser ("concrete syntax tree parser") to give Clang/Rust-style diagnostics telling you exactly where in an expression an error happened [1].

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 [2]. 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.

[1] https://github.com/JuliaLang/julia/pull/31954

[2] can't find the PR now but part of a GSoC project

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.

Julia: come for the syntax, stay for the speed

https://www.nature.com/articles/d41586-019-02310-3

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

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.

I hope it goes well, this has been a common complaint for half a decade now.

This is a rather unfair statement given that the first stable version of Julia was released only a year ago.

There has been a lot of other work over the last five years with a constant stream of new people talking about iteration and start up times with constant promises that it will be fixed soon.

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

There are many approaches they could go, they could improve the live session approach (for example saving between sessions), which could also help people who repeatedly run scripts on the bash (for example with a --save-session flag). It wouldn't solve the very first plot but it would help all "first plot within the current run", which is probably most of the complaints.

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).

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.

That's nice, thanks for the information !

To me it looks quite fast, specially when compared having to build native libraries to plug into Python.

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.

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

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.

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

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

As Chris said, `using` is mostly for interactive usage where having to import each name you use is annoying. If you want to import specific names, do `import SomePackage: name1, name2`.

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.

Reply on news.ycombinator.com