pollitos

Just to note, these benchmarks are biased. This is a competition between highly-tuned-to-the-processor Julia with tuned BLAS vs other languages out-of-the-box binaries. Additionally, the benchmarks tests are written inefficiently in the comparison languages. But even then Javascript comes out on top on some benchmark tests.

The issue of primitive performance seems to be in the background of how algorithms are implemented, which BLAS is running, compilation to server architecture, etc. One might measure the performance of 'very specific language primitives' directly for those language primitives. Stripping out confounding factors feels fundamental.

Of course, such a benchmark it might not have the same marketing hue as claiming that Julia is 553 times faster than Matlab at parsing an integer, for example.

It would be interesting to see what happens if each language is compiled to the benchmark server, linked to the same BLAS and an expert implementation of the tests in each language was allowed; a scientifically valuable experiment. Just to remove all doubt about the relativities of performance :-)

Wonderful.

Insightful :)

"Why do we use scientific languages?" is very true.

Applause to the Julia contributors for their work on this innovative language with great out of the box support for modern computer chip architectures. However, they have fibbed to build up momentum, particularly their performance benchmarks. The tests are of compiled Julia with OpenBLAS for the benchmarks against out of the box versions of the other languages. Also, the benchmark code in other languages is with a style that is among the slowest implementations for each language. No seasoned programmer in any of those languages would write code in such a way.

It does seem that there is co-ordination to get Julia posts most attention, timing and upvoting.

Nonetheless, credit where it's due. It should become an awesome language, marketing hacks notwithstanding.

Hoping to put this or RPi3 into foldable card cases and connect to power, vga/lcd monitor, keyboard and mouse for schools in developing world. Would the chip or chip pro be better than RPi3 please?

For httpuv, author Joe Cheng advised cannot do a websocket-client. https://stackoverflow.com/questions/28120307/how-to-interact...

Looking forward to the improvements. Appreciate all your work in the field.

Thanks for the link on JSON and your packages, great work as always. I should clarify when I said we-client, I meant websockets client to consume feed. The last time I tried, the only R package (r-websockets) just crashed my Linux box and not maintained for several years. httr doesn't do websockets, as I understand. Seems likely a fundamental way to engineer/wrangle data into R.

For example, reshaping JSON to the format an intricate R function expects. Appreciate the great work with (d)plyr and similar packages, but it's still work and overhead. Combined with some inefficiencies/quirks in base r functions (does ifelse() still evaluate twice?) it's easier to go with a widely used and respected package in a general purpose language; Nokogiri for example. For data engineering, consider there is not a maintaned R package for a web-client, and asynchronous programming is weak.

R is really LISP with syntactic sugar and bindings to well respected high-performance FORTRAN matrix and math optimization codes.

http://librestats.com/2011/08/27/how-much-of-r-is-written-in...

It's great for bleeding edge scientific research. The results of many languages don't always match for advanced algorithms, but the open source nature of R, makes it easier to identify the problem areas.

The R-core interpreter does have a number of deficiencies. (R is based on S-language specification that left wiggle room from the 70s.) General purpose programming and data wrangling/engineering is best handled in other programming idioms.