Live data from Hacker News

Julia 1.0

julialang.org

371–380 of 446 posts

Re: Julia 1.0

#371
post #291

Earlier quoted context omitted.

Agreed. Even better if they had code snippets that highlights what makes the language cool (instead of the usual "Hello World").

what is "cool" is very person specific though. It's hard to fully appreciate multiple dispatch in 8 lines for example

I found https://giordano.github.io/blog/2017-11-03-rock-paper-scisso... to be a pretty good attempt at that. Of course, the code's elegance will probably not be immediately evident to a beginner, but a link to the full explanation could suffice to complement that.

Re: Julia 1.0

#372

Earlier quoted context omitted.

The blog mentions that Julia is supposed to be a general purpose language, and not a language built specifically for scientific computing. Is that wrong? The first impression does leave me thinking that using Julia for different programming domains like distributed internet-facing servers or web services is not something it was built for.

My sense has been it's designed specifically to be the best language for scientific and mathematical computing, but also a general purpose language in the sense you don't have to switch languages when you need to incorporate into a web service or a GUI tool or text munging. So like Python, you have SciPy Pandas etc. but don't have to leave Python when you need to do a bunch of text processing or whatever.

Big difference being that most of the packages in Julia are written in Julia itself (unlike Python, where they're often written in some more performant language); so the aspiration is that you have to leave Julia even less frequently than you have to leave Python.

At the same time, calling into other languages (eg C) is super straightforward (disclaimer: last time I checked).

Re: Julia 1.0

#373
post #366
post #359

Earlier quoted context omitted.

> For example, the fact that an array of unions such as Array{Union{Missing,T}} is represented in memory as a much more efficient union of arrays is a perfect example of where a clever compiler can make the logical thing to do also the efficient thing to do! Can you elaborate on how Julia represents arrays of unions, or point to some documentation? I'm working on something where an automatic efficient representation…

There's an overview here: https://docs.julialang.org/en/v1.0.0/devdocs/isbitsunionarra... In terms of the Julia changes that were needed to support this, there were two key PRs: https://github.com/JuliaLang/julia/pull/20593 https://github.com/JuliaLang/julia/pull/22441

Thanks, this looks about as I expected. The real problem occurs when you have an array of union types, where sum of the union cases are themselves way, which it does not look like Julia does anything clever about (because it's not even clear to me that it's even possible).

Re: Julia 1.0

#375

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…

Anecdote time: I hit a non-deterministic bug in one of the C based Python packages we were using. Most of the time it worked, but we were running MonteCarlo on it and saw many errors. I guessed correctly that it was using uninitialized memory, and errored when that wasn't zeroed out, but my C wasn't good enough to find where. Had this been Julia the whole C code would have been Julia code and I would have had a chanc…

Let me guess, this can’t happen in Julia because memory is always initialized? Sounds like a performance hit if you know what you’re doing, so maybe you can use uninitialized memory in Julia and run into the same bug. Perhaps Julia makes it easy to use LLVM sanitizers? But you could’ve done this with your C code as well.

Re: Julia 1.0

#376

Earlier quoted context omitted.

Optimization (or any gradient based algorithm) is a good use case for AD, but I don’t see why Julia’s approaches are any better than Python’s, eg autograd, theano, pytorch etc. And sure that wouldn’t work with arbitrary Cython modules because Cython was designed as a Pythonic syntax over the Python C-API, and it just happened to become popular for numerical work. I don’t think that’s a strong argument, though, becaus…

In python I can chose whether to use autograd or numba, I can't JIT the autograded function. Seriously, read this issue: https://github.com/HIPS/autograd/issues/47

I’m aware of that, but high performance, fat vector AD would be done with eg Theano or PyTorch, not autograd.

Re: Julia 1.0

#377

Earlier quoted context omitted.

What are user defined types that don’t require being defined?

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.

Re: Julia 1.0

#378

Earlier quoted context omitted.

SciPy solvers are mostly interfaces to existing established solvers, and I’ve not had any problems with them. We’ve also used PyDSTool without problem, and it appears to support Python 3, https://github.com/robclewley/pydstool/blob/master/README.rs... If you think these are poorly maintained you should see XPPAUT, a tool still quite widely used.

It just sounds like your code doesn't require more than the occasional hotloop. That's fine then. There is no reason to leave numba. If you have anything that requires more complications, numba becomes painful. You seem to somehow insist that your usecase is the only one out there. We are actively developing a scientific simulation library in Julia. The prototype was in Python+numba. The Julia code is vastly simpler,…

I’m not insisting I have the only use case, but apart from the examples of traversing language boundaries, I haven’t see a good example of what’s so painful in Numba. What is so challenging that is requires code generation?

Re: Julia 1.0

#379

Earlier quoted context omitted.

It's not arbitrary. It's English. In the list [apple, orange, tree] which element is orange? It's the second element. I have taught Python quite a bit, and I have gotten good at explaining 0 based indexing and slicing based on it. When I switched to Julia there was nothing to explain. And my code has about as many +/- 1s as before...

Just because it is our common convention in lay conversation doesn’t mean it isn’t “arbitrary”. These spoken language conventions developed before there was an established name for “zero” or even a concept that “nothing” could be a number per se. For similar reasons, we have no zero cards in our decks, no zero faces on a dice, no zero hour on our clocks, no zero year in our calendar, no zeroth floors in our buildings…

> no zeroth floors in our buildings

In (North?) America. In Europe, there's a ground floor (zero), then first floor (1), etc. Basement is -1 (etc.).

A European friend of mine arrived at college in the USA, and was assigned a room on the first floor of the dorm. She then asked the housing office whether there was a lift, because she had quite some heavy luggage, earning some rather amused looks :-)

Re: Julia 1.0

#380

Earlier quoted context omitted.

In python I can chose whether to use autograd or numba, I can't JIT the autograded function. Seriously, read this issue: https://github.com/HIPS/autograd/issues/47

I’m aware of that, but high performance, fat vector AD would be done with eg Theano or PyTorch, not autograd.

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/make it JIT compatible. In practice this turns out to be way to subtle. Ok I'm giving up, either I reimplement an algorithm directly in my hotloop or run slow code.

So yeah, as long as your problems do not cross the domain of one package, Python and its ecosystem is great. Stay with it. But I fully expect that we'll see a lot more innovation in Julia. Already now there are classes of problems for which no Python solution exists but which actually have library support in Julia. That's really really remarkable.

Despite my misgivings about the state of tutorials, the release handling process and the aproach to tooling, this is why I switched already. I also hope that all these aspects will improve post 1.0 massively.

It's genuinely a liberation to no longer be confined to silos of DSLs that do not allow for low cost abstractions.

It's fine if you don't need it. I just don't understand why you hang out in a thread about Julia insisting that I don't need it either and could just use numba + Python when that's exactly what I've been using prior to Julia.

Post reply on HN