4 ms·

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 potent

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 7y ago
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 7y ago
  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 7y ago
    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.
ChrisRackauckas 7y ago
I agree. More focus on differential equations! :)
StefanKarpinski 7y ago
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 https://github.com/JuliaLang/julia/pull/31954 [2] can't find the PR now but part of a GSoC project

krastanov 7y ago

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 7y ago
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 7y ago
  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.

ChrisRackauckas 7y ago

I agree. More focus on differential equations! :)

StefanKarpinski 7y ago

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 https://github.com/JuliaLang/julia/pull/31954 [2] can't find the PR now but part of a GSoC project