4 ms·

You are very misinformed here. Julia doesn't have static typing and there are a very large set of problems that are trivially solved with it's type system. Se

You are very misinformed here. Julia doesn't have static typing and there are a very large set of problems that are trivially solved with it's type system. See the tables.jl ecosystem for example

mlthoughts2018 6y ago
I think you are misinformed. Runtime dispatch on multiple argument types is still using static typing under the hood (Julia is using this, just as Cython is). The fact that input types are dynamic and resolved at runtime (which works identically in both Julia and Python using a Cython extension module) does not mean the multiple dispatch “is dynamic” (it’s still based on a registry of types that determine which overloaded implementation to select). The only trade-off is whether you want to be able to extend this registry of static types mapping to implementations on the fly (similar to type classes in Haskell) which Julia supports natively and Python supports via tools like numba, or you need to ahead-of-time compile it (Cython). This is a trade-off though, between AOT resolver speed vs JIT flexibility. It’s not definitely better one way or the other, and Cython gives you a level of control over explicit language features to enable or disable (eg Exception disabling) that is much better for some use cases.
- dklend122 6y ago
  No. You're confusing static dispatch with static typing. Julia can do both static and dynamic dispatch. The latter works with function barriers works to maintain codebases that are impossible to achieve with just one or the other. There's no resolving trade-off because when Julia knows types and call time (or a union of them ) it can inline function calls. Anyway, neither numba nor cython has the combin of features that allows for one to define a fast custom abstract array and have another package seamlessly define a subtype that works fast and with other data structures, overloading only the necessary functions. Then a third package can come and build on top using traits from the first and some weird solver.
  - mlthoughts2018 6y ago
    No, you are still misunderstanding static type dispatch within a dynamic language. The registry of overloaded specializations works based on static type information. That is not a requirement to have statically typed values (neither in Python nor Julia) but it is still statically typed.

You are very misinformed here. Julia doesn't have static typing and there are a very large set of problems that are trivially solved with it's type system. See the tables.jl ecosystem for example

mlthoughts2018 6y ago

I think you are misinformed. Runtime dispatch on multiple argument types is still using static typing under the hood (Julia is using this, just as Cython is). The fact that input types are dynamic and resolved at runtime (which works identically in both Julia and Python using a Cython extension module) does not mean the multiple dispatch “is dynamic” (it’s still based on a registry of types that determine which overloaded implementation to select). The only trade-off is whether you want to be able to extend this registry of static types mapping to implementations on the fly (similar to type classes in Haskell) which Julia supports natively and Python supports via tools like numba, or you need to ahead-of-time compile it (Cython). This is a trade-off though, between AOT resolver speed vs JIT flexibility. It’s not definitely better one way or the other, and Cython gives you a level of control over explicit language features to enable or disable (eg Exception disabling) that is much better for some use cases.

dklend122 6y ago
No. You're confusing static dispatch with static typing. Julia can do both static and dynamic dispatch. The latter works with function barriers works to maintain codebases that are impossible to achieve with just one or the other. There's no resolving trade-off because when Julia knows types and call time (or a union of them ) it can inline function calls. Anyway, neither numba nor cython has the combin of features that allows for one to define a fast custom abstract array and have another package seamlessly define a subtype that works fast and with other data structures, overloading only the necessary functions. Then a third package can come and build on top using traits from the first and some weird solver.
- mlthoughts2018 6y ago
  No, you are still misunderstanding static type dispatch within a dynamic language. The registry of overloaded specializations works based on static type information. That is not a requirement to have statically typed values (neither in Python nor Julia) but it is still statically typed.