What steps should the Julia community take to bring Julia to the next level of popularity?

Community
464

I think one key lies in the niche of newbie developers:

Python got popular with that. Ruby got popular with that.
I think a lot of JavaScript developers started with JavaScript.

So the question could be more like:
How can we get new developers on board?

Some, who have never programmed before.

“No matter how it looks at first, it’s always a people problem”
Gerald Weinberg

I totally agree with that more.

Within the 5 years I am within programming, it has always turned out to be a people problem.
Most of the time, simply because they don’t care. And one thing they care the least about, is newbies.

And no, not if one posts a question, and they can answer it. People are usually quite competent and helpful then. And this is not, where the heart of the matter lies, in my opinion.

Python got popular due to its friendliness and simplicity, that made it accessible to children, students, and sysadmins :wink:

Also, scientists did struggle with many of the alternatives, and ultimately decided collectively, to settle with Python.

And I would claim the simple nature of the language is only a part of that.
Another thing is, that the community is wholeheartedly committed to that concept.

Publications, inclusivity, and a general sentiment of empathy and preemptive guidance, lies at the heart of Python’s success. We are talking a lot about inclusivity, and forget largely about people, that happen to be new to programming.

My reasoning: I am a functional programmer since day 1.

Due to me liking to code in a declarative style - which I knew due to me being a KDE and Qt nerd previously, and they are using the declarative QML - I already knew at day 1, that I wanted to be a functional programmer. Before I knew anything else about programming.

I think the casual programming community has generally bad onboarding for newbies.
The functional community has simply no such onboarding.

And why I think that this is an issue: It’s simply far easier to convince someone, who has never programmed before, rather than someone who is committed to a code base, tooling, and a general sentiment.

I would argue, to come up with random and highly unscientific numbers, that 10 people without programming background can be convinced to give Julia a chance, with the same time and effort that we put in, to convince a single existing Java, Python or C++ developer.

3 Likes
465

That’s not true. It always compiles function only the first time it is run in a session, and package code is compiled on installation (in a precompilation stage) if the package is setup with PrecompileTools. These two facts together, while not perfect, cause a few orders of magnitude difference in the amount of compilation that is done for novice users in comparison to “EVERYTIME”

14 Likes
466

I think a lot of novice users run their Julia code by typing julia my_script.jl from the shell, since that’s how almost every other scripting language works.
The “trick” of avoiding recompilation by keeping a session open and using Revise.jl is not mentioned in the introduction part of the manual, nor in the “performance tips” section, so there is probably a risk of people giving up on Julia for being “too slow” before they learn about this.

13 Likes
467

I think it would be worthwhile to detect the first time Julia is run as a script runner and print a warning that that is not an optimal way of running code and suggest link to the documentation.

1 Like
468

it’s a perfectly fine approach for many uses

I think adding such a warning would do more harm than good

3 Likes
469

so what about storing cached compiled code and keep it accessible by path:source:function(type1, type2, …)::Type3 form after a first compilation? If file is changed then a compilation is required. If the file is not changed, then the pre-compiled one is already usable. A julia --clean-cache can be used for cleaning out the cache (in a way like Makefile works).

Note: Saving type information is not necessary, the key point here is to detect the file is either changed or not.

1 Like
470

Such as? And why would it do any harm at all?

471

What do you mean such as? such as many many many workloads that require no interactivity or editing

it would do harm because it warns against a very common and useful workflow; users often don’t like to do things that the languages admonishes them against

1 Like
472

I have found only a single case where I run Julia as a script runner: when it computes on a long-run-time computation on a remote machine.

For anything else I use an interactive session. I don’t see any reason whatsoever to run those sorts of jobs as julia script.jl.

The point is that indeed I have a firsthand experience with new users who tried to do this, knowing that this would work with python, and were seriously disappointed, to the point of chucking julia.
People who know what they are doing would simply ignore this warning; all others would benefit. I don’t see any downside.

7 Likes
473

People who know what they are doing would simply ignore this warning

I believe you that students and new users require more interactivity when getting started with Julia.

in like 99% of cases where Julia would be used in a “production” job it would be run as a script

I do not want to see a useless warning in my logs, nor do I want to keep a REPL running for months at a time with a custom timer rather than just setting a cron

fundamentally there is nothing wrong, incorrect, or even suboptimal about this usage pattern. any admonition would be much better phrased as a “development workflow suggestion” somewhere in the docs rather than a runtime warning

11 Likes
474

Wouldn’t it be better if the Julia extension for VS Code helped beginners with tips like that as the Java extension does?

getting-started
getting-started1024×768 24 KB

Hopefully the Julia extension for VS Code will find new ways to help beginners. Would JuliaSyntax help the extension to show inlay hints?

7 Likes
475

I do not see what harm can that be. Provided it is shown, as explicitly suggested, only once (per specific Julia version on a specific computer)

2 Likes
476

so, presumably, per docker container as well? or per AWS instance spun up to run the job?

running julia my_workload.jl is not unconditionally incorrect or suboptimal, at all. It is conditionally suboptimal depending on what it is being used for. This kind of thing deserves documentation but not a warning

5 Likes
477

That sounds like an issue in the documentation. Do you know, if or if not that is already assigned to someone? Or that we have at least an issue open?

I do see this as something to be mentioned in the “performance tips” section.
And then a clear, dedicated part in the introduction, that explicitly tells about how Julia is meant to run.

Thanks :slight_smile:

2 Likes
478

Have you seen many newbies who start by reading the docs?

7 Likes
479

In the Julia REPL, the only thing I can tolerate seeing initially is the juliaup message saying that a new version is ready.

4 Likes
480

Do we have a bullet point of ideas/concerns shared in this thread?

3 Likes
481

It would be nice to have such a thing in VS Code, but that’s not the best place. Just linking to the documentation is not ideal either, at least as of right now, as this page is fairly incomplete and unclear (see previous discussions about module usage in Julia). What I think is needed for beginners is something like this on the front page:

image
image1346×230 151 KB

The information in there should be presented as a how-to, a step-by-step guide, instead of prose or a laundry list of items like in Performance Tips. For example, one page in there could be for a beginner on a Windows computer setting up his workflow for the first time:

Step-by-step tutorial on setting up a recommended workflow (Windows users)

It is possible to run a Julia script as julia script.jl in the command line, as familiar from other languages, but you will have to pay the cost of compilation every time this line is run. Moreover, it can be a hassle updating Julia by directly downloading binaries from the site every time a new version is released. For many, these two things are annoying and slow, but there are ways to bypass this as much as possible. Following the steps below will help improve your workflow while writing Julia code.

  1. Install juliaup in the Windows store. (Link directly to it, not the Github page)
  2. Open PowerShell and type juliaup add 1.9 to install the latest 1.9 version. You can then type juliaup status to confirm which version you have installed.
    • In the start menu, click on Julia to open the REPL. You can pin this to the taskbar and use it as a calculator, if you like.
  3. Type juliaup update to update to the latest version when new releases come out.
  4. If you want to use an editor, VSCode with the Julia language plugin is the most mature – install them both if you don’t already have them. If you are interested in notebooks, Jupyter or Pluto are the two main options. (Links to a comparison between Jupyter and Pluto, other editors) Below, we assume you’re using VSCode.
  5. If you are using juliaup, VSCode will automatically find the Julia installation for you – skip to step 6. Otherwise, if you installed the binaries directly from this site, do the following:
    • In VSCode, enter Ctrl+, to open up the settings.
    • In the top bar, type julia.executable. You’ll need to paste the filepath to the executable from there. If you used default installation settings, it should look something like this: C:/users/username/AppData/Local/Programs/Julia-1.9.2/bin/julia.exe
    • If you update Julia directly by downloading binaries directly from this site, you will need to change this filepath every time you update in order for VSCode to point to the latest installation.
  6. Type Alt+J+O to open the REPL in VSCode. (J+O stands for “Julia open.”) Besides being able to run Julia code, the REPL has a built-in package manager (type ]), a help mode (type ?), and a shell mode (type ;).
  7. Arguably the most important package to help with workflow is Revise.jl. Install it by typing ] to enter Pkg mode, and then type add Revise. This package will automatically update function definitions in a running Julia session. Since Julia has a relatively long startup time, for maximum convenience, we recommend keeping the current REPL session open for as long as possible.
    • Unlike most packages, VSCode is set up to run Revise.jl upon starting up Julia. That way, you don’t need to type in using Revise at the top of your script, or every time you open the REPL.
  8. To run code, you have a few choices. To illustrate, create a new file called test.jl with the example code to print out powers of 2:
a = 1:10     # defines a vector of the first 10 natural numbers
b = 2 .^ a   # defines a vector that takes the first 10 powers of 2. The dot indicates element-wise operation.

[a b]   # defines a matrix whose columns are a and b

There are three choices you have to run this code:

  • With the cursor on the window with the code, hit Ctrl+A+Enter to select all and execute the highlighted code to the REPL.
  • Press the play button near the top of the screen to execute the active file in the REPL.
  • Type include(“./test.jl”) into the REPL.

Notice that in all of these, the last line is returned.

  1. Where does Revise come in? By default, the includet function that Revise exports will track changes to function definitions, not data. Since we didn’t define any functions, typing includet(“./test.jl”) won’t reflect changes if, say, we wanted a to go from 1 to 20. It is good practice to write our code in functions, especially for more complex code, so let’s define a function called main:
function main()
	a = 1:10
	b = 2 .^ a
	return [a b]
end

main()

  1. You can check that Ctrl+A+Enter works as usual. (If the main() at the end were not there, you would only be defining a function called main, but not actually running it. To run it, type main() in the REPL.)

    • Now to check that Revise works, type includet(“./test.jl”). This will include the file and track any changes to main() as long as the REPL is running. Notice that nothing will be printed. That’s fine – in the REPL, type main() to display the result.
    • Change the second line to a = 1:20. Save the file.
    • Type main() again in the REPL. Revise detects that main() has changed, and the function now prints out the first 20 powers of 2.

That’s pretty much it. We’ve set up juliaup so that Julia can be updated to the latest version with one line in Powershell, and we’ve set up Revise so that function changes are automatically updated in a running Julia session. There are many other things available to streamline the workflow, including…(links elsewhere, OhMyREPL and startup.jl, etc etc…)

(Ideally this would be accompanied by a short video which I’d be happy to make if something like this gets implemented. There would be separate pages for Mac and Linux, of course.)

In this manner the beginner has a setup that gets him in the ballpark of what is considered a good workflow in Julia and is not overwhelmed by so much information on this topic that he ends up asking “why is it so hard/convoluted/painful to just get something set up in Julia.” Such information is not scattered across blog posts or Discourse/Slack comments, but in one place, on the official site. Moreover, it is not enough to have the necessary and relevant information in one place - the way it is presented is important. The more hand-holding the better.

9 Likes
482

Sure!

Issuing the warning only once must involve setting some flag somewhere in the settings to suppress it afterwards. Then there must be a way to configure settings manually to suppress the warning, which must be documented if the suggestion is accepted.

2 Likes
483

I intended that to imply that would be highly undesirable behavior, my apologies for the sarcasm