|
Just a comment to participants who are suspicious of Julia usage over another, more popular language (for example) -- I think most Julia users are aware that the ecosystem is young, and that encouraging usage in new industry settings incurs an engineering debt associated with the fact that bringing a new language onto any project requires an upfront cost, followed by a maintenance cost. Most of these arguments are re-hashed on each new Julia post here. A few comments: For most Julia users, any supposed rift between Python and Julia is not really a big deal -- we can just use PyCall.jl, a package whose interop I've personally used many times to wrap existing Python packages -- and supports native interop with Julia <-> NumPy arrays. Wrapping C is similarly easy -- in fact, easier than "more advanced" languages like Haskell -- whose C FFI only supports passing opaque references over the line. Ultimately, when arguments between languages in this space arise -- the long term question is the upfront cost, and the maintenance cost for a team. Despite the fact that Julia provides an excellent suite of wrapper functionality, I'm aware that introducing new Julia code into an existing team space suffers from the above issues. I'm incredibly biased, but I will state: maintaining Julia code is infinitely easier than other uni-typed languages. I've had to learn medium-sized Python codebases, and it is a nightmare compared to a typed language. This total guessing game about how things flow, etc. It really is shocking. Additionally, multiple dispatch is one of those idioms where, one you learn about it, you can't really imagine how you did things before. I'm aware of equivalences between the set of language features (including type classes, multi-method dispatch, protocols or interfaces, etc). Ultimately, the Julia code I write feels (totally subjectively) the most elegant of the languages I've used (including Rust, Haskell, Python, C, and Zig). Normally I go exploring these other languages for ideas -- and there are absolutely winners in this group -- but I usually come crawling back to Julia for its implementation of multiple dispatch. Some of these languages support abstractions which are strictly equivalent to static multi-method dispatch -- which I enjoy -- but I also really enjoy Julia's dynamism. And the compiler team is working to modularize aspects of the compiler so that deeper characteristics of Julia (even type inference and optimization) can be configured by library developers for advanced applications (like AD, for example). The notion of a modular JIT compiler is quite exciting to me. Other common comments: time to first plot, no native compilation to binary, etc are being worked on. Especially the latter with new compiler work (which was ongoing before the new compielr work) -- seems feasible within a few quarter's time. |
Yes, and even with languages that have these abstractions, they aren't as pervasive as in Julia. Ex. There's a fundamental difference between typclasses and functions in haskell. In julia, there's no such distinction and code is more generic