5 ms·

Julia is typesafe as both of c# / swift. Supporting programming in large has no meaning at all.

by h8hawk 8y ago

orbifold 8y ago
That is factually incorrect: It offers no static compilation guarantees at all. All it has is some form of duck typing, much like python, there were some discussions on this with Haskell people on the issue tracker that objected to the claim that Julia is dependently typed, when in fact it isn't. Programming in the large has a precise meaning. It is what Programming languages like Rust, OCaml, C#, Java, Swift, Go, Ada were designed for: Languages that facilitate many engineers (100s-1000s) to work on a common project, that requires static types, a sane package or module system and the possibility to separate implementation and interface (go interfaces, swift protocols etc.). None of these features really exist in Julia (in particular no static type system)
- KenoFischer 8y ago
  I always think these discussions miss the fact that static type systems only give you these benefits if whatever property you're trying to prove is encoded in your type system. E.g. people keep telling me that static type systems will prevent shape mismatch errors at runtime, but then go ahead and give their variables a static type of "Tensor" (without shape information), because encoding that shape information in the static type system is a bit of a pain and nobody really wants to write that (Not always, but it's a surprisingly common pattern). Meanwhile, we have absolutely no problem statically checking Julia code (and in fact we do when generating code for TPU). It's a bit of a non-standard thing to do and we're working on improving the tooling for this, but putting Julia on the same level as python here ignores a significant aspect of the design of Julia. As for collaborations among thousands of engineers, it is true that we don't really have Julia projects that large yet (other than Julia itself) and I'm sure we'll undoubtedly find things to improve in the language to support collaboration at that scale, but i really would encourage you to look at things like the new package manager or the documentation system. A significant amount of work has gone into the usability thereof and I think at that point they warrant criticism more detailed than an off hand dismissal.
  - tremors_123 8y ago
    Julia was created for and by the scientific computing/data scientists folk. It's a very valuable endeavor, I am glad we have another programming language/tool for this field. What I don't quite get it's the silly insistence of the Julia fanboys to claim Julia is a general programming language, and that as such it should be used for everything. There is nothing wrong with being a focused and discipline specific programming language.
    - byt143 8y ago
      Why is it a silly insistence? What about it is not fit for general programming? Please be specific.
  - renox 8y ago
    Yes, it always annoys how much C++ code is "integer typed"..
  - orbifold 8y ago
    I get that for scientific/numeric applications Julia is probably at a sweet spot and equally well suited if not better suited than many of its competitors (in many ways it feels like Matlab on steroids). Clearly the stuff you're doing with XLA.jl and the ease of implementation of Neural Differential Equations demonstrate the power of Julia's approach to deep learning. As you probably know it is hard (and in a precise sense actually theoretically impossible) to design type systems that are both convenient to use (have automatic type inference) and incorporate dependent types (such as shapes of tensors). Julia's solution of using multiple dispatch is not a substitute for such a static type system. Running into an exception, if there is no method for the particular combination of parameter types you have accidentally produced in a 1000 LOC project might be fine, it will make it pretty hard to refactor anything in a larger project. It results in exactly the same challenges that large python / javascript projects have. Those challenges are well documented and are the reason why large companies move away from those languages to statically typed languages. This is why I believe a statically typed language with good support for numerical computing will eventually win as the language of choice for large production machine learning applications. Leaving (for now) exotic examples such as Neural Differential Equations aside, current machine learning models would probably actually profit more from some of the type safety features let's say Swift has (using structs for example instead of Tensors of certain shapes) than from more comprehensive support of numerical features. For the most part we are talking about very basic linear algebra after all. The Swift for Tensorflow design documents argue this pretty convincingly as well. Regarding the package and module system you might be right, but looking at https://github.com/JuliaTPU/XLA.jl/blob/master/src/XLA.jl https://github.com/JuliaTPU/XLA.jl/blob/master/src/XLA.jl and comparing this to how you would assemble a user facing module in lets say OCaml https://github.com/janestreet/core/blob/master/src/core_unix.mli https://github.com/janestreet/core/blob/master/src/core_unix... I personally feel like the later gives me a lot more information how I would use the module and a clear separation from the implementation at the same time, similar things can be said about how this would look like in Swift or even a well written C/C++ header. As far as I can tell package management is still roughly at the level of pip in sophistication, not comparable to solutions like cargo or opam.

Julia is typesafe as both of c# / swift. Supporting programming in large has no meaning at all.

by h8hawk 8y ago

Julia is typesafe as both of c# / swift. Supporting programming in large has no meaning at all.

That is factually incorrect: It offers no static compilation guarantees at all. All it has is some form of duck typing, much like python, there were some discussions on this with Haskell people on the issue tracker that objected to the claim that Julia is dependently typed, when in fact it isn't. Programming in the large has a precise meaning. It is what Programming languages like Rust, OCaml, C#, Java, Swift, Go, Ada were designed for: Languages that facilitate many engineers (100s-1000s) to work on a common project, that requires static types, a sane package or module system and the possibility to separate implementation and interface (go interfaces, swift protocols etc.). None of these features really exist in Julia (in particular no static type system)

KenoFischer 8y ago
I always think these discussions miss the fact that static type systems only give you these benefits if whatever property you're trying to prove is encoded in your type system. E.g. people keep telling me that static type systems will prevent shape mismatch errors at runtime, but then go ahead and give their variables a static type of "Tensor" (without shape information), because encoding that shape information in the static type system is a bit of a pain and nobody really wants to write that (Not always, but it's a surprisingly common pattern). Meanwhile, we have absolutely no problem statically checking Julia code (and in fact we do when generating code for TPU). It's a bit of a non-standard thing to do and we're working on improving the tooling for this, but putting Julia on the same level as python here ignores a significant aspect of the design of Julia. As for collaborations among thousands of engineers, it is true that we don't really have Julia projects that large yet (other than Julia itself) and I'm sure we'll undoubtedly find things to improve in the language to support collaboration at that scale, but i really would encourage you to look at things like the new package manager or the documentation system. A significant amount of work has gone into the usability thereof and I think at that point they warrant criticism more detailed than an off hand dismissal.
- tremors_123 8y ago
  Julia was created for and by the scientific computing/data scientists folk. It's a very valuable endeavor, I am glad we have another programming language/tool for this field. What I don't quite get it's the silly insistence of the Julia fanboys to claim Julia is a general programming language, and that as such it should be used for everything. There is nothing wrong with being a focused and discipline specific programming language.
  - byt143 8y ago
    Why is it a silly insistence? What about it is not fit for general programming? Please be specific.
- renox 8y ago
  Yes, it always annoys how much C++ code is "integer typed"..
- orbifold 8y ago
  I get that for scientific/numeric applications Julia is probably at a sweet spot and equally well suited if not better suited than many of its competitors (in many ways it feels like Matlab on steroids). Clearly the stuff you're doing with XLA.jl and the ease of implementation of Neural Differential Equations demonstrate the power of Julia's approach to deep learning. As you probably know it is hard (and in a precise sense actually theoretically impossible) to design type systems that are both convenient to use (have automatic type inference) and incorporate dependent types (such as shapes of tensors). Julia's solution of using multiple dispatch is not a substitute for such a static type system. Running into an exception, if there is no method for the particular combination of parameter types you have accidentally produced in a 1000 LOC project might be fine, it will make it pretty hard to refactor anything in a larger project. It results in exactly the same challenges that large python / javascript projects have. Those challenges are well documented and are the reason why large companies move away from those languages to statically typed languages. This is why I believe a statically typed language with good support for numerical computing will eventually win as the language of choice for large production machine learning applications. Leaving (for now) exotic examples such as Neural Differential Equations aside, current machine learning models would probably actually profit more from some of the type safety features let's say Swift has (using structs for example instead of Tensors of certain shapes) than from more comprehensive support of numerical features. For the most part we are talking about very basic linear algebra after all. The Swift for Tensorflow design documents argue this pretty convincingly as well. Regarding the package and module system you might be right, but looking at https://github.com/JuliaTPU/XLA.jl/blob/master/src/XLA.jl https://github.com/JuliaTPU/XLA.jl/blob/master/src/XLA.jl and comparing this to how you would assemble a user facing module in lets say OCaml https://github.com/janestreet/core/blob/master/src/core_unix.mli https://github.com/janestreet/core/blob/master/src/core_unix... I personally feel like the later gives me a lot more information how I would use the module and a clear separation from the implementation at the same time, similar things can be said about how this would look like in Swift or even a well written C/C++ header. As far as I can tell package management is still roughly at the level of pip in sophistication, not comparable to solutions like cargo or opam.