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

141–150 of 216 posts

Re: Julia 1.9

#141

Post by cjalmeida »

cookieperson wrote: post #113
cjalmeida wrote: post #103

Earlier quoted context omitted.

Counter anecdote, I had to go back to a quite complex project that a was developed in 1.5, 3 years ago, hundreds of dependencies. Upgrading to 1.9 RC2 required changing a single dep (Light raps to the drop-in Graphs) and a single line (a library changed the return from a String to a StringView)

You're incredibly lucky. Even minor version bumps have left me up shit creek in production with deadlines.

Julia core is backwards compatible all the way to 1.0, libs not so much.

Now, something as fundamental as numpy dropped support for Pythonhttps://numpy.org/devdocs/release/1.19.0-notes.html

And I've been bitten by relevant python libs breaking stuff even in patch releases.

It happens and it's far from particular to Julia. I just make sure to test stuff property before going to production.

Re: Julia 1.9

#142

Post by sundarurfriend »

affinepplan wrote: post #132
krastanov wrote: post #124

Earlier quoted context omitted.

Could you elaborate on the ecosystem problem? For my corner of the world, Julia probably has one of the highest quality ecosystem (differential equations, physics modeling, autodiff through very complicated code, probabilistic programming, SIMD/multithreading, and wonderful plotting libraries (the Makie.jl ecosystem) and good data wrangling capabilities (the Dataframes.jl ecosystem)). I am curious what are the fields…

> I am curious what are the fields where it is less well developed? Data engineering and cloud integration is a big one. It has very few tools in that domain, and I say this as a heavy Julia user (hobby).

I've heard about cloud integration as an issue before, but what is "data engineering"?

Re: Julia 1.9

#143

Post by hpcjoe »

cookieperson wrote: post #112
Sukera wrote: post #104

Earlier quoted context omitted.

It would be great if you could share such an example work load - such big examples are often few and far between, even though they are VERY good for debugging compilation performance.

Grab any project you have with more than 2k lines, multiple dependencies and run package compiler on it. Wait an hour, hopefully it didn't barf irreconcilably and check the file size.

My packages at work are about 1.5k lines. Precompilation is about 10-15 seconds. After precomp, about 1-2 seconds to load with "import" or "using". The longest I've seen on precomp have been DifferentialEquations.jl. I've not used it in a while, though I have plans to for personal (non-work related) projects.

My packages have 5-10 dependencies in them, I tend to keep my packages/tooling streamlined, and I performance optimize them (everything from loading time, through data structure/algorithm implementation) quite thoroughly.

Other users at my firm are adopting Julia as well. It isn't displacing python, though that is a possible future. Its similar enough that many grasp it right away. Its fast enough that its a viable alternative to Python + C++.

This said, Julia is not a silver bullet[1], though it is an excellent programming language. It has been able to do all of the same tasks as my python code. Faster (often multiple orders of magnitude) working with 10s to 100s of GB of data, in parallel.

Its a better solution for my workflow, and an increasing number of others. If its not to your liking, that's fine. No need to try to push it down with, from my vantage point, what seems like specious claims (very long precompilation times close to an hour, or so). If you have such actual examples, please post them. I'd love to see them. Chances are we could optimize this fairly easily.

[1] https://www.merriam-webster.com/dictionary/silver%20bullet

Re: Julia 1.9

#144

Post by hpcjoe »

jrockway wrote: post #121
cookieperson wrote: post #83

Earlier quoted context omitted.

Probably a decent one. Compilation of even small size projects easily took hours as of a year ago. All while people were screaming about how good it was. The equivalent code in other languages would be statically compiled in milliseconds. The size of the binaries was also thousands of times bigger...

You've gotten Julia to produce a runnable binary? Impressive.

It is possible, within specific limits, using StaticTools.jl and StaticCompiler.jl. Sadly for me, my code won't work within the indicated limits.

This is the biggest issue for me, for deployable code. I'd love to hand my users a single binary (like go/rust), which has all the code/data needed, so no precompilation time, and instant startup. I am hoping the Julia team understand how important this is ... language competitors have runtimes (python, etc.) or binaries (go/rust/c++). We really need the latter to distribute code to production.

Imagine a post compilation step, kind of like the code caching, which wraps everything we need into a binary, with compiled cached code, startup code, runtime libs, etc. . That would be amazing, and fit well within the julia paradigm.

Re: Julia 1.9

#145

Post by jakobnissen »

tastyminerals2 wrote: post #140
krastanov wrote: post #134

Earlier quoted context omitted.

I think the dynamical recompilation that made code caching difficult is from 0.6, the last release before 0.7 (the first stable release). From 0.1 (2012 or 2013) to 0.7 julia evolved drastically. They stabilized only in 2018ish. This seems like a pretty reasonable timeline for something no other language has done before (although, as I mentioned, pytorch/jax/tensorflow have some limited similarities, and similar prob…

I see. Right, 2017 was the first time I tried Julia and never came really back. Then the Torch, TF, Keras, PyTorch era started and kept ML engineers busy while I think Julia couldn’t keep up. Well, there is Flux. Not sure how it compares.

It can't compare, not even close. There is just too little devpower behind Flux. Also, the AD landscape in Julia have been changing so fast that the ground has been shifting under Flux, so to speak.

It's a shame, because Julia is so obviously a good language for DL.

Re: Julia 1.9

#146

Post by sundarurfriend »

borodi wrote: post #122
sundarurfriend wrote: post #48

> 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?

We used the chromium snapshot file format ( https://learn.microsoft.com/en-us/microsoft-edge/devtools-gu... ). If firefox uses the same format then it should work, but I haven't tested.

Unfortunately it seems like they're different formats, Firefox just prints "Error: Invalid memory report(s): data version number missing or doesn't match" if I try to load a snapshot (whether from Chromium or from the Julia profiler).

Re: Julia 1.9

#147

Post by sundarurfriend »

sundarurfriend wrote: post #95

Two very nice additions to the REPL that weren't mentioned in the highlights: * `Alt-e` now opens the current input in an editor. The content (if modified) will be executed upon exiting the editor * A "numbered prompt" mode which prints numbers for each input and output and stores evaluated results in Out can be activated with REPL.numbered_prompt!() (basically `In[3]` `Out[3]` markers like in Mathematica/Jupyter).

(The page does mention the numbered prompts, I somehow missed it.)

Re: Julia 1.9

#148

Post by mejutoco »

henearkr wrote: post #69
mejutoco wrote: post #27

Earlier quoted context omitted.

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.

You could start indices at 0 but still take slices with ［start:end］, I don't see a dependency between those two aspects. And the start index being 0 or 1 does not affect much the understanding of the language, contrary to this slice insanity in Python... I had college lectures using 0 as start index, others using 1, both were fine, no problem. However taking a slice with ［start:end+1］ is unequivocally counterintuitiv…

They are orthogonal issues. The connection was that if Python can be counterintuitive because of slice syntax, the same can be claimed of Julia and 1-indexed. It is not a good argument IMO.

I see your point, but personally find it a matter of preference, not of objective truth.

`range(end+1)` is consistent with that slice notation that you disapprove of.

At the same time, on 0-indexed vs 1-indexed you seem to have no preference (I prefer 0 for historical reasons).

How about `len(items)` vs `items.length`? I have my own preferences there, but I would not say any or the other is intrinsically better.

Anyway, I already wrote way too much about such a small syntax thing :)

Re: Julia 1.9

#149

Post by kxyvr »

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.

At least in the past, there were some issues with the licensing of dependencies. For example, both Julia and MATLAB were dependent on a variety of routines from SuiteSparse such as the Choleski factorization and the QR factorization. These routines are dual licensed commercial/GPL. The difference is that your MATLAB license gave the ability to use things like the MATLAB Compiler to distribute somewhat closed code to a client because they, ostensibly, have a license for SuiteSparse. Julia did not, so any project compiled into a stand alone executable would be subject to GPL unless an additional license for the dependencies was purchased. Now, if you're only distributing the source code, which most people do, this doesn't matter as much, but we should all be aware of our license responsibilities. MATLAB has more functionality built-in and I trust they've done the legal legwork for their included routines, so I don't have to.

To be clear, Julia constantly updates and I'm sure many of its original dependencies are being recoded to help address this issue. I still think it's worth a check and audit if someone wants to put together a broader project as to not get burned by this issue later.

Re: Julia 1.9

#150

Post by sundarurfriend »

kxyvr wrote: post #149
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.

At least in the past, there were some issues with the licensing of dependencies. For example, both Julia and MATLAB were dependent on a variety of routines from SuiteSparse such as the Choleski factorization and the QR factorization. These routines are dual licensed commercial/GPL. The difference is that your MATLAB license gave the ability to use things like the MATLAB Compiler to distribute somewhat closed code to…

Yeah, there have been active attempts to move SuiteSparse out of the base sysimage for this reason. It was planned for this 1.9 release, but looks like there are some performance regressions from the current attempts, so it's not yet there.

Julia code is mostly distributed as source code, and compiling into standalone executables and then distributing them to outsiders is not very common, so it doesn't often come up as an issue. But it's an important detail to keep in mind in case the use case does arise.

Post reply on HN