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

21–30 of 137 posts

Re: Julia 1.4

#21

Post by mbeex »

logicchains wrote: post #17
komuher wrote: post #11

Earlier quoted context omitted.

Flux but its not even close to PyTorch or TF in terms of features and performance

It depends what you're doing. If you need to write your own kernels, or have small networks where the framework overhead is significant, then it's way faster than Tensorflow (unless you implement your own Tensorflow OP in C++/Cuda, but that's way more painful than just implementing it directly in Flux/Julia). It's hence quite nice for research on new architectures. Flux's autodiff also handles more language features…

> unless you implement your own Tensorflow OP in C++/Cuda

I don't know exactly what 'OP' means, but there are other ways to do ML in for example C++. I have some good experience with dlib, PyTorch's libtorch is on my todo list.

Re: Julia 1.4

#22

Post by xiphias2 »

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.

Re: Julia 1.4

#23

Post by disgruntledphd2 »

Someone wrote: post #5
KenoFischer wrote: post #2

To answer the usual complaint whenever the release announcement gets linked here, the NEWS file is intended to give current users of Julia an overview of all the things that changed that they may want to adjust to. It is however, not designed to give people who are only casually following the project an overview of all the work that's going on and why it's happening. We've been talking about writing a more casual doc…

”It is however, not designed to give people who are only casually following the project an overview of all the work that's going on and why it's happening. The NEWS file may not be designed for that, but IMO, it still is way better than this text, which, for casual followers, doesn’t say much more than “1.4 replaces 1.3, no breaking changes, a few new features”, without even mentioning those features, or why they wer…

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 idea of Julia, and that first document made me fall in love. And I think that the design for statistical computing is really, really good.

It's just a shame that this ops/packaging stuff is holding them back.

Re: Julia 1.4

#24

Post by cmrdporcupine »

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…

Sounds like a great opportunity to contribute fixes and improvements.

Re: Julia 1.4

#25

Post by logicallee »

ced wrote: post #18
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…

We're using it in a soft-realtime setting to monitor industrial chlorine production, and for us it has been a very pleasant experience overall. Yes, we've had some issues, but similar to other ecosystem IMO, and our support contract with Julia computing helped us in the one case we really couldn't solve ourselves. Julia works really well for power users. There are no huge libraries full of C code like pandas or scipy…

>and our support contract with Julia computing helped us in the one case we really couldn't solve ourselves.

Could you elaborate? What was the problem and what was the solution?

Re: Julia 1.4

#26

Post by dr_coffee »

disgruntledphd2 wrote: post #23
Someone wrote: post #5

Earlier quoted context omitted.

”It is however, not designed to give people who are only casually following the project an overview of all the work that's going on and why it's happening. The NEWS file may not be designed for that, but IMO, it still is way better than this text, which, for casual followers, doesn’t say much more than “1.4 replaces 1.3, no breaking changes, a few new features”, without even mentioning those features, or why they wer…

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.

Re: Julia 1.4

#27

Post by logicchains »

mbeex wrote: post #21
logicchains wrote: post #17

Earlier quoted context omitted.

It depends what you're doing. If you need to write your own kernels, or have small networks where the framework overhead is significant, then it's way faster than Tensorflow (unless you implement your own Tensorflow OP in C++/Cuda, but that's way more painful than just implementing it directly in Flux/Julia). It's hence quite nice for research on new architectures. Flux's autodiff also handles more language features…

> unless you implement your own Tensorflow OP in C++/Cuda I don't know exactly what 'OP' means, but there are other ways to do ML in for example C++. I have some good experience with dlib, PyTorch's libtorch is on my todo list.

>I don't know exactly what 'OP' means, but there are other ways to do ML in for example C++.

I think Flux really excels when you're trying to do ML as "differentiable programming" (e.g. model-based reinforcement learning), because it can differentiate so much control flow via Zygote, which hooks into the compiler and differentiates the AST: https://github.com/FluxML/Zygote.jl

Re: Julia 1.4

#28

Post by pjmlp »

m4r35n357 wrote: post #14
tomerbd wrote: post #12

Earlier quoted context omitted.

I have to admit that over the past 20 years, java is like the most stable robust, huge project, multiple teams, IDE friendly, type safe, infinite tooling and libraries language of choice!

Not too surprising. Java was _designed_ by ex Unix engineers at a time that the word "engineer" meant something. Now we have the cloud/web stack and _Javascript_. The bar was low enough for Julia to sound good at the start, but it gives the impression of being "designed" "on-the-fly".

Luckily in some parts of the world engineer still means something by law, even in informatics, and one is not allowed to use it just because they went through a six weeks programming bootcamp.

Re: Julia 1.4

#29

Post by ddragon »

signaru wrote: post #7

I wish it had more dedicated IDE besides the atom/electron based ones (like GNU Octave has its own). I think Julia's performance deserves an equally performant IDE.

I don't really have issues with the performance of Visual Studio Code even though it's electron, but with Julia I mostly use it for the syntax highlighting, linting and autocompletion (plus version control and other external tools). I find it much easier to have a Julia instance running on a drop down terminal or in the second monitor for easy access, Revise so every file I save is automatically loaded in the REPL session and some extras like Rebugger, Infiltrator and OhMyREPL for debugging and some niceties.

This way I can just immediately query and test things using the language itself without having to deal with any sort of constraints or quirks within the editors. And the Julia REPL allows for quickly switching to shell (just pressing ;) when needed. I would hope they keep improving the REPL (and the editor support features like linters) over focusing on a completely new IDE (there is even more potential when considering Lisp languages REPL, plus general usability improvements like first call latency), but I'm biased and that's not the workflow most developers use.

Re: Julia 1.4

#30

Post by the_monster »

m4r35n357 wrote: post #14
tomerbd wrote: post #12

Earlier quoted context omitted.

I have to admit that over the past 20 years, java is like the most stable robust, huge project, multiple teams, IDE friendly, type safe, infinite tooling and libraries language of choice!

Not too surprising. Java was _designed_ by ex Unix engineers at a time that the word "engineer" meant something. Now we have the cloud/web stack and _Javascript_. The bar was low enough for Julia to sound good at the start, but it gives the impression of being "designed" "on-the-fly".

Engineering implies scientific rigour and high intellect. So, no wonder software developers, usually a derided and mistreated collective, just love being called engineer...
Post reply on HN