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

Julia 1.0

julialang.org

Post reply on HN
Print view View original

431–440 of 446 posts

Re: Julia 1.0

#431

Post by Certhas »

marmaduke wrote: post #429
Certhas wrote: post #413

Earlier quoted context omitted.

This pattern is how I wrote the SDE solver in Python. That works great and is really useful and the reason why I teach closures. The library we're building now though does something different. Something like this: def network_rhs(fs, Network) def rhs(y,t) y2 = np.dot(Network, y) r = empty_like(y) for i, f in enumerate(fs): r[i] = f(y2[i]) return r return rhs > what did you run into that was problematic? For more comp…

I see what you mean. I’ve done exactly that sort of thing in C with an array of function pointers, but I’m not sure it would work in Numba. The churn is exhausting but I see the merit of starting over and getting everything done in a fully fledged JITd language.

As said in another part of the thread, we were in a very good spot to do so. There absolutely are many reasons to not jump in at this time.

Re: Julia 1.0

#432

Post by sgt101 »

sgt101 wrote: post #96
ChrisFoster wrote: post #29

Earlier quoted context omitted.

Dependency management for packages just got hugely better with the release of Pkg3 (now simply Pkg) as part of 0.7 / 1.0.

yes - 0.7 and the rigorous and (at a glance) hard to break system were a big thing for me; I've spent so many hours trying to make code tree A compile with code tree B in so many different languages in the past...

A few days later : ] is great, love it... just a shame so many major packages are broken!

Re: Julia 1.0

#433

Post by Certhas »

mlthoughts2018 wrote: post #415
Certhas wrote: post #363

Earlier quoted context omitted.

1. You're talking to the author. 2. The quoted text talks exactly about separate compilation, like the comments above do. So it's really unclear where you take offense. Maybe read it again carefully? 3. I have championed numba for a long time, and am now happy to jump to Julia, for pretty much those reasons. I have implemented time critical parts of the code in numba, and that has forced me to reimplement a whole bun…

I’m not clear on why you being the author is supposed to matter. There’s a direct, unambiguous quote (of your own writing) that disagrees with what you are saying here. I don’t care who wrote it, only that your opinions here in the comments are not consistent with the actual linked post. Authors can have inconsistent opinions, and can sometimes try to retroactively reinterpret something they wrote to serve a differen…

I'm not the author, the guy you're replying to is. The article that you quote says that crossing function barriers and joint compilation are issues with numba and cython. So does the comment you were replying to. You've failed to articulate where the perceived discrepancy is.

Re: Julia 1.0

#434

Post by ChrisRackauckas »

dnbgfher wrote: post #426
iamed2 wrote: post #369

Earlier quoted context omitted.

This is truly an important issue. Right now, every interface represents something that needs to be documented by the author. The AbstractArray and Iteration interfaces are well-documented, but the AbstractDict interface isn't. I believe that documentation for an interface is enough, but I also don't think enough people will take the time to write it. So I agree there should be a technical solution. The main reason th…

I think you need language changes no matter what. I've seen some of the previous trait packages and while extremely cool, they're insufficent for tackling this problem for a couple reasons. First, this extends deep into the core of Julia, and I don't see how a traits package would be involved with that. Second, and this dovetails with the first issue, this needs to be something that people actually use as a default a…

>First, this extends deep into the core of Julia, and I don't see how a traits package would be involved with that.

No, Tim Holy described over dinner how all that was necessary to complete the existing traits packages was method deletion, and that's in v1.0.

Re: Julia 1.0

#435

Post by SolarNet »

ur-whale wrote: post #193
SolarNet wrote: post #184

Earlier quoted context omitted.

Ok, then use the built in Julia features to use any offset you want inside your algorithm's code. Compilers are pretty good about optimizing integer constants.

Everyone in this thread seems to believe that 1-based indices is a non-problem because Julia "offers a choice". My reaction: - the default is 1-based, which means the bulk of Julia code will adopt the convention and therefore the vast majority of coders in 2018 will have to do mental gymnastics to understand what the code does. - when I read Julia code, I will never know which convention the code was written with unl…

I think you misunderstand that the offset is encoded in the type of the object, so only your 1st concern is valid.

For concern 2, it's as easy as finding the type. And without knowing the types you wouldn't know what the code did anyway.

For concern 3, a type error.

And for 4, because it's a type there is zero runtime overhead. A view of the array with the offset the code expects is constructed, often automatically based on the types involved. This view is often a zero cost abstraction at runtime because of how Julia specialization works. So at worst you pay some (extremely minor) compile-time/load-time costs.

Re: Julia 1.0

#436

Post by dnbgfher »

ChrisRackauckas wrote: post #434
dnbgfher wrote: post #426

Earlier quoted context omitted.

I think you need language changes no matter what. I've seen some of the previous trait packages and while extremely cool, they're insufficent for tackling this problem for a couple reasons. First, this extends deep into the core of Julia, and I don't see how a traits package would be involved with that. Second, and this dovetails with the first issue, this needs to be something that people actually use as a default a…

>First, this extends deep into the core of Julia, and I don't see how a traits package would be involved with that. No, Tim Holy described over dinner how all that was necessary to complete the existing traits packages was method deletion, and that's in v1.0.

Interesting.

But as an external package it still has the issues I described as not being part of the defaults of the culture. Without that it just becomes a nice-to-have that only people serious about writing good quality, usable code are going to use. And these are the people most likely to have good documentation in any case.

Re: Julia 1.0

#437

Post by ChrisRackauckas »

dnbgfher wrote: post #436
ChrisRackauckas wrote: post #434

Earlier quoted context omitted.

>First, this extends deep into the core of Julia, and I don't see how a traits package would be involved with that. No, Tim Holy described over dinner how all that was necessary to complete the existing traits packages was method deletion, and that's in v1.0.

Interesting. But as an external package it still has the issues I described as not being part of the defaults of the culture. Without that it just becomes a nice-to-have that only people serious about writing good quality, usable code are going to use. And these are the people most likely to have good documentation in any case.

Yes indeed, but the cultural issue can be addressed by adding it into Base in a 1.x since it's not breaking. I don't think it will make it into a 1.x though but it can.

Re: Julia 1.0

#438

Post by cmroanirgo »

Please forgive my ignorance, but does it compile to a binary and can it be targeted to a different platform than the current one? eg. Can I make for OSX, Windows, Android, etc?

The best documentation I can find is this article, but it seems a bit spartan on how-to: https://medium.com/@sdanisch/compiling-julia-binaries-ddd6d4...

Re: Julia 1.0

#439

Post by ismael_vc »

tavert wrote: post #425
ScottPJones wrote: post #417

Earlier quoted context omitted.

I complained also about the "cowboy" culture I saw among the Julia developers when I first started with it (people making a change directly to master, or merging there own PR without giving time for people around the world to review, or not having a minimum number of qualified reviewers before merging), but those days are gone, and I feel they've matured quite a lot in the past few years in that respect. Some of it I…

Just in the last few months BinDeps was broken by a "deprecation fix" that was completely wrong and using a name that didn't exist, and it got merged and released by the patch author before anyone else could look at it, breaking many downstream packages. Refactorings and major changes in ZMQ.jl and the web stack similarly get merged and released immediately with zero review, still. This is a major problem. Features i…

I was not expecting the change to MDD (Marketing Driven Development) at the last minute. But at least 1.0 is out, I hope those wild west times, get past far behind us now. I'll wait for Julia 1.1 and most packages at 1.0 before diving back in.

Re: Julia 1.0

#440

Post by ksaitor »

> We want the speed of C with the dynamism of Ruby. We want a language that’s homoiconic, with true macros like Lisp, but with obvious, familiar mathematical notation like Matlab. We want something as usable for general programming as Python, as easy for statistics as R, as natural for string processing as Perl, as powerful for linear algebra as Matlab, as good at gluing programs together as the shell.

… they forgot to compare Julia to JavaScript — the most popular programming language in the world.

Or is that because authors don't want Julia to be used by anyone?

¯\_(ツ)_/¯

[I'm joking, ofc. But I still find it weird how almost every modern language is mentioned, but JavaScript…]

Post reply on HN