4 ms·

Julia compares very unfavourably to both Python and Swift: Slow startup time (unpredictable JIT compiler lag), terrible error messages and stack traces, duck ty

Julia compares very unfavourably to both Python and Swift: Slow startup time (unpredictable JIT compiler lag), terrible error messages and stack traces, duck typing misrepresented as type checking. I've tried using it for what it is meant for (numerical code / ODE solving etc.) multiple times now. It performs admirably in that domain. But no ten horses would make me use it for anything else. Machine learning needs to be fully integrated into the larger language ecosystem. You can easily imagine developing a large scale software product in Swift, not so much in Julia (even less so than in Python). Julia is probably a Nightmare to develop in once you have more than 10 people working on the project. The internal structure of Julia's compiler is also a mess compared to the Swift compiler. You could easily imagine building a compile service / large scale build system / tooling for swift, not so much for Julia. Plus they were able to easily extend the Swift intermediate language in the way they wanted to, while there is no comparable abstraction in Julia. The Swift compiler also fits neatly into the C++ based ecosystem that Google has.

cwyers 7y ago
It's possible that it's less effort for a top notch compiler developer to come in and fix Julia's compiler than it is to give Swift the data science ecosystem that Julia is building. I have little experience with it, but it's a question of tradeoffs.
- orbifold 7y ago
  Well from my point of view, the largest advantage that Swift has over Julia is that it has a pretty nice static type system. If you look at what they did with the Differentiable protocol, then this is precisely what you want from a type system perspective without going all in on dependent types. Historically there are very few examples where a dynamically typed language was retrofitted with a static type system successfully (Typescript and Javascript being one example). Julia's multi methods are really nice but produce horrible errors when they fail at runtime, I don't see an obvious way to fix that. There is a bigger chance that another contender arises within the C#/F# ecosystem as an evolution of the ML.Net work, then that a company invests significant resources in Julia to make it suitable for large scale machine learning in a non scientific "blue collar" setting.
  - FridgeSeal 7y ago
    > Julia's multi methods are really nice but produce horrible errors when they fail at runtime, I don't see an obvious way to fix that. What? I have had no trouble with the errors produced from multiple dispatch! More often than not they've helped me get straight to the fix, which is more than I can ever say for Python. > There is a bigger chance that another contender arises within the C#/F# ecosystem as an evolution of the ML.Net work I would rather claw my eyes out than do significant data work in .Net. C# is our language of choice at work, and it's pretty great for them, but my god is it the most verbose, confusing and convoluted language I've ever had to deal with. F# isn't too bad, but once again, lacks any serious data science community and package support. They're also not terribly fast languages, which is a pretty important factor in ML stuff.
byt143 7y ago
So many patently false claims here. 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/ 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 https://github.com/FluxML/Flux.jl/issues/614
- orbifold 7y ago
  I don't think static type checking is a matter of tooling, getting Julia to perform well amounts to either a lot of trust in the compiler (is static type inference for the Julia type system even possible?) or manual type annotations as far as I can tell. And static types are not there in a large program to make them necesarily faster, but to automatically enforce contracts. For this to work they have to be mandatory, not added on as an after thought. I don't want to be able to run a program only to discover it crashes because a method was not overloaded with this particular combination of parameter types. Swift has clearly an advantage in that domain, as has C++, C#. In an enterprise setting such as Google no one actually wants speed and dynamism out of a language (C++ programmers are not allowed to use rtti for example), rather consistently boring, predictable, statically guaranteed results with as minimal fuzz as possible (Go, Java, C++) and enough competent programmers in that language. I agree that it is neat that you can hack the Julia compiler in a library to do compile time automatic differentiation, but my point was that if you build it into the language like the Swift for Tensorflow authors are doing this will result in a more conservative, if inflexible, but potentially more performant solution. In other words precisely because you need a team of people to implement and integrate this feature in C++ you will get a stable "single source of truth" implementation in the language, not several (Flux, Zygote) constantly changing libraries. Well I've tried DiffEqFlux.jl with Julia 1.1, it works well enough, but the stack traces are ridiculously long if something goes wrong, a ~200 LOC program takes seconds to compile and the library and package management story seems immature compared to rust/swift/python/c++.

cwyers 7y ago

It's possible that it's less effort for a top notch compiler developer to come in and fix Julia's compiler than it is to give Swift the data science ecosystem that Julia is building. I have little experience with it, but it's a question of tradeoffs.

orbifold 7y ago
Well from my point of view, the largest advantage that Swift has over Julia is that it has a pretty nice static type system. If you look at what they did with the Differentiable protocol, then this is precisely what you want from a type system perspective without going all in on dependent types. Historically there are very few examples where a dynamically typed language was retrofitted with a static type system successfully (Typescript and Javascript being one example). Julia's multi methods are really nice but produce horrible errors when they fail at runtime, I don't see an obvious way to fix that. There is a bigger chance that another contender arises within the C#/F# ecosystem as an evolution of the ML.Net work, then that a company invests significant resources in Julia to make it suitable for large scale machine learning in a non scientific "blue collar" setting.
- FridgeSeal 7y ago
  > Julia's multi methods are really nice but produce horrible errors when they fail at runtime, I don't see an obvious way to fix that. What? I have had no trouble with the errors produced from multiple dispatch! More often than not they've helped me get straight to the fix, which is more than I can ever say for Python. > There is a bigger chance that another contender arises within the C#/F# ecosystem as an evolution of the ML.Net work I would rather claw my eyes out than do significant data work in .Net. C# is our language of choice at work, and it's pretty great for them, but my god is it the most verbose, confusing and convoluted language I've ever had to deal with. F# isn't too bad, but once again, lacks any serious data science community and package support. They're also not terribly fast languages, which is a pretty important factor in ML stuff.

byt143 7y ago

So many patently false claims here. 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/ 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 https://github.com/FluxML/Flux.jl/issues/614

orbifold 7y ago
I don't think static type checking is a matter of tooling, getting Julia to perform well amounts to either a lot of trust in the compiler (is static type inference for the Julia type system even possible?) or manual type annotations as far as I can tell. And static types are not there in a large program to make them necesarily faster, but to automatically enforce contracts. For this to work they have to be mandatory, not added on as an after thought. I don't want to be able to run a program only to discover it crashes because a method was not overloaded with this particular combination of parameter types. Swift has clearly an advantage in that domain, as has C++, C#. In an enterprise setting such as Google no one actually wants speed and dynamism out of a language (C++ programmers are not allowed to use rtti for example), rather consistently boring, predictable, statically guaranteed results with as minimal fuzz as possible (Go, Java, C++) and enough competent programmers in that language. I agree that it is neat that you can hack the Julia compiler in a library to do compile time automatic differentiation, but my point was that if you build it into the language like the Swift for Tensorflow authors are doing this will result in a more conservative, if inflexible, but potentially more performant solution. In other words precisely because you need a team of people to implement and integrate this feature in C++ you will get a stable "single source of truth" implementation in the language, not several (Flux, Zygote) constantly changing libraries. Well I've tried DiffEqFlux.jl with Julia 1.1, it works well enough, but the stack traces are ridiculously long if something goes wrong, a ~200 LOC program takes seconds to compile and the library and package management story seems immature compared to rust/swift/python/c++.