Julia 1.0 • Hacker News Board

Re: Julia 1.0

#411

Post by Certhas » Fri, Aug 10, 2018, 10:43 PM UTC

marmaduke wrote: post #407

Certhas wrote: post #380

Earlier quoted context omitted.

That's the problem: You're locked into one particular library. You can not combine libraries without sacrificing massive performance. There is just no way around that. The numba story in that github issue mirrors my own experience: Excitement! This works! It's fast! Ok here are some limitations that I can work around. Hmm I would really like to use this library, in principle it should be possible to JIT its output/ma…

> That's the problem: You're locked into one particular library. But that's not a issue resolved by any particular language; Julia appears to be free of lock-in because it hasn't had time to develop multiple, exclusive approaches to the same problems. Perhaps Julia builds into the language the ultimate performance solutions, so ok, then, for example, wait until there are N different web frameworks, and there you will…

Well I'm not a grad student, but my grad students were happy to switch, too. :) I think you are ignoring the structural reasons why Python has to lead to silos, and that these reasons are addressed in Julia. But in the end, time will tell.

Re: Julia 1.0

#412

Post by Certhas » Fri, Aug 10, 2018, 10:48 PM UTC

mlthoughts2018 wrote: post #401

Certhas wrote: post #384

Earlier quoted context omitted.

I have a data structure based on which I generate a dynamical behaviour that I want to integrate. So I construct a rhs. I further want the user of the library be able to pass it new functions that can be integrated into overall dynamical behaviour. There are different ways to achieve this, the simplest version is with closures. Pass a list of functions, and some parameters and I construct a right hand side function f…

This just sounds like bad software designto me. You are miswanting something overly generic that’s super not needed, and regardless of implementing in any given language, it sounds like it would benefit hugely from taking a more YAGNI approach to it, restricting its genericity based on likely usage (not intended or imagined usage), and either just manually writing stuff for an exhaustive set of use cases, or code gen…

You don't know my use case, and you are not right. I have a network of heterogeneous interacting nodes with quite different dynamics on the nodes. I pay great attention to YAGNI, and constantly tell my students and colleagues to cut enerality and work from the specific case outward. But this is just essential complexity of the problem domain. I've spent years implementing the concrete cases, I know what research we couldn't and didn't do because it was to painful to do by hand, and this is the minimum level of generality I can get away with.

I have ideas for a more general library of course, :P But I'm not spending time on them.

Re: Julia 1.0

#413

Post by Certhas » Fri, Aug 10, 2018, 11:13 PM UTC

marmaduke wrote: post #406

Certhas wrote: post #384

Earlier quoted context omitted.

I have a data structure based on which I generate a dynamical behaviour that I want to integrate. So I construct a rhs. I further want the user of the library be able to pass it new functions that can be integrated into overall dynamical behaviour. There are different ways to achieve this, the simplest version is with closures. Pass a list of functions, and some parameters and I construct a right hand side function f…

> With DifferentialEquations.jl I also could just yep... I took a look at the DE packages in Julia today, and quite frankly they're much better than the situation in Python, perhaps because of one or more prolific applied mathematicians are making a concerted effort, which is lacking Python? I dunno, but I did recommend my colleagues look at Julia for DEs, for this reason. That said, > Pass a list of functions, and s…

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 complex model building the right hand side functions actually make use of fairly complex class hierarchies. That was the major stumbling block. But people also were using dictionaries and other non-numpy data structures and just generally idiomatic Python that is not always supported. Some of that stuff is inherently slow/bad design of course, but it still ended up killing the use of my solver for this project.

They are now rewriting in C++, which is absolutely a great choice for their case (and probably would have been viable for us too if we had had more people with a C/C++ background in the team).

> passing @numba.jit'd functions to scipy is in the Numba guide

I wanted to use scipy.root from numba. Not the other way around.

Now if all of the numerical Python community was standardized on numba, a lot of this would not be an issue. Scipys LowLevelCallable is a great step in the right direction. But fundamentally I don't see how you will ever get the different libraries to play together nicely in a performant way. It would require every API to expose numba jitable functions. Last I checked, the only functions you could call from within numba code were other numba functions and the handful of numpy features the numba authors implemented themselves (I remember waiting for dot and inv support). If I have an algorithm by a student implemented on a networkx graph as a data structure I can't just jit that. In Julia it automatically is.

Re: Julia 1.0

#414

Post by ScottPJones » Fri, Aug 10, 2018, 11:16 PM UTC

Q6T46nT668w6i3m wrote: post #44

bsdubernerd wrote: post #39

I'm a quite happy Julia user, however I feel there are still some warts in the language that should have warranted a bit more time before banging 1.0 on the badge. Exception handling in julia is poor, which reminds me of how exceptions are (not/poorly) handled in R. Code can trap exceptions, but not directly by type as you _would_ expect. Instead, the user is left to check the type of the exception in the catch block…

Yeah, I agree with your comments about error handling. It’s far from ideal in non-interactive contexts. It’s especially disappointing since you could easily imagine something like Julia replicating Python’s success at transitioning code from interaction (e.g. Jupyter notebook) to production. I initially defended the choice, but I now agree that 1-based indexing now seems like a poor choice since Julia has become some…

Three years ago, when I found out about Julia (and quickly fell in love with the language), I not happy at all about the 1-based indices and column-major storage, and at the time, a lot of the responses I got were along the lines of "Julia is for mathematicians, and 1-based indexing and column major are just fine for us". Now, Julia is able to have indices with any base that you want, and can handle row-major storage as well (thanks to Tim Holy's great work). Why is anybody concerned about this anymore? Julia can do whatever you want, you shouldn't be stuck with languages that can ONLY do 0-based indexing.

Re: Julia 1.0

#415

Post by mlthoughts2018 » Fri, Aug 10, 2018, 11:24 PM UTC

Certhas wrote: post #363

mlthoughts2018 wrote: post #334

Earlier quoted context omitted.

This is a quote from the link: > “It's not hard to get a loop written in terms of simple basics (well okay, it is quite hard but I mean "not hard" as in "give enough programmers a bunch of time and they'll get it right"). Cool, we're all the same. And microbenchmark comparisons between Cython/Numba/Julia will point out 5% gains here and 2% losses here and try to extrapolate to how that means entire package ecosystems…

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 different purpose later on. That is happening here. It’s not a big deal; I’m just saying for this reason I don’t agree with your claims about my comments, nor your overall comments about numba (even after re-reading your link and comments and deliberately reflecting on them).

Re: Julia 1.0

#416

Post by ChrisRackauckas » Fri, Aug 10, 2018, 11:26 PM UTC

CyberDildonics wrote: post #395

ChrisRackauckas wrote: post #304

Earlier quoted context omitted.

Fun fact, the GC really isn't an issue and instead the opposite issue was found. There had to be callbacks built to slow down the computations for the robotics simulations in order to get it to run at real-time because it was too fast. https://github.com/JuliaRobotics/RigidBodySim.jl/blob/34ac43... Notice that this function is purposefully sleeping the differential equation solver in order to slow it down to the exac…

That's a very amateurish way to solve this problem. Games typically have a main loop which will check the amount of time that has passed on every iteration of the loop. You can see how much extra time is left for that frame at the targeted frame rate, then sleep for that amount of time. Then you never have to slow down anything else, you can set a maximum amount of cycles per second and you can sleep once per cycle.…

Interesting to hear. This just isn't a thing I think is ever encountered in this kind of stuff. The author's previous struggle was to get to real-time. Getting below it wasn't something they really considered. Here's a talk they gave:

https://www.youtube.com/watch?v=dmWQtI3DFFo

Re: Julia 1.0

#417

Post by ScottPJones » Fri, Aug 10, 2018, 11:34 PM UTC

tavert wrote: post #349

simonbyrne wrote: post #314

Earlier quoted context omitted.

Out of curiosity: what language has a package ecosystem that in your opinion does do this right?

Large Apache projects, notable widely-used c++ projects like boost, llvm, zmq, cmake, the c++ language standards committee itself, all take their time and rarely if ever release changes/bugfixes immediately. Things go through review, testing, release candidates, and people other than original authors of code provide input before normal users get their hands on anything. The core pydata projects take their time and ar…

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 think was simply the great excitement that comes from being able to be so creative with the language, and a rush to get things figured out and nailed down to finally get to v1.0. As far as projects in other languages, I don't really feel it has much to do with the languages themselves, more the type of people that particular project attracts.

Re: Julia 1.0

#418

Post by ScottPJones » Fri, Aug 10, 2018, 11:45 PM UTC

simonbyrne wrote: post #319

jhayward wrote: post #252

Earlier quoted context omitted.

Industry gets professional programmers by hiring people who have been hammering out shipping code in paying products for years, and years, doing support, maintenance, and new product development and research. Grad students may be brilliant but that does not help give them any insight in to what makes a good ecosystem, toolchain, and feature set good.

We would love to have more professional programmers contribute: unfortunately those 1-based indices put them off. More seriously: part of the problem does seem to be that Julia does have some significant differences from "traditional" languages (e.g. the concept of a "virtual method" is a bit fuzzy in Julia, what we call a JIT is probably better described as a JAOT, whether it has a "type system", homoiconicity, etc.…

I've seen quite an evolution over the past 3.4 years I've been using Julia and the 4 JuliaCon's I've attended so far. Back at the 2015 JuliaCon, a number of us "older" professional programmers felt like we should stage a palace coup, because it did feel like the input of people who had "been around the block" a few times was not really valued. That's changed quite a lot (maybe because in the intervening years many of the core contributors have gotten their Ph.D.s and are having to live off their blood, sweat, and tears (plus lots of joy, to be sure) of producing things with Julia that people will actually pay money for). Yes, it was young and brash, but those awkward years seem to be past, and I feel the future of Julia is quite bright.

Re: Julia 1.0

#419

Post by ChrisRackauckas » Fri, Aug 10, 2018, 11:47 PM UTC

marmaduke wrote: post #408

ChrisRackauckas wrote: post #360

Earlier quoted context omitted.

SciPy's solvers cannot handle events which are nearby, most return codes aren't documented, you cannot run the wrapped solvers in stepping control mode, you cannot give it a linear solver routine, etc. So it wraps established solvers but still only gives the very basic solving feature of it, and most of the details that made the methods famous are not actually available from SciPy's interface. And it wasn't Python 3…

You mentioned Python 3, not me. Btw, I did look through your DE packages, and they are definitely an amazing contribution not seen in Python; I've recommend to colleagues.

>You mentioned Python 3, not me.

Yeah sorry, I was just acknowledging that I was wrong when I found the PR and noticed the mistake. I guess it come across oddly.

Re: Julia 1.0

#420

Post by ChrisRackauckas » Fri, Aug 10, 2018, 11:51 PM UTC

marmaduke wrote: post #377

ChrisRackauckas wrote: post #361

Earlier quoted context omitted.

Generic functions in Julia can use types which have no reference to their definition using dependent compilation. http://www.stochasticlifestyle.com/why-numba-and-cython-are-... So you can work with types even when you've never seen their definition given how the compilation will occur with all of the pieces together instead of separately.

I usually profit from type definitions during debugging and memory layout work, so perhaps i don’t see this is a feature.

It's probably us that are using types in a weird way so it's my lack of explanation that's the issue. Types in Julia undergo multiple dispatch, so by passing a type into a generic function you can make the same generic algorithm run in different ways. So I use types to parallelize my code, calculate derivatives, propagate parameter uncertainties, and things like that. This talk from JuliaCon discusses a lot of the things for free that were developed by taking a type from one package and putting it into another:

https://www.youtube.com/watch?v=dmWQtI3DFFo