8 ms·

Can someone please explain to me, a mere mortal, what is the big deal with Julia. Why use it, when there are so many other good languages out there with more co

Can someone please explain to me, a mere mortal, what is the big deal with Julia. Why use it, when there are so many other good languages out there with more community/support? Honest question.

RandomWorker 5y ago
Basically, the syntax is similar to matlap as well as lots of the same features around functional and variable deceleration as python. The best thing for sure is the native support for parallel processing. Where python is single tread.
Kranar 5y ago
I think your question presupposes a lot of assumptions that may not be right. For one, I don't know that Julia is like a "big deal", certainly Python is the big deal in this field and I doubt Julia is looking to displace it wholesale. That said, Julia is a great addition to the scientific computing landscape because of its performance compared to other languages and its use of modern programming features. Python is just really really slow compared to Julia and parallelism in Python is a huge pain. Fortran is really really fast but that comes at a cost of being awkward to use and coming with a great deal of baggage. Julia is fast, feels modern, and has pretty easy parallelism. Then there's Matlab, Mathematica, and they are also pretty good but they're closed source/proprietary, so their ecosystem is mostly limited and driven by commercial interests. Nothing wrong with that intrinsically and they're all widely used but it's one way Julia differentiates itself, by making the language open and making money through services.
- ChrisRackauckas 5y ago
  Julia Computing is not a services company. There are commercial products built off of this stack which are the core of Julia Computing. For example, https://pumas.ai/ https://pumas.ai/ is a product for pharmacology modeling and simulation, and runs on the JuliaHub cloud platform of Julia Computing. It is already a big deal in the industry, with the quote everyone refers to "Pumas has emerged as our 'go-to' tool for most of our analyses in recent months" from the Director Head of Clinical Pharmacology and Pharmacometrics at Moderna Therepeutics during 2020 (for details, see the full approved press release from the Pumas.ai website). JuliaSim is another major product which is being released soon, along with JuliaSPICE publicly in the pipeline. But indeed, Julia Computing differentiates itself from something like MATLAB or Mathematica by leveraging a strong open source community on which these products are developed. These products add a lot of the details that are generally lacking in the open source space, such as strong adherents to file formats, regulatory compliance and validation, GUIs, etc. which are required to take such a product from "this guy can use it" to a fully marketable product usable by non-computational scientists. I will elaborate a bit more on this at JuliaCon next week in my talk on the release of JuliaSim.
  - codekilla 5y ago
    Wanted to ask if JuliaDB is something that might get more development attention? Or will that remain a community project? (I see it’s been in need of a release for awhile.)
    - ChrisRackauckas 5y ago
      It is not in our current set of major products. That said, informal office discussions mentioned JuliaDB as recently as last week, so it's not forgotten. If there's a demonstrated market, say a need for new high-performance cloud data science tools as part of the pharmaceutical domains we work in, then something like JuliaDB could possibly be revived in the future (of course, this is no guarantee).
    - ViralBShah 5y ago
      In general, the community has discussed reviving the project (or at least the ideas and some of its codebase). Julia computing will also be contributing as part of that revival.
      - codekilla 5y ago
        Thank you both for the comments. I believe I remember early on there were some comparisons to kdb+/q. I think there is some pretty great potential with an offering like this (an in-memory database integrated with the language, coupled with solid static storage) from the Julia community going forward. I can envision some use cases in genomics/transcriptomics.
nvrspyx 5y ago
From what I understand, Julia is dynamically typed and similar to a scripting language like Python or Ruby, but is also compiled, so it has performance similar to C/C++ (it's also written in itself). It also has built-in support for parallelism, multi threading, GPU compute, and distributed compute. I'm sure others can provide more insight. I've only dabbled in it and haven't used it extensively in any sense of the word.
deleted 5y ago
[deleted]
oscardssmith 5y ago
Short answer is that it is (imo) by far the best language for writing generic and fast math. Multiple dispatch allows you to write math using normal notation and not have to jump through hoops to do so.
- enriquto 5y ago
  can you show a simple example of that? I tend to see multiple dispatch as a mental burden, (e.g.: when I see a function call, where will it be dispatched? the answer dependa on the types that I'm juggling, that may not even be visible at that point...)
  - oscardssmith 5y ago
    The key to make multiple dispatch work well is that you shouldn't have to think about what method gets called. For this to work out, you need to make sure that you only add a method to a function if it does the "same thing" (so don't use >> for printing for example). To Dr the benefit of this in action, consider that in Julia 1im+2//3 (the syntax for sqrt(-1)+2 thirds) works and gives you a complex rational number (2//3+1//1 im). To get this behavior in most other languages, you would have to write special code for complex numbers with rational coefficients, but in Julia this just works since complex and rational numbers can be constructed using anything that has arithmetic defined. This goes all the way up the stack in Julia. You can put these numbers in a matrix, and matrix multiplication will just work, you can plot functions using these numbers, you can do gpu computation with them etc. All of this works (and is fast) because multiple dispatch can pick the right method based on all the argument types.
    - enriquto 5y ago
      > make sure that you only add a method to a function if it does the "same thing" But this only concerns when I'm writing the code myself. If I read some code and I see a few nested function calls, there's a combinatorial explosion of possible types that gives me vertigo. > complex and rational numbers can be constructed using anything that has arithmetic defined. seriously? this does not seem right, it cannot be like that. If I build a complex number out of complex numbers, I expect a regular complex number, not a "doubly complex" number with complex coefficients, akin to a quaternion. Or do you? There is surely some hidden dirty magic to avoid that case.
CapmCrackaWaka 5y ago
It’s a solid combination of performance, easy syntax and flexible environment. A big drawback of Python is that any performant code is actually written in a lower level language, with foreign function calls. That’s not to say that there are no disadvantages to Julia. I personally see Julia as a beefed up, new and improved R.
leephillips 5y ago
If you are doing very high-performance numerical work, your choices¹ are Fortran, C, C++, or Julia. Julia is way more fun to program in than the other choices. Also, it has some properties² that make code re-use and re-combination especially easy. 1 https://www.hpcwire.com/off-the-wire/julia-joins-petaflop-club/ https://www.hpcwire.com/off-the-wire/julia-joins-petaflop-cl... 2 https://arstechnica.com/science/2020/10/the-unreasonable-effectiveness-of-the-julia-programming-language/ https://arstechnica.com/science/2020/10/the-unreasonable-eff...
- notafraudster 5y ago
  What's the argument against using R and dropping into RCpp for very limited tasks? I (helped) write a very widely used R modelling package and while I wasn't doing anything on the numerical side, we seemed to get great performance from this approach -- and workflow-wise it wasn't too dissimilar to 25 years ago where I had to occasionally drop in X86 assembly to speed up C code! (Not a hater of Julia at all, very much think it's a cool language and an increasingly vibrant ecosystem and have been consistently impressed when Julia devs have spoke at events I've attended)
  - _Wintermute 5y ago
    I think the argument is that most R users don't know C++. So Julia avoids the "2 language problem" that you get with modern scientific computing.
  - QuadmasterXLII 5y ago
    I think that's just being clumped in with "Use C++," which he mentioned as an option
    - galangalalgol 5y ago
      and the ffi adds a lot of overhead for granular data. Julia just works fast. My only friction has been offline development, which isn't well supported yet.
  - 5y ago
cbkeller 5y ago
Composability via dispatch-oriented programming, e.g. [1] It also pretty much solved my version of the two-language problem, but that means different things to different people so ymmv. [1] https://www.youtube.com/watch?v=kc9HwsxE1OY https://www.youtube.com/watch?v=kc9HwsxE1OY
axpy906 5y ago
My understanding is that it runs faster than native python and R. That said with Numba and other libraries, see no point.
- NeutralForest 5y ago
  It's easier to write Julia code than to deal with Numba tbh and the ecosystem around Julia makes the code composable which is often not the case if you write Numba code and have to deal with other libraries.
- tfehring 5y ago
  Numba is great for pure functions on primitive types but it breaks down when you need to pass objects around. PyPy is fantastic for single-threaded applications but doesn't play nicely with multiprocessing or distributed computing IME. Numpy helps for stuff you can vectorize, but there's a lot of stuff you can't (or can but shouldn't); it also brings lots of minor inconveniences by virtue of not being a native type - e.g., the code to JSON serialize a `Union[Sequence[float], np.ndarray]` isn't exactly Pythonic.
  - oscardssmith 5y ago
    Also, numpy has about a 100x overhead door small arrays (10 or fewer elements).
- danuker 5y ago
  > runs faster than native python and R That's a bit of an understatement. It's about as fast as C and Rust (ignoring JIT compilation time). https://julialang.org/benchmarks/ https://julialang.org/benchmarks/
- dklend122 5y ago
  Composability, speed, static analysis, type system, abstractions, user defined compiler passes, metaprogramming, ffi, soon static compilation, differentiability and more create an effect that far exceeds numba
duped 5y ago
There really aren't that many languages out there trying to be on the cutting edge of JIT for scientific computing with a great REPL experience. There are a few areas where developers have to prototype in a language like Python or MATLAB to design their systems, generate test data, and even just plot stuff during debugging then rewrite in C/C++ for speed. It's an enormous time sink that is prone to errors, and leads to terrible SWE culture. If Julia can provide both the REPL/debugging experience of a language like Python or MATLAB with a fast enough JIT to use in production it would be an enormous boon to productivity and robustness. There are a few limiting factors but I don't think they're absolute.
coldtea 5y ago
>Why use it, when there are so many other good languages out there with more community/support? Honest question. Such a question seems sort of in bad faith (or loaded), since the selling points of Julia have been hammered time and again on HN and elsewhere, and are prominent on its website. It's a 1 minute search to find them, and if someone is already aware that there's this thing called Julia to the point that they think it's made to be "a big deal", they surely have seen them. So, what could the answer to the question above be? Some objective number that shows Julia is 25.6% better than Java or Rust or R or whatever? But first, who said it's a "big deal"? It's just a language that has some development action, seems some adoption, and secured a modest fundng for its company. That's not some earth shattering hype (if you want to see that, try to read about when Java was introduced. Or, to a much lesser degree, Ada, for that matter). You use a language because you've evaluated it for your needs and agree with the benefits and tradeoffs. Julia is high level and at the same time very fast for numerical computing allowing you to keep a clean codebase that's not a mix of C, C++, Fortran and your "real" language, while still getting most of the speed and easy parallelization. It also has special focus on support for that, for data science, statistics, and science in general. It's also well designed. On the other hand, it has slow startup/load times, incomplete documentation, smaller ecosystem, and several smaller usability issues.
- cbkeller 5y ago
  While you have a valid perspective, the HN guidelines [1] do specifically ask us to assume good faith. [1] https://news.ycombinator.com/newsguidelines.html https://news.ycombinator.com/newsguidelines.html
- exdsq 5y ago
  You assume they've seen the posts about Julia on HN. If you're not interested in PL it's fair to assume they might not click on those posts.
agumonkey 5y ago
kinda tries to make coding like python but running like fortran (without having to resort side-batteries like numpy/scipy) designers seems to have a good amount of PLT knowledge and made good foundations
SatvikBeri 5y ago
We had three big data pipelines written in numpy that we'd spent a lot of time optimizing. Rewriting them in Julia, we were able to get an 8x (serial -> serial), 14x (parallel -> serial), and 28x (parallel -> parallel) speedups respectively – and with clearer, more concise code. The difference is huge.
- xiaodai 5y ago
  did you end up using package compiler as well?
  - SatvikBeri 5y ago
    No, the pipelines are long enough that compilation time isn't a big issue.
ziotom78 5y ago
I am using Julia extensively since 2013, and I can say that it's awesome! But don't try to use it if you're looking for a general-purpose scripting language: Python is far better suited for this. Similarly, if you want to produce standalone executables, C++, Rust, Go or Nim are better. However, Julia is perfect if you write mathematical/physical/engineering simulations and data analysis codes, which is my typical use case. Its support for multiple dispatch and custom operators lets you to write very efficient code without sacrificing readability, which is a big plus. Support for HPC computing is very good too.
- amkkma 5y ago
  >Python is far better suited for this. Similarly, if you want to produce standalone executables, C++, Rust, Go or Nim are better. That's the case now, because Julia made a design decision to focus on extreme composability, dynamism, generic codegen etc which involved compiler tradeoffs...but it's not inherent to the langauge. For scripting, interpreted Julia is coming. For executables, small binary compilation is as well...particularly bullish on this given the new funding
  - ziotom78 5y ago
    Yeah, you are right, these limitations are not much of a matter of the language itself.
  - oxinabox 5y ago
    > For scripting, interpreted Julia is coming. Citation for this? Julia has had a built-in interpretted since 1.0, in 2017 use `--compile=min`, or `--compile=none` to make use of it. And JuliaInterpretter.jl has been working since 2018. Both are very slow -- slower than adding in the compile time for most applications. As I understand it, this is because a number of things in how the language works are predicated on having a optimizing JIT compiler. As is how the standard library and basically all packages are written. Julia is going to over time become nicer for scripting, just because of various improvements. In particular, I put more hope on caching native code than on any new interpreter.

Can someone please explain to me, a mere mortal, what is the big deal with Julia. Why use it, when there are so many other good languages out there with more community/support? Honest question.

RandomWorker 5y ago

Basically, the syntax is similar to matlap as well as lots of the same features around functional and variable deceleration as python. The best thing for sure is the native support for parallel processing. Where python is single tread.

Kranar 5y ago

I think your question presupposes a lot of assumptions that may not be right. For one, I don't know that Julia is like a "big deal", certainly Python is the big deal in this field and I doubt Julia is looking to displace it wholesale. That said, Julia is a great addition to the scientific computing landscape because of its performance compared to other languages and its use of modern programming features. Python is just really really slow compared to Julia and parallelism in Python is a huge pain. Fortran is really really fast but that comes at a cost of being awkward to use and coming with a great deal of baggage. Julia is fast, feels modern, and has pretty easy parallelism. Then there's Matlab, Mathematica, and they are also pretty good but they're closed source/proprietary, so their ecosystem is mostly limited and driven by commercial interests. Nothing wrong with that intrinsically and they're all widely used but it's one way Julia differentiates itself, by making the language open and making money through services.

ChrisRackauckas 5y ago
Julia Computing is not a services company. There are commercial products built off of this stack which are the core of Julia Computing. For example, https://pumas.ai/ https://pumas.ai/ is a product for pharmacology modeling and simulation, and runs on the JuliaHub cloud platform of Julia Computing. It is already a big deal in the industry, with the quote everyone refers to "Pumas has emerged as our 'go-to' tool for most of our analyses in recent months" from the Director Head of Clinical Pharmacology and Pharmacometrics at Moderna Therepeutics during 2020 (for details, see the full approved press release from the Pumas.ai website). JuliaSim is another major product which is being released soon, along with JuliaSPICE publicly in the pipeline. But indeed, Julia Computing differentiates itself from something like MATLAB or Mathematica by leveraging a strong open source community on which these products are developed. These products add a lot of the details that are generally lacking in the open source space, such as strong adherents to file formats, regulatory compliance and validation, GUIs, etc. which are required to take such a product from "this guy can use it" to a fully marketable product usable by non-computational scientists. I will elaborate a bit more on this at JuliaCon next week in my talk on the release of JuliaSim.
- codekilla 5y ago
  Wanted to ask if JuliaDB is something that might get more development attention? Or will that remain a community project? (I see it’s been in need of a release for awhile.)
  - ChrisRackauckas 5y ago
    It is not in our current set of major products. That said, informal office discussions mentioned JuliaDB as recently as last week, so it's not forgotten. If there's a demonstrated market, say a need for new high-performance cloud data science tools as part of the pharmaceutical domains we work in, then something like JuliaDB could possibly be revived in the future (of course, this is no guarantee).
  - ViralBShah 5y ago
    In general, the community has discussed reviving the project (or at least the ideas and some of its codebase). Julia computing will also be contributing as part of that revival.
    - codekilla 5y ago
      Thank you both for the comments. I believe I remember early on there were some comparisons to kdb+/q. I think there is some pretty great potential with an offering like this (an in-memory database integrated with the language, coupled with solid static storage) from the Julia community going forward. I can envision some use cases in genomics/transcriptomics.

nvrspyx 5y ago

From what I understand, Julia is dynamically typed and similar to a scripting language like Python or Ruby, but is also compiled, so it has performance similar to C/C++ (it's also written in itself). It also has built-in support for parallelism, multi threading, GPU compute, and distributed compute. I'm sure others can provide more insight. I've only dabbled in it and haven't used it extensively in any sense of the word.

deleted 5y ago

[deleted]

oscardssmith 5y ago

Short answer is that it is (imo) by far the best language for writing generic and fast math. Multiple dispatch allows you to write math using normal notation and not have to jump through hoops to do so.

enriquto 5y ago
can you show a simple example of that? I tend to see multiple dispatch as a mental burden, (e.g.: when I see a function call, where will it be dispatched? the answer dependa on the types that I'm juggling, that may not even be visible at that point...)
- oscardssmith 5y ago
  The key to make multiple dispatch work well is that you shouldn't have to think about what method gets called. For this to work out, you need to make sure that you only add a method to a function if it does the "same thing" (so don't use >> for printing for example). To Dr the benefit of this in action, consider that in Julia 1im+2//3 (the syntax for sqrt(-1)+2 thirds) works and gives you a complex rational number (2//3+1//1 im). To get this behavior in most other languages, you would have to write special code for complex numbers with rational coefficients, but in Julia this just works since complex and rational numbers can be constructed using anything that has arithmetic defined. This goes all the way up the stack in Julia. You can put these numbers in a matrix, and matrix multiplication will just work, you can plot functions using these numbers, you can do gpu computation with them etc. All of this works (and is fast) because multiple dispatch can pick the right method based on all the argument types.
  - enriquto 5y ago
    > make sure that you only add a method to a function if it does the "same thing" But this only concerns when I'm writing the code myself. If I read some code and I see a few nested function calls, there's a combinatorial explosion of possible types that gives me vertigo. > complex and rational numbers can be constructed using anything that has arithmetic defined. seriously? this does not seem right, it cannot be like that. If I build a complex number out of complex numbers, I expect a regular complex number, not a "doubly complex" number with complex coefficients, akin to a quaternion. Or do you? There is surely some hidden dirty magic to avoid that case.

CapmCrackaWaka 5y ago

It’s a solid combination of performance, easy syntax and flexible environment. A big drawback of Python is that any performant code is actually written in a lower level language, with foreign function calls. That’s not to say that there are no disadvantages to Julia. I personally see Julia as a beefed up, new and improved R.

leephillips 5y ago

If you are doing very high-performance numerical work, your choices¹ are Fortran, C, C++, or Julia. Julia is way more fun to program in than the other choices. Also, it has some properties² that make code re-use and re-combination especially easy. 1 https://www.hpcwire.com/off-the-wire/julia-joins-petaflop-club/ https://www.hpcwire.com/off-the-wire/julia-joins-petaflop-cl... 2 https://arstechnica.com/science/2020/10/the-unreasonable-effectiveness-of-the-julia-programming-language/ https://arstechnica.com/science/2020/10/the-unreasonable-eff...

notafraudster 5y ago
What's the argument against using R and dropping into RCpp for very limited tasks? I (helped) write a very widely used R modelling package and while I wasn't doing anything on the numerical side, we seemed to get great performance from this approach -- and workflow-wise it wasn't too dissimilar to 25 years ago where I had to occasionally drop in X86 assembly to speed up C code! (Not a hater of Julia at all, very much think it's a cool language and an increasingly vibrant ecosystem and have been consistently impressed when Julia devs have spoke at events I've attended)
- _Wintermute 5y ago
  I think the argument is that most R users don't know C++. So Julia avoids the "2 language problem" that you get with modern scientific computing.
- QuadmasterXLII 5y ago
  I think that's just being clumped in with "Use C++," which he mentioned as an option
  - galangalalgol 5y ago
    and the ffi adds a lot of overhead for granular data. Julia just works fast. My only friction has been offline development, which isn't well supported yet.
- 5y ago

cbkeller 5y ago

Composability via dispatch-oriented programming, e.g. [1] It also pretty much solved my version of the two-language problem, but that means different things to different people so ymmv. [1] https://www.youtube.com/watch?v=kc9HwsxE1OY https://www.youtube.com/watch?v=kc9HwsxE1OY

axpy906 5y ago

My understanding is that it runs faster than native python and R. That said with Numba and other libraries, see no point.

NeutralForest 5y ago
It's easier to write Julia code than to deal with Numba tbh and the ecosystem around Julia makes the code composable which is often not the case if you write Numba code and have to deal with other libraries.
tfehring 5y ago
Numba is great for pure functions on primitive types but it breaks down when you need to pass objects around. PyPy is fantastic for single-threaded applications but doesn't play nicely with multiprocessing or distributed computing IME. Numpy helps for stuff you can vectorize, but there's a lot of stuff you can't (or can but shouldn't); it also brings lots of minor inconveniences by virtue of not being a native type - e.g., the code to JSON serialize a `Union[Sequence[float], np.ndarray]` isn't exactly Pythonic.
- oscardssmith 5y ago
  Also, numpy has about a 100x overhead door small arrays (10 or fewer elements).
danuker 5y ago
> runs faster than native python and R That's a bit of an understatement. It's about as fast as C and Rust (ignoring JIT compilation time). https://julialang.org/benchmarks/ https://julialang.org/benchmarks/
dklend122 5y ago
Composability, speed, static analysis, type system, abstractions, user defined compiler passes, metaprogramming, ffi, soon static compilation, differentiability and more create an effect that far exceeds numba

duped 5y ago

There really aren't that many languages out there trying to be on the cutting edge of JIT for scientific computing with a great REPL experience. There are a few areas where developers have to prototype in a language like Python or MATLAB to design their systems, generate test data, and even just plot stuff during debugging then rewrite in C/C++ for speed. It's an enormous time sink that is prone to errors, and leads to terrible SWE culture. If Julia can provide both the REPL/debugging experience of a language like Python or MATLAB with a fast enough JIT to use in production it would be an enormous boon to productivity and robustness. There are a few limiting factors but I don't think they're absolute.

coldtea 5y ago

>Why use it, when there are so many other good languages out there with more community/support? Honest question. Such a question seems sort of in bad faith (or loaded), since the selling points of Julia have been hammered time and again on HN and elsewhere, and are prominent on its website. It's a 1 minute search to find them, and if someone is already aware that there's this thing called Julia to the point that they think it's made to be "a big deal", they surely have seen them. So, what could the answer to the question above be? Some objective number that shows Julia is 25.6% better than Java or Rust or R or whatever? But first, who said it's a "big deal"? It's just a language that has some development action, seems some adoption, and secured a modest fundng for its company. That's not some earth shattering hype (if you want to see that, try to read about when Java was introduced. Or, to a much lesser degree, Ada, for that matter). You use a language because you've evaluated it for your needs and agree with the benefits and tradeoffs. Julia is high level and at the same time very fast for numerical computing allowing you to keep a clean codebase that's not a mix of C, C++, Fortran and your "real" language, while still getting most of the speed and easy parallelization. It also has special focus on support for that, for data science, statistics, and science in general. It's also well designed. On the other hand, it has slow startup/load times, incomplete documentation, smaller ecosystem, and several smaller usability issues.

cbkeller 5y ago
While you have a valid perspective, the HN guidelines [1] do specifically ask us to assume good faith. [1] https://news.ycombinator.com/newsguidelines.html https://news.ycombinator.com/newsguidelines.html
exdsq 5y ago
You assume they've seen the posts about Julia on HN. If you're not interested in PL it's fair to assume they might not click on those posts.

agumonkey 5y ago

kinda tries to make coding like python but running like fortran (without having to resort side-batteries like numpy/scipy) designers seems to have a good amount of PLT knowledge and made good foundations

SatvikBeri 5y ago

We had three big data pipelines written in numpy that we'd spent a lot of time optimizing. Rewriting them in Julia, we were able to get an 8x (serial -> serial), 14x (parallel -> serial), and 28x (parallel -> parallel) speedups respectively – and with clearer, more concise code. The difference is huge.

xiaodai 5y ago
did you end up using package compiler as well?
- SatvikBeri 5y ago
  No, the pipelines are long enough that compilation time isn't a big issue.

ziotom78 5y ago

I am using Julia extensively since 2013, and I can say that it's awesome! But don't try to use it if you're looking for a general-purpose scripting language: Python is far better suited for this. Similarly, if you want to produce standalone executables, C++, Rust, Go or Nim are better. However, Julia is perfect if you write mathematical/physical/engineering simulations and data analysis codes, which is my typical use case. Its support for multiple dispatch and custom operators lets you to write very efficient code without sacrificing readability, which is a big plus. Support for HPC computing is very good too.

amkkma 5y ago
>Python is far better suited for this. Similarly, if you want to produce standalone executables, C++, Rust, Go or Nim are better. That's the case now, because Julia made a design decision to focus on extreme composability, dynamism, generic codegen etc which involved compiler tradeoffs...but it's not inherent to the langauge. For scripting, interpreted Julia is coming. For executables, small binary compilation is as well...particularly bullish on this given the new funding
- ziotom78 5y ago
  Yeah, you are right, these limitations are not much of a matter of the language itself.
- oxinabox 5y ago
  > For scripting, interpreted Julia is coming. Citation for this? Julia has had a built-in interpretted since 1.0, in 2017 use `--compile=min`, or `--compile=none` to make use of it. And JuliaInterpretter.jl has been working since 2018. Both are very slow -- slower than adding in the compile time for most applications. As I understand it, this is because a number of things in how the language works are predicated on having a optimizing JIT compiler. As is how the standard library and basically all packages are written. Julia is going to over time become nicer for scripting, just because of various improvements. In particular, I put more hope on caching native code than on any new interpreter.