Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Julia 1.9

julialang.org

Post reply on HN
Print view View original

41–50 of 216 posts

Re: Julia 1.9

#41

Post by currymj »

kgwgk wrote: post #26
pjmlp wrote: post #23

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

if a small piece of code depends on a few big, complex packages then depending on how things work out, due to the JIT model, you might have needed to essentially recompile all these dependencies at runtime every time. now there are increasingly better precompilation tools to avoid this.

Re: Julia 1.9

#42

Post by 16bitvoid »

mejutoco wrote: post #27
henearkr wrote: post #4

Earlier quoted context omitted.

Given the premices on which the Python language was designed (giving access to programming to non-programmers), your stance is surprising. To me, it looks like, to the contrary, that Python is so full of counter-intuitive bits... like doing a［begin:end+1］ to take a slice.

I like Julia, and Python has some weird bits. I see your point. But not sure this is an argument for it. Julia uses 1-indexed arrays. I guess counter-intuitiveness is in the eye of the beholder.

I'm not sure if you're saying that 1-indexed arrays are counterintuitive, but if you are, my experience has been that 0-indexed arrays are more counterintuitive to non-programmers, since most people count or make ordered lists starting at 1.

A few years ago, I worked in a neuroimaging research lab and taught some basic Python programming to quite a few research assistants with psych degrees. At the time, a scientific computing or intro to programming course wasn't part of the psych curriculum at the university that the lab was. 0-indexed arrays were often a big sticking point. It just didn't mesh with their intuition.

For example, if `len(some_list)` returned 2, they would try to get the last value with `some_list[2]` and then get confused. Or for another example, if they used `for i in range(n)`, they'd be confused when `i` didn't start at 1 and end at n. They eventually caught on and learned further syntax such as `some_list[-1]` for getting the last value in a list. But, it was a bit of a frustrating experience for both them and myself because I only had time to teach them the basics and some google-fu as well as give them some example code. While 0-indexing was a source of a lot of their bugs in the beginning, I learned that the best method for them to get the hang of it was to encourage them to do a lot of print debugging, which was more than adequate for any scripts they'd be writing. They just really needed more feedback from what they wrote and what it actually did to get a better grasp of the idiosyncrasies of programming vs. their intuition.

Side note: The frustration of teaching non-techies Python was nothing compared to teaching them LaTeX. I was luckily able to eventually convince the PI to adopt Overleaf and organizing the text into separate files and using `\include` or `\input` to reduce the headache of collaborative writing as well as move all the internal docs to markdown. The latter became a huge help when we eventually moved to Jupyter notebooks for a lot of our python-related scripts as the team members already became adept enough with markdown. It was also easier to teach everyone how to use pandoc for making pretty PDFs of the internal docs or converting their markdown drafts into LaTeX.

Re: Julia 1.9

#43

Post by jbieler »

This makes a big difference in usability, before loading a big project was almost in the "coffee time" category, now it's more "wait a few seconds". It helps a lot to make the tool feel more responsive.

Re: Julia 1.9

#44

Post by stdbrouw »

jasode wrote: post #36
aborsy wrote: post #6

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.

>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 Julia and in exchange you get a fast, ergonomic and sane language with universal support for physical units [1] and unicode variable names [2] so things are much less verbose than they would be in, say, Python.

In the past I used Calca [3] for these kinds of things, and there are many of these "fancy calculator apps" around, but it's just so much nicer to work in a real programming language.

[1] https://painterqubits.github.io/Unitful.jl/stable/

[2] https://docs.julialang.org/en/v1/manual/unicode-input/

[3] http://calca.io/

Re: Julia 1.9

#45

Post by jakobnissen »

sundarurfriend wrote: post #38
jakobnissen wrote: post #30

Earlier quoted context omitted.

PrecompileTools works out of the box - in the sense that the package developer needs to add a "@compile_workload" block in their package, but the users don't need to do anything. There is no special workflow or command to use it. The tradeoffs are somewhat larger load times (TTL), increased precompilation time (because some of the compilation moves to precompile time), and increased disk usage by the package.

> 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. However, this is an optimisation that is separate from the improvements to precompilation. The developers are currently working on even more TTL optimisations, so I expect that TTL will be significantly reduced in Julia 1.10, but for now, it's nice to see that TTL optimisations present in 1.9 has counteracted the increasing load times from package images.

Re: Julia 1.9

#46

Post by PartiallyTyped »

anewhnaccount2 wrote: post #22
PartiallyTyped wrote: post #3

Earlier quoted context omitted.

For me, the issue is that there's too much magic happening, e.g. with macros, but finding or solving the issues seems needlessly convoluted. Haskell, Rust, Python, or even C++ feel a lot less magic, and more reasonable despite all being quite different.

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 the proper semantics.

---

The main reason I have had such with Julia is simply because of how early / soon I ended up needing to use them whereas with the other languages, you can get away without getting into the very messed up things.

Re: Julia 1.9

#47

Post by PartiallyTyped »

wiz21c wrote: post #17
PartiallyTyped wrote: post #3

Earlier quoted context omitted.

For me, the issue is that there's too much magic happening, e.g. with macros, but finding or solving the issues seems needlessly convoluted. Haskell, Rust, Python, or even C++ feel a lot less magic, and more reasonable despite all being quite different.

I like rust a lot but when you get into errors because some deeply generic trait can't be matched, believe me, the compiler's messages are cryptic :-)

I'd love to see examples :D

Re: Julia 1.9

#48

Post by sundarurfriend »

> To analyze your heap snapshot, open a Chromium browser and follow these steps: right click -> inspect -> memory -> load. Upload your .heapsnapshot file, and a new tab will appear on the left side to display your snapshot's details.

Can the same be done with Firefox's `about:memory`'s `Load...` button, or is it Chromium specific?

Re: Julia 1.9

#49

Post by zorked »

geokon wrote: post #37
aborsy wrote: post #6

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…

VS Code supports Julia well, both plain and in Jupyter notebooks.

Re: Julia 1.9

#50

Post by freilanzer »

MagnumOpus wrote: post #14
aborsy wrote: post #6

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.

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.
Post reply on HN