Live data from Hacker News

Static, Ahead of Time Compiled Julia

juliacomputing.com

41–50 of 87 posts

Re: Static, Ahead of Time Compiled Julia

#41
post #8

I think this [0] is worth reading before starting a project in julia (it's quite shocking). Does anyone know if anything has changed in julia's development process over the last year? [0] http://danluu.com/julialang/

I'm an enthusiastic julia user, observer and very minor contributor. IMO a lot of the issues in this constructive rant have been addressed to some extent. For context, here's the previous HN discussion https://news.ycombinator.com/item?id=8809422 Going through the post in order: The stable releases still have some bugs as you would expect in a young language, but 0.4 is now well below my tolerance level. For a rough…

> I've no idea about the "private and semi-private communications" and I can only hope things were patched up there.

I'm the co-creator that Dan was talking about. He wrote a bunch of less-than-charitable comments on the aforementioned semi-private forum – not specifically to me, but where he surely knew I would read them – to which I responded with:

https://gist.github.com/StefanKarpinski/c72219ff8ce261172b11

You can judge for yourself whether I was nasty or dishonest. Things were, unfortunately, not patched up. Dan posted a number of responses, deleted all of them before I could read them, then left the conversation permanently.

Re: Static, Ahead of Time Compiled Julia

#42
post #27

Earlier quoted context omitted.

The language works well for what is effectively still a beta. Sure I'd like more documentation and tests, but I'm happy to get features first. The alternative for me is trying to do some non trivial cluster computing in C or in python, either of which would suck.

What kind of cluster computing? I've had good experiences with Scala and Spark, though that might be for a different use case.

It's an MCMC algorithm for a fancy kind of matrix factorisation.

I had a look at Spark, but its linear algebra packages seemed too limited (I guess abstraction comes at a cost). I can see that Spark would be nice if it does what you need out of the box.

Heard good things about Scala, is it straightforward to get a process on a remote machine to execute code?

Re: Static, Ahead of Time Compiled Julia

#43
post #8

I think this [0] is worth reading before starting a project in julia (it's quite shocking). Does anyone know if anything has changed in julia's development process over the last year? [0] http://danluu.com/julialang/

I'm an enthusiastic julia user, observer and very minor contributor. IMO a lot of the issues in this constructive rant have been addressed to some extent. For context, here's the previous HN discussion https://news.ycombinator.com/item?id=8809422 Going through the post in order: The stable releases still have some bugs as you would expect in a young language, but 0.4 is now well below my tolerance level. For a rough…

Thanks for the lengthy response!

Re: Static, Ahead of Time Compiled Julia

#44
post #23
post #19

Earlier quoted context omitted.

Here are some tasks that are ugly with [1:n] indexing: - the 1D index of element (i,j) in a matrix is i+(j-1)*m instead of i+j*m - the i'th 3-element subvector of a vector is v[3*(i-1)+1:3*i] instead of v[3*i:3*(i+1)] - if you have vector of indices that partitions an vector into chunks, the i'th chunk is v[ind[i]:ind[i+1]-1] instead of v[ind[i]:ind[i+1]] Perhaps small issues, but these are all real examples from my…

>I really, really wish they had dropped the 1-based indexing >, my opinion on this topic is distorted because I spent a lot of time programming in C++ Mathematics-related programming[1] in MATLAB, R Language, Mathematica, SAS, etc all use 1-based indexing. Given that the originators of Julia are MATLAB users, it makes sense that they made a deliberate choice to keep 1-based indexing. In other words, it was more impor…

Mathematica is actually 0-based - but with the zero index spot reserved. A list {1, 2, 3}=List[1, 2, 3] could be read as (List 1 2 3) in Lisp style; one can check if you have Mathematica that {1, 2, 3}[[0]] = List.

But I think that's neither here nor there. Whenever the index has more use than as a label, mathematics starts at zero. Modular arithmetic, polynomials, discrete fourier transformations - for that matter, any discrete approximation of continuous math - all naturally start at zero, and generate lots of -1s in one-based indexing.

Re: Static, Ahead of Time Compiled Julia

#45
post #27

Earlier quoted context omitted.

What kind of cluster computing? I've had good experiences with Scala and Spark, though that might be for a different use case.

It's an MCMC algorithm for a fancy kind of matrix factorisation. I had a look at Spark, but its linear algebra packages seemed too limited (I guess abstraction comes at a cost). I can see that Spark would be nice if it does what you need out of the box. Heard good things about Scala, is it straightforward to get a process on a remote machine to execute code?

> I had a look at Spark, but its linear algebra packages seemed too limited (I guess abstraction comes at a cost). I can see that Spark would be nice if it does what you need out of the box.

Did you look at MLlib and/or just using Breeze directly? There's a bit of awkwardness in the initial set up of the cluster (mainly just having LAPACK installed on all nodes, see https://spark.apache.org/docs/1.1.0/mllib-guide.html ). Spark itself is essentially just sugar to let you write a map/reduce in natural scala style and have it distributed across a cluster - it'll only work if you can factor your algorithm in a way that fits into that paradigm. (I've heard arguments that it's possible to do that with any distributable algorithm if you're clever enough, but I'm not sure I believe them).

> Heard good things about Scala, is it straightforward to get a process on a remote machine to execute code?

Honestly, no. I love the language but Spark is very much what I think of (perhaps unfairly) as typical scientific software. Spark clusters are finicky - they're cobbled together from a few unrelated projects (especially for cases where you need LAPACK as well), and it shows, especially when it comes to updating them. There are a few organizations like Cloudera (I think there was an open-source effort under the Apache umbrella somewhere too) that try to provide a working package, and various efforts with Puppet/Chef/etc. to automate the process of putting a cluster together, and it's certainly a lot better than it was even a few years ago, but a cluster still need at least a little bit of dedicated sysadmin time (or, at a bare minimum, a programmer with a bit of *nix admin experience who's willing to get their hands dirty - that was me at times) to keep it running reliably.

If you're part of an institution that already maintains a Spark cluster - or maintains an ordinary Hadoop cluster and you're friendly enough with the sysadmins to suggest they install it - it's wonderful. If you're having to do it all from scratch I won't lie, it's going to involve a lot of fiddling and may well not be worth it for your problem.

Re: Static, Ahead of Time Compiled Julia

#46
post #8

I think this [0] is worth reading before starting a project in julia (it's quite shocking). Does anyone know if anything has changed in julia's development process over the last year? [0] http://danluu.com/julialang/

This article was pointed out to me, more than once now, as a user of Julia. However, I don't see that it has too much relevance to me as a user of the language, even if its quite outdated points were still valid today.

I am part of a team that now has over 60,000 lines of Julia code in our computer algebra package(s), and the intersection between our experience as users and the points danluu made is almost nil.

If one looks at the ranking of the language on Tiobe, it's quite obviously being used a lot for a language that hasn't even reached 1.0 yet.

I think the issues one is likely to have with Julia as an evolving language have completely moved on from those made in danluu's article. In fact, it might be useful for someone to write a "constructive criticism" blog article about the state of affairs today.

My personal opinion is that I would wait until 1.0 (which will arrive in less than 2 years time) if I were a fortune 500 company, unless you really need to be ahead of the game and are prepared to contribute to the development of the actual language itself. But for just about anything else, if you need the features Julia provides, it's probably vastly superior to the alternatives today.

Our experience is you will occasionally have to adjust some of your code to handle changes to the language prior to 1.0, and we've had to do that a few times so far (at most a few hours work each 0.x point release, even with our large, complex code base). And this mainly applies if you are really pushing Julia hard and exploring interesting corners of the language. Other than this, its more than stable enough for serious work.

Re: Static, Ahead of Time Compiled Julia

#47

> For example, the Julia community seems to have coined the term “type-stability” to describe a concept that static / compiled languages have historically enforced and dynamic / scripting languages have historically disregarded. I was not aware that this was a Julia neologism. It seems like such an appropriate term for discussing how to make code make the most out of JIT-compilation.

The closest concept I can think of is the concept of "strong typing," that a value does not change type based on its context, which is a fairly widely used term. It seems like Julia has some form of weak typing, at least between the different numeric primitives, and "type stability" refers to avoiding any usage of weak typing. I don't know a lot about Julia, though, so I could be way off here.

Re: Static, Ahead of Time Compiled Julia

#48
post #8

I think this [0] is worth reading before starting a project in julia (it's quite shocking). Does anyone know if anything has changed in julia's development process over the last year? [0] http://danluu.com/julialang/

The main valid complaints in Dan's post were: 1. Insufficient testing & coverage. Code coverage is now at 84% of base Julia, from somewhere around 50% at the time he wrote this post. While you can always have more tests (and that is happening), I certainly don't think that this is a major complaint at this point. 2. Package issues. Julia now has package precompilation so package loading is pretty fast. The package ma…

> The main valid complaints [...] the legitimate issues raised [...]

This is a really passive-aggressive weaselly phrasing. I’d recommend reconsidering this type of tone in public discussion responses.

Instead of suggesting that the other complaints were invalid or illegitimate, you could just not mention them at all, or at least use nicer language in brushing them aside. E.g. “... the main actionable complaints...” or “the main technical complaints ...”

* * *

> [...] I certainly don't think that this is a major complaint at this point. [...] it's hard to consider this unaddressed [...] fixed

After reading the original post and your responses, I think the responses come across as pretty smug and dismissive.

Third-party readers would probably be more optimistic if you just left it at “we’ve made a lot of improvement since then and we’re still working on it” or similar.

Re: Static, Ahead of Time Compiled Julia

#49

Earlier quoted context omitted.

My areas of focus are pretty different from that author's - e.g. I haven't tried contributing to the core language. But I've been using Julia for my research code for ~4 months now, and it's been an absolute joy. The language allows super-readable code while remaining quite fast. The sort of research I'm doing involves interacting a bit with data then doing a bunch of simulations, and Julia excels at this. The expres…

> I'd like an infix function composition operator. Do you mean like the pipe symbol? rand() |> println Or are you referring to something else?

No, x |> f is equivalent to f(x) while (f ∘ g)(x) is equivalent to g(f(x)). Specifically, x |> f results in a value (of the type of the return value of f) while f ∘ g results always results in a function.

Re: Static, Ahead of Time Compiled Julia

#50

> For example, the Julia community seems to have coined the term “type-stability” to describe a concept that static / compiled languages have historically enforced and dynamic / scripting languages have historically disregarded. I was not aware that this was a Julia neologism. It seems like such an appropriate term for discussing how to make code make the most out of JIT-compilation.

The closest concept I can think of is the concept of "strong typing," that a value does not change type based on its context, which is a fairly widely used term. It seems like Julia has some form of weak typing, at least between the different numeric primitives, and "type stability" refers to avoiding any usage of weak typing. I don't know a lot about Julia, though, so I could be way off here.

"Strong typing" and "weak typing" don't really mean anything:

http://blogs.perl.org/users/ovid/2010/08/what-to-know-before...

You probably mean "static typing" versus "dynamic typing" which I wrote a bit about in the context of Julia here:

http://stackoverflow.com/questions/28078089/is-julia-dynamic...

Basically, I think "type stability" hasn't really been a thing in the past because in dynamic languages, people have traditionally not cared about ensuring that return types are predictable based on argument types, and in static languages, a program is incorrect if that's not the case. As people care more and more about being able to statically predict the behavior of programs in dynamic languages, the concept of type-stability in dynamic languages becomes increasingly important.

Post reply on HN