4 ms·

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 infere

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++.

simondanisch 7y ago
>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. That's a pretty weird statement, considering how hard it is to write a complex C++ program error free. I suppose Swift is much better in this regard - But compared to C++, Julia is a bliss and one can easily write huge applications error free, while I had my absolute worst debugging experiences in C++, where it's very easy to create obscure and hard to find bugs. If you really need to get predictable results and actually know those results - you won't get away with a static type checker anyways, but will have to write & run tests, which then pretty much make it irrelevant whether your language is dynamic or not.
simondanisch 7y ago
Btw, the argument "If it compiles, I don't need to be afraid about run time errors anymore" is also pretty foreign to me. I just run my code in small batches while developing it, so at every point I already know that it works. This helps writing code that nicely separates into small chunks of functionality, and you basically automatically write tests for it while at it. This is especially nice when refactoring a large code base. I can already run many small and usable tests in the middle of a refactor (while the program wouldn't even compile in a static language). In my experience, this greatly helps to improve the quality of the refactor, and makes it much easier to see problems in your refactoring approach very early on. In a static language, you'd only get these crucial insights after you're done with fixing all compilation errors - which is usually when you're already done with the whole refactor... and after that, you might still have lots of errors in it that you can only find with real tests ;)

simondanisch 7y ago

>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. That's a pretty weird statement, considering how hard it is to write a complex C++ program error free. I suppose Swift is much better in this regard - But compared to C++, Julia is a bliss and one can easily write huge applications error free, while I had my absolute worst debugging experiences in C++, where it's very easy to create obscure and hard to find bugs. If you really need to get predictable results and actually know those results - you won't get away with a static type checker anyways, but will have to write & run tests, which then pretty much make it irrelevant whether your language is dynamic or not.

simondanisch 7y ago

Btw, the argument "If it compiles, I don't need to be afraid about run time errors anymore" is also pretty foreign to me. I just run my code in small batches while developing it, so at every point I already know that it works. This helps writing code that nicely separates into small chunks of functionality, and you basically automatically write tests for it while at it. This is especially nice when refactoring a large code base. I can already run many small and usable tests in the middle of a refactor (while the program wouldn't even compile in a static language). In my experience, this greatly helps to improve the quality of the refactor, and makes it much easier to see problems in your refactoring approach very early on. In a static language, you'd only get these crucial insights after you're done with fixing all compilation errors - which is usually when you're already done with the whole refactor... and after that, you might still have lots of errors in it that you can only find with real tests ;)