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

Julia 1.4

github.com

Post reply on HN
Print view View original

51–60 of 137 posts

Re: Julia 1.4

#51

Post by ViralBShah »

dr_coffee wrote: post #26
disgruntledphd2 wrote: post #23

Earlier quoted context omitted.

I dunno, the comments were pretty informative. Looks like Julia still haven't managed to handle updates well. I remember being so amazed that they'd blown their 1.0 announcement (went from 0.7 to 1.0 over a Juliacon). And because there were so many changes (most of which i thought were good), it was pretty broken for new users at that time, which I firmly believe limited their adoption. And to be clear, I love the id…

I really enjoy using Julia too but I have also been disappointed with how the updates have played out. Just a few weeks ago I rolled back my installation from v1.2 to the LTS version because of silly errors in the plotting package not allowing me to plot. Otherwise it really is a pleasure to use, and I have found that the LTS install has zero compatibility issues thus far.

Glad to hear that the LTS version did not have an issue.

I hope you did file an issue with the Plots package. The reason is that we generally like to make sure that regressions like these are not language level regressions. Sometimes package use undocumented internals - but we generally chase each and every single one of these.

For those who haven't seen it yet, we have described our release process in great detail in this blog post: https://julialang.org/blog/2019/08/release-process/

Re: Julia 1.4

#52

Post by KenoFischer »

xiphias2 wrote: post #22
komuher wrote: post #9

Something about Julia from me. I was big Julia fan using it for last 1.5 year and in my company we are using Julia for data preprocessing and parsing hundred of GB's of data. (We also use Python for ML and start to moving julia code to Nim for data prepro) If u consider Julia as ur next language dont use it to any medium to big project outside pure scientific purposes it just isnt ready yet. We have about 3.5k loc in…

I'm also fighting the GC all the time, although I love Julia. I wish I could tell the compiler to compile a function only if it can do it without using memory allocations. Often I would rather see a compilation error than the GC making performance of a function unpredictable.

Yep, you're not alone in wanting tighter control over memory allocation and GC. It's something that we're planning to work on this year.

Re: Julia 1.4

#53

Post by xiphias2 »

KenoFischer wrote: post #52
xiphias2 wrote: post #22

Earlier quoted context omitted.

I'm also fighting the GC all the time, although I love Julia. I wish I could tell the compiler to compile a function only if it can do it without using memory allocations. Often I would rather see a compilation error than the GC making performance of a function unpredictable.

Yep, you're not alone in wanting tighter control over memory allocation and GC. It's something that we're planning to work on this year.

It's really cool.

Of course borrow checker would be helpful, but I guess that's too hard to implement, that's why something like this would be a good balance.

Re: Julia 1.4

#54

Post by vasili111 »

What is the state of Julia dataframe? Is it ready for production use? How is the Julia dataframe performance in comparison with R and Python dataframes?

Re: Julia 1.4

#55

Post by oxinabox »

komuher wrote: post #9

Something about Julia from me. I was big Julia fan using it for last 1.5 year and in my company we are using Julia for data preprocessing and parsing hundred of GB's of data. (We also use Python for ML and start to moving julia code to Nim for data prepro) If u consider Julia as ur next language dont use it to any medium to big project outside pure scientific purposes it just isnt ready yet. We have about 3.5k loc in…

> If u consider Julia as ur next language dont use it to any medium to big project outside pure scientific purposes it just isnt ready yet

My employer, Invenia, uses Julia for what I would say is at least a medium sized project.

~200k LOC, ~30 people concurrently working on that code base, literally the core product/system that makes us money.

Julia's not perfect, but I would not blanket discount it out of hand for medium projects. Like all technologies the tradeoffs need to be investigated with reference to the task (and team) at hand.

Re: Julia 1.4

#56

Post by oxinabox »

vasili111 wrote: post #54

What is the state of Julia dataframe? Is it ready for production use? How is the Julia dataframe performance in comparison with R and Python dataframes?

My employer uses DataFrames.jl in production. It's fine, nothing wrong with it. Used to be a bit unsafe to unwarey uses, now it's safe by default and you need to do a bit extra to get all the performance.

It's worth knowing it is more like R's DataFrames than like Pandas.

It is getting pretty close to a 1.0 release. Probably a few months out (One more minor, then if all goes well 1.0 a month or so later)

Further one should know that there are many tabular data packages in Julia and they all use the interface defined by Tables.jl, and all interop very well.

Query.jl (which is something like Linq or TidyR) works with all of them, and do packages for loadingand saving (CSV.jl, LibPQ.jl etc)

Re: Julia 1.4

#57

Post by eigenspace »

Surprised by some of the negativity here! I've been extensively using julia for my graduate physics research and a lot of hobby programming for almost 3 years now and absolutely love it.

It's a beautifully designed language with incredibly responsive and wise developers and 1.4.0 is a great release I've been on 1.4 release candidates for over a month and haven't had a single issue, and love the new features and improvements.

Re: Julia 1.4

#58

Post by eigenspace »

logicchains wrote: post #38
komuher wrote: post #31

Earlier quoted context omitted.

For numeric code sure but its because Julia are using BLAS (or any other instruction for CPU/GPU u give to LLVM). Julia (no BLAS) -> In matmul its on pair with Golang and Swift and a bit slower then RUST and Nim. If u need BLAS then just use lib with that :)

Numeric code doesn't just mean matrix multiplication. If I have a random nested for loop, it will probably run at least as fast as those languages(apart from maybe Nim, never used it) if annotated with @simd and @inbounds. If I'm operating on a small array/matrix, then Julia will blow Go/Rust out of the water via stack-allocated static arrays ( https://github.com/JuliaArrays/StaticArrays.jl ). These can't be implemen…

Actaully, julia for loops can be made to perform at BLAS levels with this package: https://github.com/chriselrod/LoopVectorization.jl.

Here are my early experiments at making a pure-julia multi-threaded BLAS using LoopVectorization.jl https://github.com/MasonProtter/Gaius.jl. It absolutely blows a naive triple for loop out of the water and is quite competitive against OpenBLAS until you get to very big sizes.

Re: Julia 1.4

#60

Post by FabHK »

komuher wrote: post #40
darsnack wrote: post #32

Earlier quoted context omitted.

I have been using Flux for a year (or more?) and I have never found it to be slower than PyTorch or TF. Granted I am training at most ResNet-20 and mostly smaller models, so maybe there is larger training routines where people have issues. Every single one of these deep learning libraries is mapping to CUDA/BLAS calls under the hood. If you wrote the framework correctly, the performance difference should not be drast…

Ok my fault i was writing from perspective of ML engineer not reasercher (I'm using Julia for 1.5 year now and my bois reaserchers prefer pure julia solutions cause its easier to write u can use symbols and not using OOP etc.) But for production ready models PyTorch and TF is miles ahead first of all: NLP, audio and vision based packages building frameworks, (attention layers, vocoders etc.) then u have option to com…

I have no special insight into ML or Julia (though I love it), but one thing I can confirm from experience is that there is a huge difference between getting a model work once in an academic or research setting, and having something reliably and scalable work in production day after day. Mind boggling, totally different challenges.
Post reply on HN