Julia's primary purpose is as a scientific language, which means lots of number-crunching on large data sets, complex computations, etc. IO is unlikely to be the bottleneck in these situations.
I'm not sure I agree with the second sentence. Any kind of crunching on large data sets has I/O bottlenecks as one of its main issues. When you're crunching on a terabyte of data, pretty much the most important thing is your precise strategy for handling that terabyte of data. I'll agree the asm can be interesting still there in some cases, though, if you think of memory-bandwidth-and-latency issues as part of I/O. There are definitely scientific simulations where compute throughput is the only real issue, but I think of them as a bit different kind of setting than big-data processing (stuff like solving complex sets of equations, which has low I/O but high computational requirements).
Yeah, I shouldn't have conflated big-data issues with numerical computing. Good catch.
Mostly I was responding to the idea that there is a relationship between dynamic languages and IO bottlenecks. This is certainly often the case in things like web development, where dynamic languages dominate, but under the hood, Julia has relatively little in common with Python/Ruby/JS/PHP/etc, in terms of how it's implemented or, especially, what it's intended to do.
> There are definitely scientific simulations where compute throughput is the only real issue, but I think of them as a bit different kind of setting than big-data processing (stuff like solving complex sets of equations, which has low I/O but high computational requirements).
