What a strict mode in julia would look like?

Hello everyone,

I came across this video: Newcomers experiences: Why do we need a stricter Julia mode🧐 | Alberto Vieyra Salas, and I think this topic deserves further discussion.

What would a strict mode in Julia look like? Would it apply at the parsing stage (e.g., as a VS Code extension or a REPL flag) or during compilation (e.g., by toggling type inference warnings with a flag)?

I’d love to discuss this—why it hasn’t been implemented yet, the challenges involved, and whether or not it would be desirable, depending on different perspectives.

I know that AllocCheck, Aqua, and their counterparts are available and greatly help in development. However, for newcomers—such as Fortran, C++, or Rust users—who are already familiar with strict typing and just need a bit of guidance to avoid common pitfalls, having a stricter mode could be useful. It could help prevent mistakes and mitigate the frustration that might arise when porting a large codebase to Julia.
Also, we would need to choose between warning-strict and error-strict, this is quite different.

6 Likes

It’s in the works being discussed, but perhaps still mostly on the idea stage: Add `strict` mechanism for opting into stricter subsets of the language Ā· Issue #54903 Ā· JuliaLang/julia Ā· GitHub

4 Likes

See also the previous discussion here: New features targeting the strict subset of Julia.

I’m not sure that anyone is actively working on it; it’s hard to say what it’d look like as it’s still a hypothetical feature.

5 Likes

I’ve readen a little and this seems to be error-strict and on parsing (macro based) It does not seem like they discuss why this and not warning or why not compiler based. I’m also not sure someone should change the code to check if he is doing bad things, a repl/parser mode seems to be a lot friendlyer.

There’s not much discussion about implementation because it’s still very hypothetical. That said, restricting code to a subset of a language would most naturally be done at the parsing stage. For example, you can immediately tell when structs have implicit Any fields when the expression is parsed; doing it later is possible but it’d take more work, and there’s no reason the compiler has to be the one to do it.

It might help in some small ways but I doubt it can make porting code significantly easier. A one-to-one bijection of syntax and semantics is easy, and that sort of coordination isn’t typical between languages. Restricting to a subset might actually make things worse by sabotaging reimplementation patterns.

If parsing is sufficient to enforce the subset restriction, then using it is reasonable.
However, this doesn’t mean that one should use macros just to prevent mistakes there are already plenty of packages available for such checks.
I didn’t claim that restricting to a subset would make porting easier; in fact, it might make it harder.
However, it would almost certainly reduce disappointment in terms of runtime performance afterwards.
Also, if it’s only clear warning based and easy to toggle it won’t change there code just to check.

Looks to me like most people in the github thread would prefer if this is configured in Project.toml or Preferences.toml, not using a macro

yes or just a repl flag actually running julia with --typestable (will error or warn if something is not type stable), --static (will error if something allocates beside compilation) and --strict (type stable + all other things discussed in the strict subset) depending on what the user wants

I think global command-line switches would lead to poor adoption because they would likely restrict you from calling the majority of existing packages, including Base and the standard library. Certainly for the strict mode discussed in the github issue, the idea is that it will be configured per package, not globally for the Julia session. Also it’s focused on syntax, not on behaviors and performance aspects of the resulting program, such as type stability and allocation—check out DispatchDoctor.jl and AllocCheck.jl for that. (Though, of course, the two are often related because many syntax footguns make the compiler’s life harder.)

2 Likes

Oh ok, I guess DispatchDoctor set_preferences!("MyPackage", "dispatch_doctor_mode" => "error") or set_preferences!("MyPackage", "dispatch_doctor_mode" => "warn") is the way to go for now, having this in repl would help a lot I think, I agree with you about Base and tons of other packages that may not work with it enable and I don’t see a solution for that beside considering non-local function to be type safe by default even though it’s false.