Specifically what?
220 karma · joined December 6, 2017
I think it will also rocket up Julia's popularity and usage not just for ML but as a general purpose language
Works with typed IR equivalent to a core compiler pass but from a third party package with regular Julia staged programming.
And the semantics are the same with some additions. This is a good thing as it allow interop with Julia code, low mental overhead and shows the power of Julia :)
Luckily package compilation seems is on the compiler dev roadmap.
Traits are more of a 2.0 thing I think.
First, julia has it's own IR (comparable to swift IR as mentioned by Chris), which is used to great effect in the autodiff packages to allow for compile time zero overhead gradients. The flexibility is actually the other way around, Julia's compiler allows these sort of compile time initiatives to be built in Julia rather than hacked into C++ like swift.
Regarding the duck typing vs type checking bit, that's a matter of tooling. It's much harder to replicate Julia's combination of speed and dynamism (for example to do flexible multistage programming) than to capitalize on Julia's the compile time information to build type checking (which are planned)
The compiler lag is going to be gone soon from two ends: more dynamic (interpreting code that doesn't need to be compiled, this is pretty much there already) and more static: Compiling and caching entire Julia programs. There are already fantastic improvements to this situation in 1.2
That leaves the error messages and stack traces, which ...well what's the last version you have tried? I find them to be ok, but they can and will be improved.
Regarding general purpose packages in Julia: check out http://genieframework.com/ as an example.
Julia's multimethods are awesome and a clear advantage over swift's methods. A protocol abstraction is similiar to julia's facility for traits, will at some point will be likely baked into the language (but even now allows for compile time resolution of methods just through multi dispatch abstraction , which again, is only one step away from building type check abstractions!).
If you want to know more about Julia's plans and philosophy in the regards, see: https://github.com/FluxML/Flux.jl/issues/614
see this as an example: http://genieframework.com/
Julia can Jit code that relies on vastly improved versions of all those features (minus some setatr etc).
Can you use them on a custom array type in any case let alone scipy? No. and that's the point. In julia, the optim package for example takes in abstract arrays with all those features. Mathematical assumptions are categorically different than unavailable or slow PL semantics.
Julia preserves full general programming language semantics including zero cost abstractions, higher order functions, closures, zero cost differentiation and extending custom types, while still being fast enough for numerical computing (minus exceptions).
It seems to be that Python is sticking with 1d figures and that's assuming your monkey patch idea works, also ignoring the ecosystem cost and the fact that monkeypatching in Julia is part of normal code design (through multimethods) whereas in python it's a code smell.
I think you are really grasping at straws here.
Have you tried that yet?
Re: Scoping rules, these are being evaled.
Re; startup time, already better in 1.1, and will soon be marginalized from two ends: Better static compilation and better tiered compilation.
It's a superior platform to on which develop this sort of thing, and further along at that. Also easier to use.
Then we have metaclasses, abstract base classes and protocols.
Also Super and self everywhere.
Even more complexity with typing, which is necessary if you want to approach similar type safety to julia ie to make the comparison more fair.
The one issue is compilation time, which is much and improved and will be further obviated through more caching and planned multi level compilation.