4 ms·

Rust & Go are ver close to Julia. Maybe a bit of code optimization would speed them up ahead of Julia? But regardless, from LTS aspect, Rust and Go maybe the w

Rust & Go are ver close to Julia. Maybe a bit of code optimization would speed them up ahead of Julia? But regardless, from LTS aspect, Rust and Go maybe the way to go

fullstackchris 3y ago
Is Julia bad for LTS? Is it something like no reverse compatibility? Genuine question; I've never used it before.
- borodi 3y ago
  Julia follows semver, so code written in 1.0 should work on the latest release (packages notwithstanding)
- IshKebab 3y ago
  No he meant long term support as in, is Julia still going to be remotely popular in 10 years time? Go and Rust are both hugely popular and definitely will be around for decades. Julia? Debatable.
wjholden 3y ago
Another post here indicated that these times don't include startup costs. From my experience with Julia (and I love Julia and have used it extensively at school!), the "time to first plot" thing is still a big problem. You would never want to write shell scripts in Julia, mostly because it takes several seconds to get the interpreter running.
- sundarurfriend 3y ago
  Just to add some nuance: > From my experience with Julia (and I love Julia and have used it extensively at school!), the "time to first plot" thing is still a big problem. This part is true - it has improved by an order of magnitude in recent versions and continues to, but time-to-first-X is still a tangible issue you have to deal with. > You would never want to write shell scripts in Julia, mostly because it takes several seconds to get the interpreter running. This part overstates the case - it takes less than half a second for the Julia runtime to start, even on my mediocre laptop. Which isn't nothing, to be sure, and maybe a non-starter for some use cases. But generally, for shell script like programs, the time taken by the runtime (the "interpreter", though it's not really one) itself isn't much of an issue. The delays come in when your code needs to load big packages to do its thing, their loading times and other time-to-first costs. And you can mitigate that too, by putting the main part of your code in a precompiled package, and just calling out to that from your script. All that is to say only that, in the past few years, Julia has gone from "you would never want to write shell scripts in Julia" to "it's mildly annoying that you have to consciously arrange your code in a certain way to avoid latencies, but it's doable and not too hard".

Rust & Go are ver close to Julia. Maybe a bit of code optimization would speed them up ahead of Julia? But regardless, from LTS aspect, Rust and Go maybe the way to go

fullstackchris 3y ago

Is Julia bad for LTS? Is it something like no reverse compatibility? Genuine question; I've never used it before.

borodi 3y ago
Julia follows semver, so code written in 1.0 should work on the latest release (packages notwithstanding)
IshKebab 3y ago
No he meant long term support as in, is Julia still going to be remotely popular in 10 years time? Go and Rust are both hugely popular and definitely will be around for decades. Julia? Debatable.

wjholden 3y ago

Another post here indicated that these times don't include startup costs. From my experience with Julia (and I love Julia and have used it extensively at school!), the "time to first plot" thing is still a big problem. You would never want to write shell scripts in Julia, mostly because it takes several seconds to get the interpreter running.

sundarurfriend 3y ago
Just to add some nuance: > From my experience with Julia (and I love Julia and have used it extensively at school!), the "time to first plot" thing is still a big problem. This part is true - it has improved by an order of magnitude in recent versions and continues to, but time-to-first-X is still a tangible issue you have to deal with. > You would never want to write shell scripts in Julia, mostly because it takes several seconds to get the interpreter running. This part overstates the case - it takes less than half a second for the Julia runtime to start, even on my mediocre laptop. Which isn't nothing, to be sure, and maybe a non-starter for some use cases. But generally, for shell script like programs, the time taken by the runtime (the "interpreter", though it's not really one) itself isn't much of an issue. The delays come in when your code needs to load big packages to do its thing, their loading times and other time-to-first costs. And you can mitigate that too, by putting the main part of your code in a precompiled package, and just calling out to that from your script. All that is to say only that, in the past few years, Julia has gone from "you would never want to write shell scripts in Julia" to "it's mildly annoying that you have to consciously arrange your code in a certain way to avoid latencies, but it's doable and not too hard".