Julia 1.0 • Hacker News Board

Re: Julia 1.0

#421

Post by ffriend » Fri, Aug 10, 2018, 11:52 PM UTC

marmaduke wrote: post #404

ffriend wrote: post #402

Earlier quoted context omitted.

I have quite limited experience with Cython and tried Numba just a couple of times, but I'm curious how much would it take to rewrite one of my Julia libraries to them. The library is for reverse-mode automatic differentiation, but let's put AD itself aside and talk about code generation. As an input to code generator, I have a computational graph (or "tape") - a list of functions connecting input and intermediate va…

> In Julia I follow the following steps: … does it fit with AST? I'm fairly certain the steps you've listed can be accomplished through AST manipulations, and would go something like def manip_ast(fn): import ast, inspect fn_ast = ast.parse(inspect.getsource(fn)) new_fn_ast = … return compile(new_fn_ast, …) def rewrite(fn): fn = manip_ast(fn) fn = numba.jit(fn) @rewrite def func(*args): … there's nothing in the langu…

> there's nothing in the language that prevents this from working with the autograd package, except no one's taken the time to implement it (https://github.com/HIPS/autograd/issues/47).

I believe it's more complicated than most posters there realize, especially in the context of PyTorch (which uses a fork of autograd under the hood) with its dynamic graphs... Anyway, AD deserves its own discussion, that's I didn't want to concentrate on it.

> I'd be interested in a side by side comparison as well, and I was thinking that the main difficulty would be that I couldn't write good Julia code, but maybe we can pair up, if that'd be interesting, to address several common topics that come up (fusion, broadcasting, generics but specialization, etc).

Sounds good! Do you have a task at hand that would involve all the topics and could be implemented in limited time? Maybe some kind of Monte Carlo simulation or Gibbs sampling to get started?

Re: Julia 1.0

#422

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

ChrisFoster wrote: post #288

marmaduke wrote: post #228

Earlier quoted context omitted.

What happens for that scientist when they have to dive into Julia’a stack to debug something weird? In Python and C, you have established debuggers, semantics etc, which means that, yes, there are two languages instead of one, but neither is a moving target compared to a language which just had a 1.0 release. I get the issue with scientists writing poor code, but Numba has largely solved this problem, by packing an L…

Sometimes low level debugging is a surprisingly pleasant experience as the julia JIT generates proper DWARF debug info. So for instance, you can break in gdb and see the julia source code for any julia generated stack frames, neatly intertwined with the frames of the C runtime. To be clear, I don't remember needing to do this as a regular user. As an occasional compiler hacker it's been quite nice though.

As someone who's spent decades programming in C/C++, and diving into assembly code (and writing a fair share when the compiler just couldn't do what I needed), I love being able to directly inspect the output code at many levels, including all the way down to "bare metal". Yes, there's a lot of work to be done in the area of debuggers for Julia, but there are already useful debugging tools (like Rebugger) that I haven't seen for any other language.

Re: Julia 1.0

#423

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

johnsea wrote: post #104

LittlePeter wrote: post #82

Every release I am downloading Julia and trying to wrestle through some tutorials. Every time (0.4.0, 0.6.0, 1.0.0) I get stuck at some error, usually during the pre-compiling of some dependency. For example, I have downloaded julia-1.0.0. I try to follow this tutorial here, linked in this post by someone: http://juliadb.org/latest/manual/tutorial.html Then I do this and get an error: julia> using JuliaDB [ Info: Pre…

> Every time (0.4.0, 0.6.0, 1.0.0) I get stuck You should have tried 0.4.2, 0.6.3, 1.0.1. Motto: Don't start too fast and be slow giving up ;-)

Yes, if you want stability, you should never use a x.0 or x.0.0 release (even from a big company - how many people remember Windows 3.0? ) I, however, am a bit crazy, and enjoy living on the bleeding edge, and so am up late tonight hacking making sure all my packages are working correctly on v1.0.0 of Julia!

Re: Julia 1.0

#424

Post by ScottPJones » Sat, Aug 11, 2018, 12:07 AM UTC

AriaMinaei wrote: post #155

StefanKarpinski wrote: post #150

Earlier quoted context omitted.

> Like, if you do type the arguments of a function, the optimising compiler will have less work to do. Giving types for function arguments doesn't actually have any effect on performance: the compiler specializes on concrete runtime argument types anyway, so completely untyped code is just as fast as fully type annotated code—since the types are known when the code is compiled. On the other hand, giving type informat…

Thanks for the correction!

I've actually seen many cases where overuse of concrete types (on function parameters) in Julia can lead to poor performance. For example, if functions are written declaring an argument as `Vector{Int64}`, and then people using the function end up calling `collect` (and causing a lot of memory allocations), when they had a value that was an iterator and were forced to convert it into a vector just to call the function. Simply leaving off the `::Vector{Int64}` and getting rid of the `collect` on the caller speeds things up nicely.

Re: Julia 1.0

#425

Post by tavert » Sat, Aug 11, 2018, 1:09 AM UTC

ScottPJones wrote: post #417

tavert wrote: post #349

Earlier quoted context omitted.

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…

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 in the base language have been deleted during 0.7-DEV because a single core developer didn't like them, despite multiple other core developers voicing disagreement that the features were useful and removing them was not urgent or necessary.

It's not a development culture I would rely on when products and money and jobs are at stake. Even the startup you were working with abandoned julia, correct?

Re: Julia 1.0

#426

Post by dnbgfher » Sat, Aug 11, 2018, 5:29 AM UTC

iamed2 wrote: post #369

dnbgfher wrote: post #343

I'm sure this is too late to get much visibility, but I recently looked into using Julia (for my MS thesis) and found it sorely lacking in one major way that I found unforgivable. Their type system is pretty interesting, and allows for some really cool abilities to parameterize things using types. I'd like to have seen more work done on, effectively, strong typedefs (or whatever $lang wants to call them). However tha…

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 action. Part of that means ensuring the built-in types make use of this.

Related to all of this, I worry it's too late to really make a meaningful change here. The culture and existing packages are already set without it. Adding the feature as a requirement isn't going to happen anytime soon unless people are willing to continue to break things post 1.0. And it needs to be a requirement or it won't get used except by people that will already provide documentation.

The lack of interest I mentioned mainly came from some github issues which either received little attention, had creators that had a very "maybe it would be nice if" attitude, and responses that were questioning the benefit compared to the cost of implementing the syntax changes.

Re: Julia 1.0

#427

Post by dnbgfher » Sat, Aug 11, 2018, 5:43 AM UTC

ChrisFoster wrote: post #352

dnbgfher wrote: post #343

I'm sure this is too late to get much visibility, but I recently looked into using Julia (for my MS thesis) and found it sorely lacking in one major way that I found unforgivable. Their type system is pretty interesting, and allows for some really cool abilities to parameterize things using types. I'd like to have seen more work done on, effectively, strong typedefs (or whatever $lang wants to call them). However tha…

It's not that people are uninterested; it's more that inventing a system for specifying and enforcing these kind of generic interfaces is a really hard design problem. As a comparison, consider that the C++ standards body has been working on, debating and serially rejecting the various "C++ concepts" proposals for years now.

This is not that hard of a problem to solve to a useful level.

If you want to get fancier, yeah, it gets hard. But something as simple as a syntax block that lists the interface methods would be enough for now.

The fancier stuff is already projected so far out to at least 2.0 that I don't understand why a simple working solution wouldn't be desired for now. It would also simplify the work of changing code later to work with 2.0.

I really don't understand how this issue wasn't addressed a long time ago, and why it wasn't a blocker for 1.0.

Re: Julia 1.0

#428

Post by marmaduke » Sat, Aug 11, 2018, 6:24 AM UTC

Certhas wrote: post #411

marmaduke wrote: post #407

Earlier quoted context omitted.

> 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.

I’m not ignoring anything, but trying to evaluate whether Julia will be worth supporting as the N+1 scientific stack in the lab I work for, and what to recommend to incoming students and people who consider getting off of MATLAB.

I think Julia looks very sexy and students jump on that, often without considering whether they will be their actual work done or spend time porting libs or debugging things I can’t help them with.

Re: Julia 1.0

#429

Post by marmaduke » Sat, Aug 11, 2018, 6:27 AM UTC

Certhas wrote: post #413

marmaduke wrote: post #406

Earlier quoted context omitted.

> 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 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.

Re: Julia 1.0

#430

Post by Certhas » Sat, Aug 11, 2018, 8:33 AM UTC

marmaduke wrote: post #428

Certhas wrote: post #411

Earlier quoted context omitted.

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.

I’m not ignoring anything, but trying to evaluate whether Julia will be worth supporting as the N+1 scientific stack in the lab I work for, and what to recommend to incoming students and people who consider getting off of MATLAB. I think Julia looks very sexy and students jump on that, often without considering whether they will be their actual work done or spend time porting libs or debugging things I can’t help the…

I was worried about the same. I think it's a valid reason to sit back and wait. Especially if Numba works for you.

I was also and continue to be worried about the tooling, the lack of good tutorials and especially the Type driven system. I like it so far but Object Oriented is a lot more familiar to many people. The library situation for me specifically has tipped to be a net positive. I also could transition my very small team off Python completely.

So it was not an ad hoc decision, I tried it several times over the last year's and decided it's not there. In my specific situation, with a rewrite of a core library coming up and the library situation being there that changed early this year.