I'm excited by Julia, but I don't think this article makes a very good sell. It's neat that you can dump the generated assembly, but I'd rather see a demonstration of a robust profiler so that I know which functions I need to dump in the first place.
I also disagree that the popularity of Node stems from "getting disparate groups of programmers to code in the same language". From what I've observed, it's not that back-end programmers are suddenly giddy at the prospect of getting to use Javascript on the server, it's that front-end programmers get to apply their existing knowledge of Javascript to back-end development.
I tend to agree with you about tools. I have yet to meet a language feature that's more important than library availability, profiling, autocompletion, documentation, debugging, etc. Then again, I don't face the script/C/CUDA choice everyday (most of his detractors on this thread don't either, I'd be willing to bet) so his circumstances are probably different enough to justify a different priority list. His argument might be perfectly valid for the HPC community which is a powerful constituency among academic programmers.
However, he did address library availability, and that argument resonates with me. I've never met a FFI I didn't come to loathe. I've had java, ruby, and python FFI libraries fail to satisfy my needs despite half a dozen bugfixes between them. What this man says about having to write wrappers, despite abundant and loud promises to the contrary, is completely true. You don't have to wander far off the beaten path before a typical FFI goes belly-up. POD structs usually suffice (Sure, we support POD structs! Oh, you want to nest them / align them / make arrays of them / have them hold pointers / ...? We don't support that "yet". Worse: they support it but it's buggy.). Heavens help you if your argument has (gasp) an initializer or one of the arguments is a reference. Maybe things have changed in the last ~5 years, but I doubt it.
If Julia's intimate connection with LLVM makes it practical to implement a better FFI or hybridize FFI + wrapper code when necessary, it will have a very valuable advantage over python for purposes of scientific computing. Maybe even enough to displace it in the long run.
EDIT: By "hybridize" I mean that the ability to embed asm,C,C++ in Julia with the same ease that you can embed asm in C/C++ would be a KILLER feature.
I've felt that pain. With so many new programming languages popping up, I've been wondering if the next killer programming improvement isn't strictly a programming language at all, but rather something that rethinks the linker, manages execution, and facilitates interfaces between larger blocks of code (maybe in multiple languages).
Yep me too. People are too quick to dismiss the cross language issues which can in my experience can slowly erode the benefit. Typically you use an FFI to access particular functionality offered in libraries/classes only offered in another language. In my experience it is only a temporary solution, a does-it-work test. After that you need to recode. Having said that, in my experience Lua(JIT) does this pretty well with C libraries but Lua was designed as the scripting companion to C from day one.
The JVM offers a better place to tackle these issues. Scala and Java cross calling is often more than adequate. Perhaps a Julia compiler for the JVM could be a step in the right direction.
I've heard many very smart people (professors, leaders of large HPC efforts, "language geeks") express the same sentiment over the years. Unfortunately, it's a btch of a problem, as attested to by the veritable graveyard of half-baked solutions out there. Apple's "Bridge Support" is the closest thing I've seen to success (haven't worked with MS's CIL) and it leaves much to be desired.
I'm not sure there is any way around the impedance mismatches between languages. They're all slightly different for a reason. Perhaps clean C APIs are the best we can hope for.
I keep hoping that some accessibility upgrade comes to the linker akin to how LLVM made compiler infrastructure more accessible, might make FFI bridging more automated. For example, if GDB can access and take apart C structs an automated way, why is FFI coding always seem to have programmers do a lot of mechanical interfacing work.
Not that all the other JVM, CIL, etc aren't approaches that yield some improvements, but something that upgrades capability or accessibility at the level of the ABI linkage level is going to be a wider impact.
The main reason we at clara.io use Node is so that front-end code can run in the back end. Imports, Exports and Renders are done by workers that are essentially headless clients that happen to have access to first and third party binary libraries.
But Node.js does glue together things written in C (by backend engineers maybe) and then used in node with javascript (by frontend engineers like you said).
not to mention the node package manager, ability to host web servers in couple lines of code, and nice implementation of single threaded pump pattern making it a very scalable platform. seems quite ingenious to me.
I also disagree that the popularity of Node stems from "getting disparate groups of programmers to code in the same language". From what I've observed, it's not that back-end programmers are suddenly giddy at the prospect of getting to use Javascript on the server, it's that front-end programmers get to apply their existing knowledge of Javascript to back-end development.