Live data from Hacker News

Julia adoption keeps climbing

hpcwire.com

241–250 of 309 posts

Re: Julia adoption keeps climbing

#241
post #223

Earlier quoted context omitted.

I'm using Julia (because of the hype) to prototype out some numerical optimization stuff. There is a million functions for reshaping multidimensional arrays. The syntax is uncannily like Matlab: retrieving the last element of an array with `[end]`, indexing into a collection with an array of booleans, element-wise versions of operators prepended with dot, etc. However, I keep running into niggling corner cases that k…

For the last thing, is this what you want? https://github.com/JuliaArrays/PaddedViews.jl There may be other packages or methods for doing the other things you want. I’d think that broadcasting over a NamedTuple would iterate over the key => value pairs, but I haven’t tried it.

Thanks for the good find!

Re: Julia adoption keeps climbing

#242
post #46

Python has a battle-tested, humongous standard library, and a rich ecosystem. It is easy to learn and it's great at gluing every day stuff. Data scientists like it, engineers like it, even the cashier at Lidl likes it. I can see how Julia may challenge Python for academic use, but challenging Python in 2021 for industrial use is no joke.

> Python has a battle-tested, humongous standard library, and a rich ecosystem

Use it then: https://github.com/JuliaPy/PyCall.jl

Re: Julia adoption keeps climbing

#243

Earlier quoted context omitted.

As sibling posts have pointed out, you can do all of those things: 1. You can trivially write a `getproperty` method for a tuple. It is considered to be type piracy and thus runs the risk of colliding with someone else's definition, but the language absolutely lets you do it. 2. You can broadcast over the fields of a `NamedTuple` by defining appropriate methods. Again, it's type piracy, so take that into consideratio…

I meant literally this: julia> (x = 1, y = 2) .+ (x = 1, y = 2) ERROR: ArgumentError: broadcasting over dictionaries and `NamedTuple`s is reserved

Stefan's point was that you are free to commit type piracy and make this do whatever you want

  julia> Base.broadcasted(f, x::NamedTuple, y::NamedTuple) = "my custom method!"

  julia> (x=1, y=2) .+ (x=1, y=2)
  "my custom method!"

Re: Julia adoption keeps climbing

#244
post #9

I tested my well-optimised R code and saw only 3x to 10x performance gain. That's still not substantial enough currently to migrate a whole code base, in particular given that the libraries are also still not mature enough. The research group I'm working with also have no interest in adopting anything new, In fact most of our code is still in FORTRAN so that is something I would be more interested in migrating to Jul…

Realistically, how much did you expect over mature R libraries or Fortran? 1000x or 10_000x? I'd consider 3-10x a major gain.

Re: Julia adoption keeps climbing

#245
post #163

Earlier quoted context omitted.

Agreed on error handling actually. It doesn't quite have the feel that it should in a modern language. I think error handling and lifetimes/mutability are two of the top things we're looking at for a fundamental remodel in 2.0.

What about traits or multiple inheritance?

That's more on the "nice to have" list (at least from my perspective - others may have different opinions).

Re: Julia adoption keeps climbing

#246

Earlier quoted context omitted.

I meant literally this: julia> (x = 1, y = 2) .+ (x = 1, y = 2) ERROR: ArgumentError: broadcasting over dictionaries and `NamedTuple`s is reserved

Stefan's point was that you are free to commit type piracy and make this do whatever you want julia> Base.broadcasted(f, x::NamedTuple, y::NamedTuple) = "my custom method!" julia> (x=1, y=2) .+ (x=1, y=2) "my custom method!"

And as the phrase "reserved" in the error message indicates, it will likely be given a meaning once all the ramifications of doing so are worked out and the best choice of meaning is decided upon. If you're impatient and don't want to wait for that, define it to do what you want. Your code won't even break when it is given an official behavior since your method will overwrite the built-in one.

Re: Julia adoption keeps climbing

#247

Can anyone recommend some good resources to learn Julia? I am hoping there is something akin to the Rust Book [1] since watching youtube videos is too slow and the exercism option listed on the website is too cumbersome. [1] https://doc.rust-lang.org/book/

This might be helpful: https://benlauwens.github.io/ThinkJulia.jl/latest/book.html

This is perfect, thank you so much!

I'm a bit surprised julialang.org only links to a the oreilly store page. Seems like you would want to call attention to a resource like this.

Re: Julia adoption keeps climbing

#248

The comparison between different languages gets tiring when it focuses on making a black-and-white statement like "Julia is better" or "Python is better" and "x is never going to overtake y". Yes, Python has many more libraries thanks to it being much older than Julia, same for R. But at the same time, Julia can be used for impressive work that R/Python struggle with and which only seem solvable in these languages be…

While I generally agree with your argument, it's worth noting that the median Julia programmer is probably more invested in the language/ecosystem than the median R/Python programmer.

Back in the mid-90's Java was the new hotness, and it probably made problems that required 100+ lines of C easier, but it's not still full of above-average programmers, as any language/ecosystem that achieves success will inevitably regress to the mean.

Re: Julia adoption keeps climbing

#249
post #228

Earlier quoted context omitted.

Urg that website is so incredibly out of date. Julia has amazing things for autodiff. But like not the things listed on that website. Also python is still doing great with Jax and PyTorch.

I linked to the website (which was updated in May, but its contents could do with more work) because it has examples of how well the suite fits together. I don't know much about Jax. I've seen competent benchmarks showing an order of magnitude benefit for using ReverseDiff from the AutoDiff suite over Autograd, which is what Pytorch uses for reverse-mode autodiff

It was update in May to fix that the CDN changed. The actual content hasn't been updated in 7 years.

It really should be updated to have basically the content of this thread https://discourse.julialang.org/t/state-of-automatic-differe...

Re: Julia adoption keeps climbing

#250

Earlier quoted context omitted.

Stefan's point was that you are free to commit type piracy and make this do whatever you want julia> Base.broadcasted(f, x::NamedTuple, y::NamedTuple) = "my custom method!" julia> (x=1, y=2) .+ (x=1, y=2) "my custom method!"

And as the phrase "reserved" in the error message indicates, it will likely be given a meaning once all the ramifications of doing so are worked out and the best choice of meaning is decided upon. If you're impatient and don't want to wait for that, define it to do what you want. Your code won't even break when it is given an official behavior since your method will overwrite the built-in one.

But this is exactly the kind of thing I called a bothersome corner case. Needing to redefine a global function in order to use fairly intuitive behavior is not great developer experience.
Post reply on HN