Note there’s talk of:
The “strict mode” would disallow some Julia syntax, and if it were not done with a strict mode it would require 2.0, but with actually can be done in 1.x. So what exactly do you want deleted/disallowed from Julia’s syntax or semantics? Or changed (is same as deleted and addition). Anything to be added can be done already in packages and/or in Julia (and a lot has already be done like two OOP systems and pattern matching systems), more or less; even syntax is handled in a (stdlib) package, and it CAN be added to at runtime… At least the new parser was changed at runtime, when it was in development, it’s now the default (the point was always compatibility, not adding syntax, but could have done it). I can only see changes to the default GC a bit difficult, and there are already alternatives.
I’m not sure what you mean with “permanently fixing type piracy”, I think like accessing/calling non-public, type piracy can be powerful, but if either disallowed, then a lot would break(?). We might need some gradual migration, allow-by-default, then later change the default or the user could until then?
Invalidations and recompilations are certainly annoying, but only a runtime/startup-speed issue, not a show stopper? And packages can be improved to avoid it(?).
Do you want to change Julia to a fundamentally different (static) language? I believe static analysis tools go a long way to fix your problems.
FYI: Julia has actually already been forked, into a static language variant (with one new keyword if I recall):
It might be mostly (or only?) for robotics. And I think, it’s proprietary, at least its runtime Romeo, but I might be wrong on both counts, where do I find it?
The other OPP system I had in mind: ObjectSystem.jl (the developer didn’t know of the former one…). Only/one reason I could see for such capabilities would be more visibility, but I think they should just be documented to exists (in Julia’s official docs…), to avoid reimplementing, not that I want OOP in Juli itself, I dislike OOP for performance reasons, and maintainability reasons, as much as the next guy. But I like that the options are there. For some strange reason the GitHub repo is gone, and I’m not sure where it is, how Julia installed it, so I can’t find the docs (was it deleted abandoned since redundant, not good enough yet?), [EDIT: ObjectOriented.jl works too, and starts very quickly.]
julia> @time using ObjectSystem
..
[ Info: Skipping precompilation since __precompile__(false). Importing ObjectSystem [beb21ac1-5488-4e8e-a65a-eed5c6ff7e13].
13.983373 seconds (6.72 M allocations: 496.686 MiB, 3.70% gc time, 52.19% compilation time)
There are some other related packages e.g. OOPMacro.jl and false alarms (I was looking up the name and docs): ObjectPools.jl and some possibly helpful to you: Interfaces.jl
What do you mean? Binary code for dependencies is already precompiled and cached, it’s just not for scripts, and juliac is solving that?