Julia 1.6 addresses latency issues
lwn.net
lwn.net
Things that kind of suck about using Julia for production:
1. Never could get Revise to work, had to restart my REPL everytime I changed any code. Even though Julia 1.6 was a lot faster than 1.5, it still took too long.
2. Couldn't find a static type checker that actually worked (I tried JET and StaticLint). I feel like static typing is just so important for a production system, but of course the community isn't really interested because of the research focus.
3. Editor tooling. The LSP server absolutely sucks. I first tried using it with emacs (both lsp-mode and eglot mode), but it would crash constantly. I think switched to VSCode (much to my chagrin), and that worked marginally better though still very poorly. It was clear that the LSP server had no idea what was going on in my macro heavy code. It couldn't jump to definitions or usages much of the time. It could never correctly determine whether a variable was unused or misspelled either. Coupled with the lack of static type checking, this was extremely frustrating.
4. Never felt like the community could answer any of my questions. If you have some research or stats question, they were great, but anything else, forget about it.
Will all of that being said, I do still use Julia for research and I find it works really well. The language is very nicely designed.
All and all, I decided to ditch Julia and decided to go with Rust (after some consideration of OCaml, but unfortunately the multi-core story still isn't there yet) and am a lot happier.
This means there is an upper bound to how good the editing and refactoring tooling will be. I suspect the best will be a little below Pythong's tooling, because Python's class helps in disambiguating methods.
One feature of Julia I think could be improved upon is the `include` statement to import code, similar to C's `include` macro directive. This makes finding functions within a package an absolute nightmare. I think this also restricts LSP's ability to find definition and usage since this tends to make Julia packages one big source file as far as the compiler is concerned. I saw that in Julia's compiler code, the core developers include C source files, not header files mind you, in other C source files, so perhaps the feature stems from their personal preference. Python's file-module may be too restricting, but Julia's including is too loose.
I feel that most of your points can be addressed if the compiler's "abstract interpreter" (static analysis) procedures were exposed and reliable/stable. Some packages (e.g. Mjolnir.jl [0]) attempt to re-implement it. Others (e.g. JET.jl [1]) try to hook into Julia's undocumented/private compiler internals (CoreCompiler). Rightfully so, only the most intrepid are willing to do this.
I've ranted about very similar things for some time now, and had some fruitful discussions, and I even offered to help to try to scratch some of the itches me and others are suffering from. I've now mostly given up too.
It's a bit sad for me. I think Julia has many things right and the core concepts are potentially revolutionary. But for me it seems that Julia ecosystem is a bit too jealous of their discovery to let it free. Weird.
https://discourse.julialang.org/t/why-no-base-iterators-map/...
The "bubble effect" here was assumption that everyone has internet access and dependencies to external ( community maintained ) packages are zero cost.
Happily 2 years later this was resolved to my satisfaction.
I'm a researcher but I have a background in software development, and especially open source. Academia is way behind software in openness, which is rather bizarre as the institutional role of academia is usually seen as providing new ideas and challenging old thinking so the community can prosper. There's some kind of a bug in the current academic culture that causes it to freeze up when it should fulfill its promise to share its findings with the world.
Probably a good way to debug this thing is to follow the money and why on earth do we have these weird hats and robes?
Julia's optimal sorts of workflows are different than many expect — especially for folks coming from static languages. Julia is a dynamic language. But also, Julia isn't Python. There are ways in which your workflows from other languages just aren't optimal in Julia. So when someone comes in "hot" and rants about how their workflow isn't working out how they expect, others jump in and — yes, defensively at times — point out alternatives that work for them.
I think some of this tension comes from an expectation mismatch. Some of the changes noted in these comments about how Julia is presented on julialang.org were made specifically due to this sort of expectation mismatch.
This doesn't mean that nobody in the community cares about improving workflows — in fact I know that's not true. But if you want to use Julia today, there are definitely some happy paths that we should guide folks towards.
And that's exactly what I've seen over and over again, in different communities, such as the ones I've mentioned, this attitude of "you're holding it wrong".
No language or tool can be everything to everybody, that's perfectly reasonable. If the goal of Julia is different from that of people that want to run applications in production—or at least those concerns aren't the most important ones—fair enough. But all too often (and I'm not necessarily talking about Julia here; I haven't spent enough time on the Julia forums, I'm mostly referring to some of the other examples I've cited) real concerns are just dismissed out of hand.
I also don't believe that enforcing certain very specific workflows at the exclusion of any others is necessarily a great way to become a language that lots of people want to use. People come from different backgrounds and have different preferences and needs (sometimes for very good reasons), successful languages like Python recognise this and let you work with a wide range of tools.
Finally, I'm just very skeptical about a certain kind of NIH syndrome that I've seen in some of these communities, something like "encapsulation? well, all these other languages might need it, but we actually don't, because XYZ" or similar things.
You're really reading this wrong. The issue is moreso about personal knowledge. I see this on the Discourse sometimes where someone comes blazing in saying "I want to use PyCharm for Julia and I run into ...", "Special Lisp-only IDE has a Julia plugin and it fails because ...", or "I have this special terminal setup and I no 0 latency and ...". The answer of course is, if you need help, use VS Code or Juno/Atom. Those have a larger userbase which that has fixed exactly those issues and has a helpful dev community on those site which will get you up and running. That's not "you're holding it wrong", that's people trying to help you into an area where they know how to help you. You can shrug it all off and blame it on them, but at the end of the day, people are sharing what they know works, a reliable solution they built for exactly this problem, and then are getting flamed on the internet for having "NIH syndrome" for not fixing some random IDE plugin they've never used. I just don't see how you can expect every person to be an expert on every possible workflow you can imagine and start throwing flame when someone tries to lead you to water.
In the Julia community in particular you tend to have people who are more experts in their scientific domains. I am in that category: I can help you in anything ML, high performance computing, differential equations, etc. but I use Windows and the Juno IDE. If you open an issue about something weird happening on emacs, I wouldn't even know how to get it installed, sorry, that's not my expertise. The Julia community has a lot more people in probabilistic programming than it has Javascript devs, and so people share how they know how to fix your problem "can you run it in VS Code and show the profile?", not "here's how to run some daemon server thing" etc. And that's perfectly fine, it has its advantages and disadvantages.
And yes, that destination does include production.
Julia is hard to debug as is (and this is fully acceptable to me due to the architecture) and these hacks on hacks make it just impossible.
Julia suffers from the same "fancy calculator" approach than e.g. R and Matlab, and like those, they refuse to take note of the decades of experience in software development that this just leads to a total mess if you have anything more complicated than a one-off analysis. It's like insisting on editing files with ed because that's how it's always been done.
I think your view of Julia as a "fancy calculator" may be part and parcel to the difficulty. I do use it as a fancy calculator, but I also use local packages all the time — and that's where you'll find the best success in both tooling and code structure for sustainable (and modern) development. We need to do a better job of helping folks more effectively develop and work with Julia before it becomes frustrating.
My view is that Julia (and R and Matlab etc) ecosystem's view is a "fancy calculator". It's hard to integrate to anything else, it almost actively tries to make e.g. unix-type workflow difficult (not much CLI, everything done in REPL, e.g. package management). Not as bad as e.g. R where its almost impossible to just run a file of code instead of doing a "workflow session".
Perhaps there is some disconnect in how different parties of the discussion see the whole thing. For me this sounds a lot like "you're holding it wrong". What background are you coming from and what languages/programming environments you are familiar with? I get the impression that you don't have much general purpose programming background and somehow tend to assume that people are using "wrong workflows" due to being just stupid or something. But this is how it comes off to me, I think you mean something else, but I don't know what that is.
My approach is: I want files with code and I want to run some of those with some kind of entry point. And preferably organize it to files or something like that. This is the usual setup for general purpose programming languages. In general purpose programming you rarely tend to stick solely to one language, any larger project is usually a mishmash of different stuff, e.g. glue code in python, tight loops in C, maybe some bash thrown around to do some more trivial chores.
This is the overall structure of practically all general purpose programming languages. This requires interfacing with these languages (often done in bash or something in unixy systems at least) and tools that work regardless of language (e.g. version control, grepping, Make etc). Julia (and R and Matlab etc) just plain refuse to even consider this as a valid approach. If you mention it somewhere, you tend to get some bizarre instant putdowns that provide no real rationale, i.e. "you're just holding it wrong".
In programming I tend to think the whole computer and its OS and so on as the programming tool. My impression is that for Julia folks Julia is something totally separate from anything else in the computer. But I don't understand why. Is it that its felt that changing syntax on the fly is too cognitively demanding or something? This is something that one gets used to very fast. And also tends to ease the IMHO weird hung-ups on syntax. In fact, I think Julia has made some (IMHO misguided) syntactic decisions because they just want to do something differently from Python just for the sake of being different. I find this totally senseless.
Us CLI folks are not even asking for much. Just a way to call a program with arguments and so that you don't have to do compile identical code every time you do something. That's it. Is that unreasonable? It wouldn't take anything away from people using REPLs and Notebooks. We don't want to change the language, the language is fine and that's why we'd like to use it but just cant because these paper cuts!
I've expanded on my rationale for my workflow and how Julia makes it really difficult e.g. here, where I admittedly started with too strong wordings out of frustration: https://news.ycombinator.com/item?id=26134970
No, you're not stupid. You've correctly identified current flaws in the tools, and the community tries to lead you to the tools that are known to work well in spite of the issues. We need to work a little bit more on the other tools to make them as good, but large parts of the community are just not the right people to work on that problem. It's not a design problem, it's fixable, but you just have more people who know how to make new differential equation solvers than you have people who can compile a binary, so the tooling ecosystem moves at a different pace from the scientific packages. This is changing with the help of some commercialization aspects though, but it is something we have to be cognizant of.
The world is bigger than you.
There is no need to insult people around.
I totally get that there are workflows that Julia is inappropriate for, but when someone says that a tool shouldn't be released because it doesn't target their workflow, I really don't know what to call that other than blindingly self centred.
More seriously though, just because some language may be considered "general purpose" doesn't mean it's the best language for everything, or should replace other languages outside of whichever particular applications where it excels.
No I don't. It needs some work in some places.
Look, everyone wants static compilation, and it's almost certainly going to happen eventually. It's not unreasonable at all to want that. The only thing that would be unreasonable is to (apparently repeatedly!) imply or assert that this lack of static compilation (and/or better caching) is due to some bizarre perversion on the part of the community.
If you want it to happen faster, then stop complaining about it on HN, get familiar with the current attempts at true static compilation in e.g. https://github.com/tshort/StaticCompiler.jl/pull/46 and start contributing yourself.
I like the "AOT-JIT" approach of Julia, and I think a separate compilation step is quite a stupid idea in the first place. I see it as some historical relic from computers with extremely limited memory (by current standards) and outdated business models that want obfuscated binaries.
My main gripe is just that I have to do it every time I run anything if I'm not using a REPL/Notebook, which drive me insane with their inconsistent and opaque global state. This could be solved mostly by caching the compilation results and compiling new stuff incrementally. But I'm starting to lose any hope that this is gonna actually happen.
Some lesser stuff follows from lack of this, but they should be relatively easily fixed.
For what it's worth, I've seen some nasty (though well meaning) pile-ons in the julia discourse, but for the most part it's a pretty nice place. I find though that the Zulip [2] and Slack communities are generally more friendly and relaxes places though.
1) I use VScode and have had 0 problems with Revise. It Just Works when using the Julia extension + built in REPL. I actually prefer the Julia environment to Python in VScode, I have way fewer problems when doing a Notebook-like workflow where I’m writing library code at the same time
2) Agreed, I also wish there was a better story here. I’m constantly frustrated by how little static support there is. It’s getting better though, eg precompilation in 1.6.
3) I haven’t had any issues here outside of the occasional update to VScode Julia extension that botches things
4) I’ve had quite a lot of luck on discourse and GitHub issues, as well as slack for the occasional small question
Rust is great for use cases where you have specific resource management needs, although seems an odd choice for general purpose scientific computing.
Try changing a struct.
Until then, consider this work-around: https://github.com/BeastyBlacksmith/ProtoStructs.jl
Not sure if you can generalize it to "Julia community isn't interested".
If we have more ppl liking Julia and using it for general purpose computing (which it is capable of), then more of these tools will become mature overtime.
Also, Julia is not in the same niche as Rust though, it's more like a Python, so not sure if the comparison is apt.
5. The module system is very primitive.
6. The testing framework is extremely barebones.
I agree with your assessment, Julia is great for crunching numbers etc., but I wouldn't write a whole application in it.
[1]: I actually tried to automate some of this in a project: https://gitlab.com/pfrasa/morcrypto/-/blob/master/test/runte...
In general though, specific issues with use-cases (or even better PRs) are the best way to direct change in an open source language. It's much easier to prioritize development if we know that a specific feature is wanted.
You know, maybe you're right and I can't prove you wrong, but this is the kind of thing that IMHO application developers read and think "yeah no, been there, done that, never again". Because many people's experience is that names do clash, again, and again, and again, and I fail to see why multimethods should solve that.
[1] https://docs.julialang.org/en/v1/manual/style-guide/#Avoid-t...
https://clojure.org/about/spec
You can compare and contrast MLDatasets.jl (uses submodule per dataset) vs CorpusLoaders.jl (uses a extra type argument per dataset)
It is supposed to land in the release after 4.13, which is the next one.
Regarding the scientific computations library there is Owl[1][2] which now has an almost finished book[3].
I have been using Julia 1.6 since the release, and I'm so grateful not only that some computations run a bit faster, but that the interactivity is so improved.
Even seeing a progress bar can help me stay focused, because it can be fun to watch (parallel precompilation is especially fun). When a command just hangs, I feel left in the dark about how much boredom I'll have to endure.
Kinda like mirrors in waiting areas, I wonder whether judicious logging messages about the compilation process (not a wall of text, but just enough) will serve to keep users engaged while also educating them about the compilation happening on the backend. That will help users feel more agency, and also improve their mental models of how to structure their code/activity for faster compilation.
Sometimes it would be enough to just google what the long task does and see "oh wait I don't actually need that step for my daily development" (e.g. resource crunching, crash reporting initalization etc) or point you in the direction of "why isn't this caching itself".
Quite a useful thing, and should be available as an option at least. In a REPL it might be context noise, but should still be there as a --verbose option.
I have very little tolerance for latency in my tools. It's one of the top deciding factors for me when choosing which tools to use. It's that important.
You should consider your self lucky when I started the compile link process took a while and that is assuming you had real time access.
I recall one of my colleagues who was running her code on an ICL at AWE (Underwater Weapons Establishment) coming into the terminal room logging in and sighing "48 jobs in GEORGE ahead of hers.
A year later we brought a Pr1me Super Mini which made things a lot faster.
Julia's time to first plot still has some problems. The Plots library can build animations, but the time to first animation on my computer is like 10 minutes, and the time to second animation is another 10 minutes. Probably just a bug, I haven't found any other case that takes so long.
I've also mentioned before that a reinforcement learning algorithm I ported from Python/PyTorch to Flux was faster, not because of training times, but because of all the other stuff (and RL has more "other stuff" than supervised learning) that goes on outside the core training loop is so much faster.
Sometimes, a function really is performance critical so you spend a ton of time fiddling with it to make it blazing fast, other times you write something non-optimal but straightforward. It's all the same language though, and unlike tools like Cython, you don't lose all your nice high level language features when you drop down to 'high performance julia code'.
Oof. I reread this several times consecutively as "I've implemented the board game in Go, Python, Rust ...".
"Closer to Rust than to Python" is a wide range. Almost any non-scripting language (e.g. Java, OCaml, Haskell, Dylan...) would qualify, and that's normally not enough to give them a reputation as "fast".
One could say the same for any of the languages I listed (maybe not "much simpler code" in the case of Java).
For string processing and other gc heavy code, Julia has further to go. Julia's gc is pretty basic, and needs a lot of love. That said, for dataframes like workloads, Julia usually manages to hand with the best (data.table), and it's rarely much slower.
Expressiveness is hard to judge objectively, but in my opinion at least, Multiple Dispatch is a massive win for writing composable, re-usable code, and there really isn't anything that compares on that front to Julia.
That seems to be very Julia-specific comparisons, which I'm sure will be oriented towards the use cases Julia has been designed for. I'm more interested in "neutral" benchmarks and more general-purpose computing areas.
> Furthermore, Julia has been used on some of the world's fastest super-computers (in the performance critical bits), which as far as I know isn't true of Swift/Kotlin/C#.
That's more a reflection of culture than performance though. Back when I worked with a bunch of data scientists they would happily run Python or R on our Spark cluster, consuming oodles of resources to do not very much, but balked at writing Scala, even though their code would have run much faster.
As a general purpose language, I'd probably categorize Julia as fast, but not crazy fast. Numerical computing is definitely where most of the man hours have gone into development. As a general purpose language, Julia probably ends up at around the same place as C# (not as fast as C++, but still pretty respectable). That said, this is an area where the main thing Julia needs here is more optimization on some of the libraries that already exist, and some new libraries to extend the language's reach further. I don't think there's anything fundamental holding it back from getting closer to C++ performance in general computing. It uses the same compiler (LLVM), and it's pretty clear that you can get Julia to output the same assembly code. It's just a matter of having enough devs pushing ecosystem forward.
Is there any effort to include Julia in the TechEmpower Benchmarks? If it's trying to be a general-purpose language, that's the first place I'd look.
Have you tried 1.6 already? I find it's substantially faster.
And by extension, it seems weird to me to complain that Julia is not a general purpose language because it can not generate binaries. What stops me from making the same statement about python, which is definitely general purpose?
That depends on the use case. With improvements in static compilation, julia could probably be a good application language. Game development would be an interesting market.
I think this is the case for at least the most popular JIT'd languages: Java, C#, JS, and PHP. Also for the most popular interpreted languages: Python, Ruby and also PHP. I don't know about Visual Basic and R though.
I know that an exception is Dart, that combines a JIT and an AOT. I think EmacsLisp can now be also compiled, but I don't know if it works with all the code and is just free performance, or something more limited.
Edit: as pointed at by pjmlp, Java and C# already combine an AOT and a JIT. What I meant by the comment on Dart is that it can either be run with a VM or compiled to produce binaries.
Other examples are Lisp and Scheme variants, Eiffel, OCaml, Haskell, Prolog.
Not that many places use Java/C# AOT compilation, except for games/iOS apps.
Almost every place I've seen using Java/C# was using JIT.
As for not everything being supported, well that is no different from having C++ code with RTTI and exceptions disabled, or being forced into a specific linking model due to possible problems with a third party dependency.
Is is still plain old Java/Kotlin/C++ as usual.
Press should be better informed, but that is asking too much in modern times.
I might have a counter example: Common Lisp (a compiled language) can be run from sources as a script (like interpreted-ish languages) and we can build self-contained binaries. With SBCL they weight ±20MB minimum (proprietary implementations do tree shaking) and they start instantly.
I agree that generating binaries don't make a language general purpose, I just tried to give an exemple of an ad hoc non scientific thing that is considered "important" to the community (its an official project) that is stuck. The common sense would be just list the web frameworks but I dont think its fair simply because there is no interest on it (yet).
1) querying a time series database of systems metrics at scale for (large) fleets. This is being done via a JSON API. Directly in Julia.
2) Creating data frames from these queries, and performing fleet wide analytics. Quickly. Millions to hundreds of millions of rows in the data frames, typically 4-20 columns. Directly in Julia, no appeal to a 2nd language.
3) leveraging the power of the language to post process these data sets before analysis, to remove an "optimization" that reduced data quality.
4) operate quickly on gigabytes of queried data, threading and sharding my requests, as the server can't handle large requests, but it can handle parallel ones. Poor design, but I can work around it ... trivially ... with Julia
5) creating jupyter lab notebooks for simple consumption of these more complex data sets by wider audiences, complete with plots, and other things.
No science done here ... well ... data science maybe ... and this is specifically in support of business analytics, process optimization, etc.
Julia is an excellent language for this, 10 out of 10, would recommend.
Python is famously bad at this. I hope Julia's proponents don't stop at "look we're only as bad as Python".
A sibling comment made a point about "compiling down to shared libraries" which seems similar to what you are describing, but that seems like it has little to do with "the two language problem".
I love Julia. Which is why it's so painful that I have to rewrite all my elegant Julia prototype code in C++, so I can compile into a shared lib for the users. Every. Single. Time. Two languages.
Now that it isn't the main front and centre claim, I feel a bit less bitter about using it as a prototyping language.
Waiting another 5 years and maybe it really will solve the two-language problem.
Anyways, I'm glad I did invest in learning Julia. Just disappointed it didn't save me from C++. On to Rust!
Common Lisp was also designed to be compiled. Most implementations these days compile to machine code. Compilation is incremental, but ahead-of-time. That means you can start running your program without having yet compiled all the features or libraries you want. You can—while you’re in the REPL or even while your program is running—compile and load extra libraries later. Compilation is cached across sessions, so you won’t ever have to recompile something that doesn’t change.
Despite Lisp being mega-interactive, incremental, and dynamic, just about every implementation of Lisp allows you to just write out a compiled binary. In the implementation called “Steel Bank Common Lisp” (SBCL), from the REPL, you just write:
(sb-ext:save-lisp-and-die "mycoolprog" :executable t :entry-point 'main)
Unless you’ve specifically programmed it in, there will be no JIT lag, no runtime compilation, etc. It will all just be compiled machine code running at the speed of your processor. (It’s possible and even easy to invoke the compiler at run-time, even in your static binary, which people rarely do, and when they do, they know exactly what they’re doing and why.)
All of this is a complete non-issue in Lisp, and hasn’t been for about 35 years (or more).
./mycoolprog
The binary itself isn’t structured like a typical one with C debugging symbols, etc. But it’s also not some “faux binary” like a bunch of .pyc bundled as data and unzipped when the program runs. It truly is machine code, just arranged differently than a bunch of C ABI functions.
I claim most people running binaries don’t care about the memory layout of the binary. I certainly am never thinking about that every time I run `grep`. You don’t debug Lisp programs with C’s tooling. You use Lisp’s tooling.
(Unless, of course, you use an implementation like Embeddable Common Lisp, which does compile your Lisp program as a C program, and does produce a non-image-based executable. That’s the beauty of Lisp being a standardized language with multiple conforming implementations.)
http://www.lispworks.com/documentation/lw71/DV/html/delivery... https://franz.com/support/documentation/current/doc/dll.htm
Unfortunately none of the FOSS implementations have this ability (to my knowledge). There is nothing inherently in Common Lisp that mandates the "core dump" delivery model.
https://github.com/sharplispers/cormanlisp/blob/master/docum...
In the context of Javascript, V8 did the opposite. Originally they had a baseline compiler for Javascript but now they use an interpreter, which reduces the startup latency.
Solved via flags to disable JIT and brought it down to a couple of secs. Native binary would be much nicer.
It wouldn't be so bad if the Julia developers acknowledged that this is a valid concern (that they are not dealing with it right now for whatever reasons) and that the ecosystem will not be considered complete until this fundamental problem is solved. But this is infuriatingly not the case. Instead, they tell you that you are "holding it wrong" and that this is not really a problem, that your usage is "niche", that the interpreter is alright as it is, and that the time to first plot is unlikely to ever go below a hundred milliseconds. I find it really depressing for the language itself is incredibly beautiful. My only hope is that an independent, fast and unix-friendly implementation of the language arises, thus freeing the reference implementation of the efficiency burden and allowing it to be simpler. Something like the lua/luajit split.
EDIT: also, sorry for the mis-characterization of Julia developers! I may have dealt until now with users and "fanboys" not real devs.
Here's a blog post that goes into some detail about the ongoing efforts to improve compiler latency: https://julialang.org/blog/2020/08/invalidations/
Now that you ask it, I realise it's been mostly through a few HN interactions! Every time I raised the issue in Julia posts over the last few years, I have been consistently ridiculed by purported Julia defenders. For example, in this very thread you can find a case of that.
I do get frustrated by characterizations of the interests of the Julia community that are very broad, and are also in evidence here. E.g. somewhere upthread one person claimed Julians are only interested in Jupyter Notebook workflows, which is a totally alien statement to me. Jupyter doesn't seem to have a very large mindshare as far as I can tell, I've never even tried it myself.
Static compilation and analysis comes up regularly on Discourse, but among the scientist part of the community, there is naturally less emphasis on this. Please don't extrapolate too far based on some isolated interactions.
How is that controversial or disappointing!? Why would anyone bother optimizing this? Nor is matlab/octave/python any faster.
`python3 -c "import matplotlib.pyplot as plt; plt.plot([1,2,3]);"` takes 600ms on my (powerful) workstation and that does not even include creating the plot window.
To be clear, I do believe there is much more work to be done to decrease latency in Julia, but your targets are ridiculous. And as a regular on their bugtracker and forum, the devs definitely acknowledge these issues and have many times said it is one of their main priorities.
By the way, if you want streaming live updated plots, this latency to first frame is not a problem. It is already straightforward to make such fast live plots in Julia (although it does not fit my personal taste for how to do it).
Only because you are not used to somewhat fast programs:
$ /usr/bin/time -v gnuplot -e 'set term png; plot sin(x)' > sin.png
...
User time (seconds): 0.02
System time (seconds): 0.00Julia is a terrible replacement for gnuplot and gnuplot is a terrible replacement for julia.
Maybe this example would make it clearer: why does your argument not apply to Python? Should we expect python libraries to come pre-cached so that the first time I load `sympy` I do not need to wait for tens of seconds to have .pyc files created. Or about matlab?
Again, I am all on board with the idea that julia needs lower latency and if you look at what their devs say, they also agree with that. But expecting Julia to be super low-latency (lower-latency than python/c/matlab) for your pet task is silly.
Another strategy: when a user installs Julia, they select “fast-loading” libraries. You’d be surprise how small changes in UI/UX make huge perceived differences in quality and performance. I bet “Julia can already do this” too, but nobody does it because it’s not idiomatic and it’s not recommended up front.
At the end of the day, people don’t complain about Python or MATLAB as much because they feel nicer. If it feels nicer because of some other reason than absolute time, then they’re doing something about UX that Julia is not, because everybody really does feel Julia is extremely sluggish to use.
There are better stats available (downloads), but I do not know of a good place to play with them publicly.
Don't most people already use a bit of PackageCompiler.jl in their workflows? Maybe it just need to be mentioned more in introduction videos, but it's literally one line of code to do this and I don't see how that isn't the solution already. Most users I know have been doing it for a few years now.
For reference, with Plots and DifferentialEquations the command is:
using PackageCompiler; create_sysimage([:Plots,:DifferentialEquations])
It's simple enough to add to every tutorial. I think the issue is that intro videos just need to be updated.
My suggestions: 1- please forget about the intro videos. Those are impossible to keep up-to-date, and are not a good reference resource. Sure, a future video should explain PackageCompiler, but that is not sufficient. 2- please update docs.julialang.org with all such guidelines. This is the likely the first place people look, so if there are important guidelines that everyone could benefit from, this is where they belong.
And to be clear, I do expect my second plot to be ready in tens of milliseconds.
eh..., it's open source. maybe they are just waiting for you to take care of it. just joking. i suspect there isn't ppl
Edit: ah, thanks for the response, it seem I just do not know the difference between "feature" and "timed" release.