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

161–170 of 216 posts

Re: Julia 1.9

#161

Post by affinepplan »

sundarurfriend wrote: post #142
affinepplan wrote: post #132

Earlier quoted context omitted.

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

working with databases, streaming data around with stuff like kafka or snowflake, integration with orchestrators like prefect or dagster, robust interfaces for spark, being able to read a directory of parquet files without the GC going insane, this kind of thing

I know there are some existing packages that nominally do some of these things, but generally they are understaffed and not fully mature. I love Julia as a language, so I hope this will improve over time. I think it's one of those problems that just requires more adoption before it can be fixed, and things like precompile TTFX improvements in 1.9 are a good way to get that!

Re: Julia 1.9

#162

Post by npalli »

Nice improvements

----------------------------

JULIA 1.8.5

julia> @time using Plots

11.341913 seconds (14.83 M allocations: 948.442 MiB, 6.88% gc time, 12.73% compilation time: 62% of which was recompilation)

julia> @time plot(sin.(0:0.01:π))

3.342452 seconds (8.93 M allocations: 472.925 MiB, 4.44% gc time, 99.78% compilation time: 78% of which was recompilation)

-----------------------------------

JULIA 1.9.0

julia> @time using Plots;

2.907620 seconds (3.43 M allocations: 195.045 MiB, 7.52% gc time, 5.61% compilation time: 93% of which was recompilation)

julia> @time plot(sin.(0:0.01:π))

0.395429 seconds (907.48 k allocations: 59.422 MiB, 98.54% compilation time: 74% of which was recompilation)

Re: Julia 1.9

#163

Post by vfclists »

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…

What is the relevance of a review of the language tried one time a few years back?

Today is not a few years back.

No one genuinely wants a review of the product from a few years back if they are seriously considering the language today.

Julia is not Lisp or Scheme.

Re: Julia 1.9

#164

Post by PartiallyTyped »

mathisfun123 wrote: post #72
PartiallyTyped wrote: post #46

Earlier quoted context omitted.

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…

>In PyTorch you have a graph that is created on runtime by connecting the operations together in a transparent manner. 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.

Transparent in this case means the average user does not need to interact with the underlying system, it is there, it does stuff, but the user does not see it or interact directly.

What is opaque is jax's tracer objects in the sense that the system exists, is there, the user is aware that it is there, and you can't peek inside it without actively going out of your way.

With PyTorch you can implement your own functions with their own forward and backward passes; whether the underlying operations use libtorch is irrelevant, that is simply a backend.

The computation graph __is__ created at runtime, whether the scaffolding for this is done in libtorch or directly in python is not relevant.

Re: Julia 1.9

#165

Post by hpcjoe »

eigenspace wrote: post #158
hpcjoe wrote: post #144

Earlier quoted context omitted.

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 comp…

StaticCompiler / StaticTools are a bleeding-edge playground. GP is talking about PackageCompiler.jl which is for serious things that can be trusted to work, but is slow and produces huge binaries.

I've been looking into that for a while, as a way to create a common environment for users in my team. I did get it to work, though as you mention, build times are long for this.

Re: Julia 1.9

#166

Post by huijzer »

eigenspace wrote: post #158
hpcjoe wrote: post #144

Earlier quoted context omitted.

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 comp…

StaticCompiler / StaticTools are a bleeding-edge playground. GP is talking about PackageCompiler.jl which is for serious things that can be trusted to work, but is slow and produces huge binaries.

Plus, to make it fully static, you need to ensure that all code paths are being hit.

Re: Julia 1.9

#167

Post by stellalo »

majoe wrote: post #133

I really like "Julia, the programming language" and had a great experience using it on the few occasions, where it made sense. But whenever a colleague asks me, if I can recommend it, I have to say "no". The crux is, that its "just-ahead-of-time" compiler disqualifies it for a lot of use cases: I actually would prefer it over Python for small scripts, but the compilation overhead is too long. On the other hand I woul…

> I actually would prefer it over Python for small scripts, but the compilation overhead is too long

Looks like this release reduces that by a lot, see the first section in the OP on caching native code, modulo adoption of good precompilation habits by the various packages.

Re: Julia 1.9

#168

Post by ddragon »

I'm quite interested in the interactive thread pool (although I assume it works based on conventions of everyone playing nice). Julia seems to have a powerful parallelism model but it couldn't apply it to responsive GUI and web frameworks that requires low latency, so it is nice if you indeed can have for example the tasks handling HTTP request focusing on handling it as fast as possible while the background working threads dealing with larger computations use all the speed of the Julia language without being constantly interrupted.

Re: Julia 1.9

#169

Post by adgjlsfhk1 »

sundarurfriend wrote: post #146
borodi wrote: post #122

Earlier quoted context omitted.

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).

It probably wouldn't be that much work to make an option for firefox compatible reports. Might be a fun first PR for someone.

Re: Julia 1.9

#170

Post by GaryNumanVevo »

tastyminerals2 wrote: post #106
jbieler wrote: post #43

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.

So, you mean that loading a bigger project in Julia was more or less equal to compiling it with some language like C++? And you had to do it every single time in order to work with the project? This doesn’t sound too good tbo.

In practice, it's not a huge issue. Static imports are already precompiled and any code paths within your project are cached. Typically people will use a single session and use hot code reloading, so any changes in the codepath will need a recompile (on the order of milliseconds).
Post reply on HN