71–80 of 216 posts
Earlier quoted context omitted.
Most likely a single or dual core CPU. I have similar compilation times with Rust on an old Asus 1215B, where 8GB and SSD hardly help the compile the world from scratch cargo model, when starting a new project.
reasonably simple notebook != compile the world from scratch
Earlier quoted context omitted.
Certainly there is a lot of magic going on in very popular Python libraries that implement autodiff or JIT compilation like PyTorch or JAX -- although the maturity of the ecosystem does mean that it is often quite well hidden. For the other languages, well... if you don't think C++'s templates tricks, Haskell's extension potpourri or indeed Rust's own combination of traits and type-level programming techniques can ge…
I really don't feel that there is magic in PyTorch or jax, but that may be because I have written my own autograd libs. In PyTorch you have a graph that is created on runtime by connecting the operations together in a transparent manner. Jax may feel a bit magic, but all that's done is sending / splitting tracers and recording the operations and compiling; by limiting the language, you have controlled branching with…
You've jumped the shark here mate because autodiff in PyTorch is implemented using compile-time generated code in libtorch - it's not only the very definition of opaque but also pretty close in spirit to a macro.
Earlier quoted context omitted.
Most likely a single or dual core CPU. I have similar compilation times with Rust on an old Asus 1215B, where 8GB and SSD hardly help the compile the world from scratch cargo model, when starting a new project.
reasonably simple notebook != compile the world from scratch
Matlab users should switch to Julia. It’s a real programming language, and better in many ways. I provide the option of Julia in my tutorials. Students are lazy, and don’t want to explore something new. Most of them stick with matlab. What prevents matlab users from switching? The syntax is similar.
I don't know if you genuinely want feedback... But I'll share my very short experience. I tried Julia one time a few years back. I'll be honest, I didn't put in a lot of effort into (but nor will most potential Matlab converts - bc people are busy and have stuff to do) It's got a frustrating "not fun" on-boarding. ie. the number of minutes from downloading "Julia" to getting cool satisfying results 1. It not a calcul…
It’s true that the majority of the Julia community comes from a scientific or engineering background, and this is reflected in the package ecosystem and some of the “embedded” language features for technical computing. However I feel like stressing Julia as a “technical language” any more than it currently is may scare away people that may want to use it for other purposes, such as a general purpose scripting language.
Now more than ever before, with the improved code caching in 1.9, Julia lends itself perfectly for interactive usage and day-to-day scripting.
Earlier quoted context omitted.
A lot has changed in a few years. This release is a big one. 1. I run Julia on my smartphone and often use it as calculator. 2. You typically only need Plots.jl for most needs. See https://docs.juliaplots.org/stable/ 3. See https://juliaacademy.com Another alternative environment are Pluto notebooks. It's reactive like a spreadsheet, but easy to use in your browser. https://featured.plutojl.org/ I have several users…
Not to detract from everything else.. I've gotta say, that's the most confusing library name possible. First I thought it's a website about Julia plotting libraries. Then I thought it's a new Julia default plotting interface (with actual plotting libraries as backends). Then after I saw the code I realized that it's a library that literally called "plots"... I'm sure it's great SEO though
> Then I thought it's a new Julia default plotting interface (with actual plotting libraries as backends). Then after I saw the code I realized that it's a library that literally called "plots"...
It's both. It's a library called Plots.jl, that's a plotting interface to backend plotting libraries. It's not "new", not "default" in the sense of built-in, but usually the recommend first option for most use cases.
Earlier quoted context omitted.
What prevents it is the libraries. Just like Python. Julia as a compiled language is faster and more distributable than either, but there is a chicken-egg problem about the ecosystem. MathWorks' provided libraries for Matlab are excellent, amazingly documented and massively supported. Python libraries are just hugely numerous in any domain you can imagine...
There are PyCall.jl and RCall.jl. Stay in Julia and use other libraries in addition.
Earlier quoted context omitted.
A lot has changed in a few years. This release is a big one. 1. I run Julia on my smartphone and often use it as calculator. 2. You typically only need Plots.jl for most needs. See https://docs.juliaplots.org/stable/ 3. See https://juliaacademy.com Another alternative environment are Pluto notebooks. It's reactive like a spreadsheet, but easy to use in your browser. https://featured.plutojl.org/ I have several users…
Not to detract from everything else.. I've gotta say, that's the most confusing library name possible. First I thought it's a website about Julia plotting libraries. Then I thought it's a new Julia default plotting interface (with actual plotting libraries as backends). Then after I saw the code I realized that it's a library that literally called "plots"... I'm sure it's great SEO though
Earlier quoted context omitted.
>Matlab users should switch to Julia. [...] What prevents matlab users from switching? The syntax is similar. Choosing a programming language based on just comparing the language syntax only works for academic settings or toy projects for self-curiosity and learning. Once you consider adopting a language for complicated real-world industry usage , you have to look beyond the syntax and compare ecosystem to ecosystem…
The flip side to this is that Julia is a great general purpose engineering calculator and simulator. For example, calculating friction in hvac ductwork, voltage drop in long electrical circuits, solar gains for windows or solar panels facing various directions, cost/benefit analyses of thicker or thinner roof insulation and so on... these are all 1 to 10 lines of code so there isn't a big porting cost in moving to Ju…
Earlier quoted context omitted.
> The tradeoffs are somewhat larger load times (TTL) The post says "TTL has also been reduced, albeit not as dramatically as TTFX." And the graph seems to indicate the same. Is that not true, or are you comparing it to pre-1.7 TTLs (which are not shown in the post), or is it just context(/project)-dependent?
Both are true. Package images and the use of PrecompileTools makes packages load slightly slower, because there is more data to load, namely all the precompiled machine code. It's still faster to load than to compile, so the gains in TTFX (i.e. compilation) outweighs the gains in TTL (i.e. loading). For 1.9, code loading has also been optimised, such that code loading is in many cases faster in 1.9 than in 1.7. Howev…
So with all of these piling up, I think v1.10 will make a great new LTS since v1.9 feels a bit "4/5 of the way there" because there's still the using time to chop down in the next release to get things to sub-second.