4 ms·

Short list of current priorities (in no particular order) Making it easier to interface with the compiler (this is step 1 on better ability to static compile/de

Short list of current priorities (in no particular order) Making it easier to interface with the compiler (this is step 1 on better ability to static compile/debug) Better garbage collection More performance Reducing the memory footprint of small strings Lowering the overhead of multithreading It's worth noting that Julia doesn't really have a core team. A lot of the development is done by a pretty large community of developers without any central management.

amkkma 5y ago
They've been pretty mum on the type system stuff though. Do you have any insight there?
- oscardssmith 5y ago
  The short answer is that changing the type system to allow multiple inheritance (traits) involves solving some really hard and open-ended problems (eg method specificity). Solving this is probably breaking, and requires a ton of work on a problem that might not even be solvable. If I had to guess it will be solved by the language that replaces Julia in 20 years.
  - deleted 5y ago
    [deleted]
  - amkkma 5y ago
    Thanks
Kalanos 5y ago
Thanks for the info. What worries me is that you can replace 'Julia' with 'Scala' in that sentence and a data scientist wouldn't know the difference. It's already fast. If Julia wants to win in data science then they need to poach users away from other languages.
- BadInformatics 5y ago
  As much as many of us would like it to be, the kind of data science work you see Scala used for is a pretty small part of what Julia is used for. I think a big part of that is because DS rarely involves writing fast numeric kernels or hot inner loops, i.e. user code that needs to do numeric stuff quickly. This is in large part because very large organizations have poured untold millions into libraries that already handle this (e.g Spark). In domains where this has not happened or that have more bespoke requirements (e.g. modelling and simulation), something like Julia is far more compelling. That's not to say it's not viable, but unless more practitioners start feeling stuck in a rut [1] I don't see the mindshare changing dramatically. [1] https://dl.acm.org/doi/10.1145/3317550.3321441 https://dl.acm.org/doi/10.1145/3317550.3321441

amkkma 5y ago

They've been pretty mum on the type system stuff though. Do you have any insight there?

oscardssmith 5y ago
The short answer is that changing the type system to allow multiple inheritance (traits) involves solving some really hard and open-ended problems (eg method specificity). Solving this is probably breaking, and requires a ton of work on a problem that might not even be solvable. If I had to guess it will be solved by the language that replaces Julia in 20 years.
- deleted 5y ago
  [deleted]
- amkkma 5y ago
  Thanks

Kalanos 5y ago

Thanks for the info. What worries me is that you can replace 'Julia' with 'Scala' in that sentence and a data scientist wouldn't know the difference. It's already fast. If Julia wants to win in data science then they need to poach users away from other languages.

BadInformatics 5y ago
As much as many of us would like it to be, the kind of data science work you see Scala used for is a pretty small part of what Julia is used for. I think a big part of that is because DS rarely involves writing fast numeric kernels or hot inner loops, i.e. user code that needs to do numeric stuff quickly. This is in large part because very large organizations have poured untold millions into libraries that already handle this (e.g Spark). In domains where this has not happened or that have more bespoke requirements (e.g. modelling and simulation), something like Julia is far more compelling. That's not to say it's not viable, but unless more practitioners start feeling stuck in a rut [1] I don't see the mindshare changing dramatically. [1] https://dl.acm.org/doi/10.1145/3317550.3321441 https://dl.acm.org/doi/10.1145/3317550.3321441