I think this is another very big problem to getting new users to adopt Julia–the difficulty in recognizing the importance of defaults and informational constraints. Among experienced Julia devs, the assumption is defaults don’t matter, so we don’t have to change them.
However, just because a change is easy for experienced users doesn’t mean it’s easy for new users, who often don’t even know a feature exists. What percentage of Julia users do you think know about julia --project? My guess is less than 5%. (I didn’t know about it until today, and I’ve written a couple of packages!)
Other examples of poor defaults that are easy to miss when you’re learning Julia:
- FMA (not default because it could confuse devs if someone ran a computation on a pre-2008 computer)
- The inability to use positional arguments with keywords (because then, developers wouldn’t be able to change the names of positional arguments without breaking user code)
- Defaulting to single-threading instead of threads=n_cores (held up by complaints this would be a bad default for large-scale computing)
- Extremely long stacktraces filled with nested type declarations (implementation held up by complaints that it could result in users not posting the full stacktrace in Github issues)
- Performance footguns like type instabilities and eager functional primitives (maybe 80% of the mistakes I find in PRs by newer users)
- No compile-time errors when static analysis catches likely mistakes, like method ambiguities.
In theory, Julia is supposed to be just as easy to pick up as Python, like it promises in its advertising. In practice, all these details are just too easy to miss. Just because it’s easy after you learn how to use it, doesn’t mean it’s easy to learn how to use it. Right now, these kinds of defaults mean it takes me a lot longer to teach a new user to learn Julia than it does to teach them Python.