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

41–50 of 137 posts

Re: Julia 1.4

#41

Post by ced »

logicallee wrote: post #25
ced wrote: post #18

Earlier quoted context omitted.

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?

See this issue: https://github.com/JuliaLang/julia/issues/30653#issuecomment...

Memory leak. As explained, it's not really Julia's fault.

This I also found amazing: https://github.com/JuliaLang/julia/issues/28726 . It took 4 hours to go from bug report about bad compiler code generation to a patch.

Re: Julia 1.4

#42

Post by komuher »

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…

Ok let me get it here cause there are a lot of misunderstanding my post on top.

Swift have built in simd same about Rust https://github.com/apple/swift-evolution/blob/master/proposa...

Nim have arraymancer https://github.com/mratsim/Arraymancer

@inbounds it is just compiler option u can use it in any language with LLVM backend i would be suprised if Julia will be faster then Rust/Swift or Nim in this regard. But True about GO in that particular case.

Re: Julia 1.4

#43

Post by komuher »

ViralBShah wrote: post #36
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 :)

Providing a well functioning BLAS experience in a language is a non-trivial task. Saying "just use lib" seems to severely understate this. How many go or swift or Nim issues discuss matmul vs the Julia repo?

Nim have Arraymancer https://github.com/mratsim/Arraymancer sure it isn't easy but still most of top dogs have some libs supporting BLAS/CUDA etc.

Re: Julia 1.4

#44

Post by komuher »

the_monster wrote: post #34
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 :)

Please double check your grammar before posting

Sorry im not native :( I tried my best

Re: Julia 1.4

#45

Post by greendave »

The language has a lot of really nice stuff and the introduction of threads and support for them in the standard libraries (beginning in 1.3) has helped us a lot.

That said, the tooling is still frustrating. Generating compiled binaries is a slow, painful process.

Re: Julia 1.4

#46

Post by logicchains »

komuher wrote: post #42
logicchains wrote: post #38

Earlier quoted context omitted.

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…

Ok let me get it here cause there are a lot of misunderstanding my post on top. Swift have built in simd same about Rust https://github.com/apple/swift-evolution/blob/master/proposa... Nim have arraymancer https://github.com/mratsim/Arraymancer @inbounds it is just compiler option u can use it in any language with LLVM backend i would be suprised if Julia will be faster then Rust/Swift or Nim in this regard. But True…

>@inbounds it is just compiler option u can use it in any language with LLVM backend i would be suprised if Julia will be faster then Rust/Swift or Nim in this regard.

I agree it wouldn't necessarily be faster, but it also wouldn't be slower. Plus in Rust at least disabling bounds checks requires marking code as unsafe, which really gets the community's hackles up.

Re: Julia 1.4

#47

Post by KenoFischer »

dilap wrote: post #39
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's natural that you'll get publicity and curious onlookers when doing new releases -- might be worth considering that natural audience, too, when writing the NEWS file.

Right, we're of course aware of that audience, which is why I posted that comment. The way the NEWS file gets written is just that each individual commit that makes a change that needs end user attention will add an entry in the relevant section. This is quite hand as people can just 'git blame' the file and automatically find a link to the relevant commit (or they can click through the linked issue). What's missing is a more high level narrative structure of changes in the release, but such a thing would have to be written once the release is done. Usually we do that in the form of a blog post announcing the release. However, invariably, these things end up on HN the second somebody thinks the release is done (or even just for early RCs).

Re: Julia 1.4

#48

Post by ViralBShah »

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…

Sorry to hear that. I do hope you filed issues or chimed in on existing issues. On deep learning, Flux has a different flexible approach. This is great for certain people. For people who want a library of existing models, Julia can already call TensorFlow and we didn't see the need to reinvent Tensorflow.

Re: Julia 1.4

#50

Post by ViralBShah »

komuher wrote: post #31
logicchains wrote: post #20

Earlier quoted context omitted.

> near stable and/or fast as any other "new" languages (RUST, Nim, Golang, even Swift) This is not my experience, at least for numeric code. It generates faster code than Golang, because it uses an LLVM backend (and actually supports macros and parametric polymorphism, so doesn't need to do the work at runtime), faster numeric code than Rust via @inbounds and @simd annotations (way more work to disable bounds checks…

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

I'm having a hard time trying to follow your argument. You seem to have had some issues with Julia, and I would like to take those issues at face value. It would be nice if you could point to specific issues since we always like to fix things.

However, in response to discussion about Julia having an integrated set of abstractions that provide high performance - you are discussing a collection of features in Rust, Go, Swift, Nim, TensorFlow, Jax, PyTorch, etc. For any single feature, there can always be some other thing that does it better. But it is unclear how that makes one system better than another.

Post reply on HN