4 ms·

These tools are a great improvement, but honestly I find working with this aspect of Julia to be super frustrating. External tools feels like a poor substitute

These tools are a great improvement, but honestly I find working with this aspect of Julia to be super frustrating. External tools feels like a poor substitute for a type system where this kind of information was obvious from the code.

vchuravy 3y ago
Yeah in the end this the difference between dynamical and static typing. I enjoy https://tratt.net/laurie/research/pubs/html/tratt__dynamically_typed_languages/ https://tratt.net/laurie/research/pubs/html/tratt__dynamical... as a discussion of dynamic typing.
ssivark 3y ago
Are you talking about static typing? If so, that sounds fundamentally incompatible with the basic worldview behind Julia — that you want to delay binding/dispatch till runtime, and leverage multiple dispatch, for high composability & code reuse. I wonder how capable the ahead-of-time compiler would be, if you have not just the library, but can also provide the “inputs” in your “script” (that it can specialize on).
- skybrian 3y ago
  The question I have is whether Julia-style multiple dispatch would be practical in a statically typed language?
  - deleted 3y ago
    [deleted]
  - cmrdporcupine 3y ago
    Multiple dispatch is a kind of runtime type resolution. Static/compile-time function overloading based on types is a thing, but is fairly banal... common in C++, but mostly forbidden in Rust, but it doesn't resolve on vtables, so doesn't give you the same kind of polymorphism as what you'd get in Dylan/Julia/CLOS/Cecil, etc. This looks like a good series of blog posts on this topic: https://eli.thegreenplace.net/tag/multiple-dispatch https://eli.thegreenplace.net/tag/multiple-dispatch Myself, I was excited to work in a language with multiple dispatch at first, but once I spent some time working full-time in Julia the sheen wore off. It could be Julia's take on it, but I really don't like the kind of ... semantic overloading ... and duck typing that can happen all over the place. Programs can become very hard to reason about.
    - underdraft_fee 3y ago
      I've worked quite extensively for Julia as my primary language for quite some time at this point. I've gone from being absolutely in love with the language to extremely disillusioned over the last couple of years. It is incredibly hard to reason about this language if every developer is not willing to commit to understanding and writing Julia code the right way (e.g. type stable, dispatch via the type system, actually defining interfaces). Given the target demographic of academics, the proportion of people interested in grokking Julia is vastly smaller than the number of academics who hear "walks like Python runs like C" and decide this is their new, free, hip MATLAB/SciPy replacement. And it's extremely good for that! The SciML ecosystem is top of the class, I would never recommend someone solve a differential equation any other way. If you can build a system that is just a thin wrapper on top of SciML, absolutely go for it. I would recommend anyone wanting to build new systems from scratch to look elsewhere. But, the tooling is subpar and overfit to the VS Code extension, and even there I found so many false positives with the linter that I just started ignoring all but the most basic of warnings. It's not entirely the fault of the developers, Julia is dynamically typed and there's only so much you can do. But if you have to type things rigidly enough that it's inferrable while developing that Cthulhu.jl or JET.jl can infer the types, why not just work with a static type system where you get that for free? I have also found the obsession with reducing time to first plot incredibly aggravating. It is finally down to a pretty good level, which is a nice quality of life improvement. However, it has done absolutely nothing for my ability to write code that doesn't crash because someone passed in a type that doesn't obey the implicit interface I expect.
      - cmrdporcupine 3y ago
        I was working in a non-numerics/non-scientific code base and the quality of the code was good to very good. And I could see the value Julia was bringing to the table on some aspects of the higher levels of their stack. But it utterly fails at being any kind of "systems language", and it was being coraled into that role in spots. Tossing some optional somewhat-static (but not really) type declarations and a JIT into the language doesn't make it a performant language for areas where something like C++, Rust, etc. would be more suited. And yes, like any late-bound language, it's going to be prone to crashing at runtime in unexpected ways. Julia has some okayish tools for doing some static analysis, but it's never going to be at the level of what you can get out of an actual modern static type system. I was fortunate to work with some very smart people who had written some very high quality code in Julia, and some aspects of the language I found very nice and expressive (and even sometimes miss), but I was happy to go back to writing Rust after I switched jobs. And yeah, not being a VSCode user (JetBrains addict), I found tooling lacking as well. The emacs mode was okayish. Also found I kept having to use the Repl in ways I found non-intuitive. I would reach for Julia as an alternative to Python, maybe, for certain types of things. It's certainly prettier to look at.
  - kelipso 3y ago
    Haskell's type classes work fine, similar enough to multiple dispatch.
    - majoe 3y ago
      I think it would be great for Julia to have a mechanism to formalise/enforce interfaces. I thought a bit about it lately and came to the conclusion, that something like C++ concepts (minus the clunky syntax) would be a better fit for Julia than Haskell's typeclasses or Rust traits. The main difference for me is, that typeclasses are a whitelist of allowed types, while concepts are a set of type constraints, that blacklist types, when the constraints are not fulfilled. Otherwise they are quite similar. As a result, you don't have to explicitly create a instance with concepts like you would need to do for type classes and packages can happily interoperate without knowing of each other.
      - kelipso 3y ago
        I think type classes and packages can happily interoperate without knowing of each other, just like abstract types and packages do currently...well I guess the concepts idea would make it so you'd need even less coordination. But yeah, would be nice if Julia had formal interfaces.
- majoe 3y ago
  Playing advocatus deii for Julia, I guess you could write code, where all function signatures only contain concrete types. Then the ahead-of-time compiler would work the same as for a C++ program without templates and dynamic polymorphism through subtyping. That's a totally valid programming model, that noone uses. Of course you don't have to go that far in practice and you still could have static types with less restrictions, as long as the types are inferable

vchuravy 3y ago

Yeah in the end this the difference between dynamical and static typing. I enjoy https://tratt.net/laurie/research/pubs/html/tratt__dynamically_typed_languages/ https://tratt.net/laurie/research/pubs/html/tratt__dynamical... as a discussion of dynamic typing.

ssivark 3y ago

Are you talking about static typing? If so, that sounds fundamentally incompatible with the basic worldview behind Julia — that you want to delay binding/dispatch till runtime, and leverage multiple dispatch, for high composability & code reuse. I wonder how capable the ahead-of-time compiler would be, if you have not just the library, but can also provide the “inputs” in your “script” (that it can specialize on).

skybrian 3y ago
The question I have is whether Julia-style multiple dispatch would be practical in a statically typed language?
- deleted 3y ago
  [deleted]
- cmrdporcupine 3y ago
  Multiple dispatch is a kind of runtime type resolution. Static/compile-time function overloading based on types is a thing, but is fairly banal... common in C++, but mostly forbidden in Rust, but it doesn't resolve on vtables, so doesn't give you the same kind of polymorphism as what you'd get in Dylan/Julia/CLOS/Cecil, etc. This looks like a good series of blog posts on this topic: https://eli.thegreenplace.net/tag/multiple-dispatch https://eli.thegreenplace.net/tag/multiple-dispatch Myself, I was excited to work in a language with multiple dispatch at first, but once I spent some time working full-time in Julia the sheen wore off. It could be Julia's take on it, but I really don't like the kind of ... semantic overloading ... and duck typing that can happen all over the place. Programs can become very hard to reason about.
  - underdraft_fee 3y ago
    I've worked quite extensively for Julia as my primary language for quite some time at this point. I've gone from being absolutely in love with the language to extremely disillusioned over the last couple of years. It is incredibly hard to reason about this language if every developer is not willing to commit to understanding and writing Julia code the right way (e.g. type stable, dispatch via the type system, actually defining interfaces). Given the target demographic of academics, the proportion of people interested in grokking Julia is vastly smaller than the number of academics who hear "walks like Python runs like C" and decide this is their new, free, hip MATLAB/SciPy replacement. And it's extremely good for that! The SciML ecosystem is top of the class, I would never recommend someone solve a differential equation any other way. If you can build a system that is just a thin wrapper on top of SciML, absolutely go for it. I would recommend anyone wanting to build new systems from scratch to look elsewhere. But, the tooling is subpar and overfit to the VS Code extension, and even there I found so many false positives with the linter that I just started ignoring all but the most basic of warnings. It's not entirely the fault of the developers, Julia is dynamically typed and there's only so much you can do. But if you have to type things rigidly enough that it's inferrable while developing that Cthulhu.jl or JET.jl can infer the types, why not just work with a static type system where you get that for free? I have also found the obsession with reducing time to first plot incredibly aggravating. It is finally down to a pretty good level, which is a nice quality of life improvement. However, it has done absolutely nothing for my ability to write code that doesn't crash because someone passed in a type that doesn't obey the implicit interface I expect.
    - cmrdporcupine 3y ago
      I was working in a non-numerics/non-scientific code base and the quality of the code was good to very good. And I could see the value Julia was bringing to the table on some aspects of the higher levels of their stack. But it utterly fails at being any kind of "systems language", and it was being coraled into that role in spots. Tossing some optional somewhat-static (but not really) type declarations and a JIT into the language doesn't make it a performant language for areas where something like C++, Rust, etc. would be more suited. And yes, like any late-bound language, it's going to be prone to crashing at runtime in unexpected ways. Julia has some okayish tools for doing some static analysis, but it's never going to be at the level of what you can get out of an actual modern static type system. I was fortunate to work with some very smart people who had written some very high quality code in Julia, and some aspects of the language I found very nice and expressive (and even sometimes miss), but I was happy to go back to writing Rust after I switched jobs. And yeah, not being a VSCode user (JetBrains addict), I found tooling lacking as well. The emacs mode was okayish. Also found I kept having to use the Repl in ways I found non-intuitive. I would reach for Julia as an alternative to Python, maybe, for certain types of things. It's certainly prettier to look at.
- kelipso 3y ago
  Haskell's type classes work fine, similar enough to multiple dispatch.
  - majoe 3y ago
    I think it would be great for Julia to have a mechanism to formalise/enforce interfaces. I thought a bit about it lately and came to the conclusion, that something like C++ concepts (minus the clunky syntax) would be a better fit for Julia than Haskell's typeclasses or Rust traits. The main difference for me is, that typeclasses are a whitelist of allowed types, while concepts are a set of type constraints, that blacklist types, when the constraints are not fulfilled. Otherwise they are quite similar. As a result, you don't have to explicitly create a instance with concepts like you would need to do for type classes and packages can happily interoperate without knowing of each other.
    - kelipso 3y ago
      I think type classes and packages can happily interoperate without knowing of each other, just like abstract types and packages do currently...well I guess the concepts idea would make it so you'd need even less coordination. But yeah, would be nice if Julia had formal interfaces.
majoe 3y ago
Playing advocatus deii for Julia, I guess you could write code, where all function signatures only contain concrete types. Then the ahead-of-time compiler would work the same as for a C++ program without templates and dynamic polymorphism through subtyping. That's a totally valid programming model, that noone uses. Of course you don't have to go that far in practice and you still could have static types with less restrictions, as long as the types are inferable