Hacker News Reader

Comment by robrenaud | Hacker News Reader

From personal experience as a software engineer at Google, precommit with a force override fall back is great. I worked here before we had it and after we had it, and it makes things way better. master should stay clean, and the pre-commit approach gets you pretty far down that road.

It also helps to have a culture of quickly rolling back breaking changes when they do slip through.

View on HN

I second the move to a precommit based system. Getting a rock solid build is low hanging fruit for most projects, And getting to that point is usually just straightforward engineering. That said, this is a young project, and probably just needs more developer bandwidth to fix these minor glitches.

The problem with Travis failures is not that people aren't running the tests, it's that Julia depends on a lot of complex, finicky software [1], much of which is unusually sensitive to platform-specific differences and even differences between specific CPUs and VMs. This makes keeping builds green across the board pretty challenging. But anyone who has tried to build a fully working numerical stack like the one Julia ships with, can attest that it's non-trivial and changes that work on one machine may break things elsewhere.

[1] https://github.com/JuliaLang/julia#required-build-tools-and-...

I understand, but having so many dependencies is probably all the more reason why you need very good test coverage and a build/deploy that keeps the trunk clean, so nothing gets released without all three (or however many) platforms all build clean.

Not to armchair quarterback, I know it is a hard thing to get there and you guys are all busy. Just my 2 cents.

(And I think Julia is bloody brilliant, fwiw)

In contrast, getting R up and running is very easy. I can easily set up multiple R versions on my machine. If I want to emulate a library environment on another machine, I just need to copy the folder over to that machine.

This isn't quite true. I know of several R packages that I've had to build from source on Linux and I'd be worried about installing on windows (Combinations and Cranvas come to mind).

Generally the packages that aim for higher performance are more difficult to install, which makes sense.

Combinations: http://www.omegahat.org/Combinations/

Cranvas: https://github.com/ggobi/cranvas

edit: and if, god forbid, cran kicks off one of the packages you're using or an upstream package for a package you're using, then you've got to track it down and install it on your own. (tikzDevice is the one I'm thinking of.)

Are you talking about compiling R from source, including all dependencies and high-performance BLAS, LAPACK, FFT, ARPACK, etc. libraries? If not, you are comparing apples to oranges.

Yes. You can get multiple versions easily on the same machine and run them from that location. It's also easy to point rstudio to that instance. All the libraries install in the same location as well.

R ships with the reference BLAS which is 4x slower than OpenBLAS even on modestly sized problems. If you value portability over performance, I guess that's an ok choice, but we want to make sure that Julia ships with the best open source BLAS available. If that means putting up with the occasional broken builds on Travis, I think it's worth it. OpenBLAS is just one example – R seems to have consistently chosen portability over performance for their libraries. That's a viable choice, but it's not the one we've made.

Reply on news.ycombinator.com