Can someone comment on the ease of distributing Julia code? Can I easily take a bit of code I write (w/o external libraries) and produce a single binary I can ship to someone or do they require a full Julia environment to run it?
Julia 1.6: what has changed since Julia 1.0?
61–70 of 212 posts
Re: Julia 1.6: what has changed since Julia 1.0?
#62Earlier quoted context omitted.
A few months ago. First time to plot is noticeably better than it was a few versions ago, but still extremely slow compared to Python. The article gives a benchmark of 9 seconds. I mean, come on. The main problem I had was simply that what any time I needed to modify a struct field, or anytime my program crashed, or any time the buggy IDE extension crashed, I needed to recompile everything. I also haven't found anyon…
> The "just ahed of time" compilation is one of those obvious-in-hindsight ideas IMO It's not new. One of the most widely used Lisp environments, SBCL, works this way. So does Chez Scheme, and therefore now Racket.
That's interesting, I didn't know Racket worked like that. What I meant wasn't so much that its a new idea, rather that it's a good one.
Re: Julia 1.6: what has changed since Julia 1.0?
#63It takes 180s to import Statistics, PlutoUI, Images and OffsetArrays in Pluto on this Macbook Pro with 32GB that is a couple of years old, while the fans are going crazy. If I'm unlucky a worker process will seg fault. All in all the interactive / REPL part (even with stuff like Revise) is kind of a let down thanks to the slow precompilation / lack of caching? I like it, but I really don't see how it is ever going to…
Just checked. On my slightly dated laptop the import of these packages in Pluto takes 5 seconds with Julia 1.6.
In general 1.6 is a huge improvements in compilation times and usability for me.
Re: Julia 1.6: what has changed since Julia 1.0?
#64Earlier quoted context omitted.
A few months ago. First time to plot is noticeably better than it was a few versions ago, but still extremely slow compared to Python. The article gives a benchmark of 9 seconds. I mean, come on. The main problem I had was simply that what any time I needed to modify a struct field, or anytime my program crashed, or any time the buggy IDE extension crashed, I needed to recompile everything. I also haven't found anyon…
No one interested in interfaces? My impression is that interfaces is very commonly discussed, and is one of the most anticipated features in the language, though it may not come until v2.0.
OK, I was being hyperbolic. It's just that the interest is low compared to other features, as most people involved in the project are used to dynamic languages and don't feel the need. It's been in discussion for a long time, with no action so far. From what I've seen, the general attitude is a bit dismissive of the utility of static verification ("its different in our language because X" type attitude)
Re: Julia 1.6: what has changed since Julia 1.0?
#65Earlier quoted context omitted.
In what way is marketing julia as a general purpose programming language 'way out of line'? People use julia to make webservers, write programming languages, create plotting libraries, do scientific analysis, do compiler research, make video games, do HPC, etc. Julia has a design that's indeed strongly informed by scientific computing, but in order to actually meet the needs of the various people using it for scienti…
Do you think R or Matlab is a general purpopse language? Sure you could do all these things but should you? Julia is clearly positioned as a scientific computing language. Let's be clear.
Doing these things in julia is very different from doing these things in R or Matlab. The tooling and ecosystem for non-scientific applications in Julia is growing rapidly and is quite competent.
Julia is absolutely a general purpose language. It’s user base skews heavily towards scientific computing, but the demographics and ecosystem are broadening daily.
Re: Julia 1.6: what has changed since Julia 1.0?
#66> Plotting, it turns out, is basically a really hard thing for a compiler. It is many, many, small methods, most of which are only called once. And unlike most Julia code, it doesn’t actually benefit all that much from Julia’s JIT. Julia’s JIT is normally specializing code, and running a ton of optimizations. But plotting itself isn’t in the hot-loop – optimizing the code takes longer than running it the few dozen ti…
Yeah, I got fed up with Julia's plotting library and wrote a C++ Qt plot function that forks and plots arrays of doubles.
It runs instantly even with millions of points.
Re: Julia 1.6: what has changed since Julia 1.0?
#67Earlier quoted context omitted.
Thanks! Is there a way to compile all installed packages into the sysimage? If so, why isn't that the default?
Technically yes, but then IIRC you’d have to recompile the whole sysimg any time you update any single package, which could get to be a pain. The usual compromise seems to be to include just a handful of your most used packages in the sysimg (say Plots + Revise)
> you’d have to recompile the whole sysimg any time you update any single package
Are there any downsides to this? You never care how long does a system update take. You always care how long do your programs run.
Re: Julia 1.6: what has changed since Julia 1.0?
#68Can someone comment on the ease of distributing Julia code? Can I easily take a bit of code I write (w/o external libraries) and produce a single binary I can ship to someone or do they require a full Julia environment to run it?
They require the full Julia environment to run it - and it's a heavy environment. It is possible to compile a binary that includes the environment and the compiler, but IIRC, that will result in a >400 MB hello-world script taking 150 MB of RAM to run.
The core devs have mentioned they are going to add the capacity to compile to actual static binaries, but that does not seem to be a top priority, so I wouldn't hold my breadth waiting for it.
Re: Julia 1.6: what has changed since Julia 1.0?
#69> Plotting, it turns out, is basically a really hard thing for a compiler. It is many, many, small methods, most of which are only called once. And unlike most Julia code, it doesn’t actually benefit all that much from Julia’s JIT. Julia’s JIT is normally specializing code, and running a ton of optimizations. But plotting itself isn’t in the hot-loop – optimizing the code takes longer than running it the few dozen ti…
You can certainly achieve the Rust plotting solution for Julia by compiling a plotting package with PackageCompiler. I use this for day-to-day research tasks.
However, Julia users are greedy! They want their cake (composability, portability, dynamic language features) and eat it too (performance). Lots of effort has thus been put into the language towards not needing solutions like PackageCompiler.
Re: Julia 1.6: what has changed since Julia 1.0?
#70Can someone comment on the ease of distributing Julia code? Can I easily take a bit of code I write (w/o external libraries) and produce a single binary I can ship to someone or do they require a full Julia environment to run it?
Doing this without the user having Julia installed would require using PackageCompiler.jl to make a standalone executable. https://julialang.github.io/PackageCompiler.jl/dev/apps/
This is a pretty stable well established process now, but the binaries it produces are huge because they actually have the full Julia runtime in them.
Active work is happening on small binary static compilation. We already do it for GPUs, we just have to repurpose our GPU AOT compilation pipeline for the CPU. There are proofs of concept that currently work, but something more polished is feeling like it’ll probably be another year or so.