6 ms·

It seems instant to me - the package compile on first invocation is rather like installing with pip or conda, and then after that I see the plot in about 1/20th

by sgt101 3y ago

It seems instant to me - the package compile on first invocation is rather like installing with pip or conda, and then after that I see the plot in about 1/20th second.

leephillips 3y ago
The REPL starts up instantly and the first plot is < 1s. People seem to be repeating complaints (valid at the time) that they overheard from three years ago.
- jampekka 3y ago
  This is not the complaint. The complaint is that running "$ julia someplotting.jl" takes a long time (actually with 1.9.0 it's reasonable at < 3s, but adding other libraries makes it easily tens of seconds or even minutes). Everybody doesn't use the REPL. In my, I think quite well founded, opinion nobody should use the REPL for more than one or two lines.
  - sanderjd 3y ago
    For what it's worth, as someone who shares a sense that "scientific" programmers have a tendency to over-use notebooks and REPLs, I find your perspective on it to be too extreme in the other direction! It's perfectly possible to incorporate interactive tools into a good software development process.
    - jampekka 3y ago
      I don't mean that running in Bash should be THE workflow. But I think it should be supported and it's used widely and lack of support for it is a major reason why Julia is not taking off. I'm not proposing taking REPL/stateful-notebook away from those who want to use it (although I'll advise them against it if asked). I don't find my plt.plot(x,y); plt.show() in a script ideal either. Something like Pluto.jl (given it's easy to modularize and preferably can be run without a notebook environment) is most likely better for a typical data analysis workflow (and will likely lead to more reproducible results and better tracking of result provenance).
      - sanderjd 3y ago
        But there isn't "lack of support" for running cli scripts, there's just a few seconds of startup time (or less than that; it depends a lot on what dependencies the project has, in my experience). Like, I don't want to diminish that this amount of latency matters, but I just feel like you're being hyperbolic. I've used tools with more startup time for most of my career - the jvm, ruby when running any non-trivial rails app, essentially every ahead-of-time compiled language, etc. - it's not a good thing, and all those tools have invested massively in improving their startup times because of that, but I just really don't see how it can be considered a deal-breaker... (And for what it's worth, most non-trivial python codebases I work with also spend a ton of time starting up, though this can be fixed with investment into it.)
        jampekka 3y ago
        Especially for data analysis the latency is crucial. I run the code practically on every time I change a line. It's not that different from how people run REPLs, but I just keep the lines in files that I run. Would people be just fine if each REPL line would have tens of seconds of latency overhead? For different cases, e.g. application development, the latency is not that critical. Although I find it quite insane that we accept so slow code iterations this day and age.
        sanderjd 3y ago
        Again, I'm not trying to downplay how much it matters, I just think you're being pretty hyperbolic about it! You've said stuff like it's "impossible" and "not supported", and I think these are just way stronger than "very inconvenient" or "extremely frustrating". Maybe it's a minor point, I dunno, but like, if we were talking about a five minute compile cycle or a language that doesn't even have a way to run a script at the command line, then sure, I'd agree with what you're saying, but as it is, it just feels a bit like a tempest in a teapot to me...
        ChrisRackauckas 3y ago
        Indeed it's something in the middle. For data analysis, many people are used to using RStudio and just keeping a running REPL going, and Julia works quite well for these kinds of tasks in the same mode because that effectively removes the startup time from being a concern. However, there are some folks that are used to other workflows and we could grow the audience by improving the ability to support such workflows better.

by sgt101 3y ago

It seems instant to me - the package compile on first invocation is rather like installing with pip or conda, and then after that I see the plot in about 1/20th second.

leephillips 3y ago

The REPL starts up instantly and the first plot is < 1s. People seem to be repeating complaints (valid at the time) that they overheard from three years ago.

jampekka 3y ago
This is not the complaint. The complaint is that running "$ julia someplotting.jl" takes a long time (actually with 1.9.0 it's reasonable at < 3s, but adding other libraries makes it easily tens of seconds or even minutes). Everybody doesn't use the REPL. In my, I think quite well founded, opinion nobody should use the REPL for more than one or two lines.
- sanderjd 3y ago
  For what it's worth, as someone who shares a sense that "scientific" programmers have a tendency to over-use notebooks and REPLs, I find your perspective on it to be too extreme in the other direction! It's perfectly possible to incorporate interactive tools into a good software development process.
  - jampekka 3y ago
    I don't mean that running in Bash should be THE workflow. But I think it should be supported and it's used widely and lack of support for it is a major reason why Julia is not taking off. I'm not proposing taking REPL/stateful-notebook away from those who want to use it (although I'll advise them against it if asked). I don't find my plt.plot(x,y); plt.show() in a script ideal either. Something like Pluto.jl (given it's easy to modularize and preferably can be run without a notebook environment) is most likely better for a typical data analysis workflow (and will likely lead to more reproducible results and better tracking of result provenance).
    - sanderjd 3y ago
      But there isn't "lack of support" for running cli scripts, there's just a few seconds of startup time (or less than that; it depends a lot on what dependencies the project has, in my experience). Like, I don't want to diminish that this amount of latency matters, but I just feel like you're being hyperbolic. I've used tools with more startup time for most of my career - the jvm, ruby when running any non-trivial rails app, essentially every ahead-of-time compiled language, etc. - it's not a good thing, and all those tools have invested massively in improving their startup times because of that, but I just really don't see how it can be considered a deal-breaker... (And for what it's worth, most non-trivial python codebases I work with also spend a ton of time starting up, though this can be fixed with investment into it.)
      - jampekka 3y ago
        Especially for data analysis the latency is crucial. I run the code practically on every time I change a line. It's not that different from how people run REPLs, but I just keep the lines in files that I run. Would people be just fine if each REPL line would have tens of seconds of latency overhead? For different cases, e.g. application development, the latency is not that critical. Although I find it quite insane that we accept so slow code iterations this day and age.
        sanderjd 3y ago
        Again, I'm not trying to downplay how much it matters, I just think you're being pretty hyperbolic about it! You've said stuff like it's "impossible" and "not supported", and I think these are just way stronger than "very inconvenient" or "extremely frustrating". Maybe it's a minor point, I dunno, but like, if we were talking about a five minute compile cycle or a language that doesn't even have a way to run a script at the command line, then sure, I'd agree with what you're saying, but as it is, it just feels a bit like a tempest in a teapot to me...
        ChrisRackauckas 3y ago
        Indeed it's something in the middle. For data analysis, many people are used to using RStudio and just keeping a running REPL going, and Julia works quite well for these kinds of tasks in the same mode because that effectively removes the startup time from being a concern. However, there are some folks that are used to other workflows and we could grow the audience by improving the ability to support such workflows better.