That’s precisely what I’ve been hoping for with this thread and all its spinoffs! 
4 Likes
Personally, I think all effort should be spent on funding package development. Julia as language is great, it solved the two-language problem. I can write relatively naive high-level code and with little effort it gets fast enough, not too far from C++.
What Julia needs is some killer application(s). For example, @ChrisRackauckas et al. are breeding a differential equations ecosystem that is state-of-the-art. A few other packages are somewhat state-of-the-art or close enough in other areas.
However, Python has so much corporate support that it offers superior libraries on many areas. A glaring example is how far Flux.jl is from JAX or PyTorch. Don’t get me wrong, it is impressive how much Julia has accomplished with so little manpower. The PyTorch team is in the hundreds of engineers! That’s likely much more than all top Julia packages combined.
The answer to this should be getting more grants and donations to continue supporting the growth of areas where Julia can make a true difference, and not to fall behind too much on things like differentiable programming.
13 Likes
Please take what I’m about to say in the spirit of sociological thought, and not confrontational.
There is a tension between what beginners need and what masters need. There’s a reason for the existence of the “AI Koans” Some AI Koans because there’s a similar tension between beginner and master in computing as there is in Zen Buddhism. There’s a tendency among the masters to think that the path should be from beginner towards master, and that one doesn’t alter the language to make it less usable by a master just so it’s more usable by a beginner.
I think this is seen as rude and snarky but it’s not intended that way, it’s more like intended to be helpful but with different assumptions and so, not always helpful.
IMHO if you want an on-ramp for Julia the place to put it is on the julialang.org homepage in documentation specific for on-ramping. This is sorely lacking and is probably the single most important thing for onboarding new Julians.
If there should be messages and information and simplifying things for beginners in the REPL/language they should be invoked as --beginner-mode or similar. I am all for this. It’s possible to replace the REPL, like with OhMyRepl.jl, why not BeginnerRepl.jl or something similar? It would be worth providing a script which would install in the outermost environment all the best “beginner friendly” packages. Like when you download Julia you get the script and if you run it, it sets you up. There should also be a “uninstall mode” for that script.
A lot of users never want to become masters. This can be a source of frustration between the two cultures.
I like to make analogies to mechanical tools… Python or R are like pre-programmed machines that carry out some complicated task for you. A machine that makes say a gear. You can program in the radius and the number of teeth and the material, and then out pops the gear. Fine and good, easy for a beginner. Julia is like a CNC lathe + milling machine. It may come with a bunch of preprogrammed tools to make gears etc, but its inherent value is as a generic user-programmable thing, it also makes turbines, and valves and clamps and baseplates and drills holes and welds things together and etc. That also makes it inherently harder to onboard. You have to know more about how to use it to make use of it simply because it can do more things.
Making it more like Python destroys its value as generic high performance thing. So we can’t do that. But we could have a sort of “mode” where it’s easier to get started for sure.
14 Likes
I think the best step would be to improve documentation and ide tools. I am somewhat surprised at the issues of the vscode extension for Julia.
I often have issues not finding referencing, autocomplete will fail to work and sometimes it doesn’t link to documentation. Can you open documentation in a browser? I have a hard time finding package-level documentation.
I would pay for a version of RStudio that included Julia support, or for a vscode ide plug-in with commercially support
Generally I’m disappointed in the accessibility of package documentation in Julia. I felt like R was better; maybe that comes out of the checks in the cran process. If you look at a simple package in r like log4r, @johnmyleswhite probably wrote more documentation than code, along with a vignette comparing and benchmarking to every other logging package in r. Going into Julia I expected to see more packages written at that level, but I often don’t find the documentation as complete and what you do see in vscode is often too short and not linked. I’m not experienced enough in Julia to offer suggestions on how to improve it, but I feel like there is a disconnect between the developers and users of packages, and r/cran/rstudio have done a better job at bridging that gap.
5 Likes
My experience is very different from yours. When I ask a question here, I get a couple of helpful answers. When I report an issue for a package, most of the time I get it fixed within a short timeframe, or get an explanation if it takes longer or cannot be done. When I make a PR, kind people review it quickly, help me improve it, and are very tolerant if I make silly mistakes (which happens).
30 Likes
It seems logical to go the extra mile to promote Julia when the language features, tools, documentation and ecosystem make a good impression on beginners and experienced users alike. Have we succeeded yet? If not, will we get it soon? If not, is it worth promoting Julia now and blithely forgetting its shortcomings?
My strategy is to use Julia and fix its shortcomings when I encounter them, and let “promotion” take care of itself.
I think that in general, the returns to effort put into promotion are very low compared to development. Good things promote themselves, especially if they are freely available for free like free software. Conversely, to promote something that is inherently inferior usually requires an immense budget, so it usually only makes sense in a for-profit context.
But most importantly, effort put into improving a language like Julia accumulates: each improvement leads to a better language. In contrast, efforts are promotion usually may just give temporary results, as people are constantly bombarded with other promotions efforts.
Nevertheless, if someone really wants to “promote” Julia, I think that their effort is best focused on the latest major improvements of each release. Eg for 1.10, I am very excited about #48600, preliminary testing suggests a significant improvement for some calculations that I run in parallel. As opposed to just talking about how great Julia is in general (it is!), promoting very specific improvements signals that the language is actively developed, and that previous shortcomings are being continuously addressed.
29 Likes
I just came across an article on Hacker News titled “Elixir saves Pinterest $2 million a year in server costs”:
I’m not sure Julia can have that much impact, but articles like this “sell” a programming language.
5 Likes
Some programs have the option of usage tips that show up when the program is started. Perhaps these usage tips would be the right place to show best practices. There could be beginner usage tips, performance usage tips, linear algebra usage tips, etc. One of the tips can be how to set which group of tips you would like to display when you start Julia or how to turn off this option.
1 Like
It is fine for personal use. If you create and deliver products to customers it is different. It is almost always run in the script format. None of my customers program.
The very few non-programmer customers I have that actually want a program (most want PPTX slides, ugh) want one that you double click on, and that has a GUI. I guess with Julia I could make a shell script (or in windows a CMD script) that calls julia -q … but then I’d be at a loss as to what GUI framework I would use.
I got so used to having Tk around in Python … I know Python is a different beast, but is there a “cannonical” GUI toolkit that people use? Because you mentioning non-programmer customers immediately reminded me that I needed to look into this.
I wonder if any Julia Con speakers would like to submit their talk to Hacker News/Slashdot and see what happens.
1 Like
To clarify, I’m not talking about making Julia easier to use (although that’s always great). I’m referring to a group of posters on Slack and Discourse who respond to suggestions for improvement they dislike with some mixture of snark and dismissiveness.
“Unfortunately, implementing feature x would be bad for performance” is a perfectly reasonable response to user criticism or complaints about difficult-to-understand behavior. That’s also especially true if it’s followed up by an attempt to address the argument in a way that doesn’t harm performance, e.g. a more informative error message. But adding snark is always unnecessary and has caused substantial damage to the Julia community’s reputation–I’ve come across quite a few people who have said they stopped using Julia because the responses they got on the Discourse were much less friendly than the ones they got on Python forums.
I don’t think these are contradictory. If you post a question like “How do I use such-and-such package,” the responses tend to be helpful and polite. This is especially true if you ask in the Github issues for a package, where people are consistently a lot nicer. The snark seems to come out when the criticisms would be difficult to fix, or suggest some previous decision might have been a mistake.
When you see rudeness and snarkiness here, please flag it.
9 Likes
One suggestion would be to revisit the documentation section on julialang.org Particularly the wording in section 3 and 4 - I was surprised to see additional documentation discouraged.
As compared to the rust advice for documentation or roxygen which structures it for the developer.
While the community and forums are very helpful to answer questions, it wasn’t clear if they want help to add more documentation after questions are answered or if they want to keep the documentation as short and to the point as possible.
I think it’s only discouraging redundant documentation, i.e. docstrings that repeat exactly the same information twice (simply in different formats)?
2 Likes
Sorry, to clarify that comment. I think it might be surprising to people coming from other languages to see it suggested not to repeat yourself or start with “The function bar …” They might be used to starting with a sentence. For example, in the example in go:
// Quote returns a double-quoted Go string literal representing s.
// The returned string uses Go escape sequences (\t, \n, \xFF, \u0100)
// for control characters and non-printable characters as defined by IsPrint.
func Quote(s string) string {
...
}
It seemed odd to me initially that the first step of writing function documentation is basically to repeat the function definition, which doesn’t seem to give hyperlinks to the types in the documentation. I was expecting to start the documentation with a sentence and have the links be autogenerated.
1 Like
Who are the authors of Julialang documentation? Language developers or professional technical writers?
1 Like
Language developers presumably wrote most of it, but anyone can contribute. Then again, not everyone dares
3 Likes
I have done it multiple times (even rewrote substantial parts of chapters), and it is a remarkably smooth process. In my experience, there are always some people who do give it a detailed reading and provide helpful comments, and small changes are reviewed and merged quickly.
For those unfamiliar with git workflows, small changes can even be done using the Github web interface.
8 Likes