3 ms·

This sounds like premature-optimization to me. Maybe it's just me, but in the apps I write in dynamic languages, the bottleneck is rarely in the language. It's

This sounds like premature-optimization to me. Maybe it's just me, but in the apps I write in dynamic languages, the bottleneck is rarely in the language. It's usually in some IO. EDIT: some sentence in the article gave me the impression he was using this for non-math-heavy stuff which is why I said this

thinkpad20 13y ago
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.
- mjn 13y ago
  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).
  - maaku 13y ago
    > 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). ^^ This is the use case for Julia.
  - thinkpad20 13y ago
    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.
vanderZwan 13y ago
It is "just you"[1] in this case - the people most enthusiastic about Julia are the people doing statistics, simulations and similar tasks with massive datasets requiring heavy number crunching. I expect fast code and cache issues are the more likely bottlenecks in their situations. [1] Of course, you might still represent the majority of people using dynamic languages, but you get my point.
SomeCallMeTim 13y ago
You're also not writing real-time apps or scripting games. There are a lot of reasons to want speed in a dynamic language.
dasil003 13y ago
In production code paths yes, but I have to admit that the 3 seconds it takes a bare Rails environment to start up has over time made me really pine for a Go or Haskell project. Rapid prototyping is great, but responsiveness at the command line also is another form of rapidity that also serves developer productivity in appealing ways (auto testing harnesses for instance).
theseoafs 13y ago
What on earth kind of programs are you writing where the dynamic language is blazingly fast but you have a bunch of IO bottlenecks? Are you writing a database driver in Ruby or something?

thinkpad20 13y ago

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.

mjn 13y ago
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).
- maaku 13y ago
  > 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). ^^ This is the use case for Julia.
- thinkpad20 13y ago
  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.

vanderZwan 13y ago

It is "just you"[1] in this case - the people most enthusiastic about Julia are the people doing statistics, simulations and similar tasks with massive datasets requiring heavy number crunching. I expect fast code and cache issues are the more likely bottlenecks in their situations. [1] Of course, you might still represent the majority of people using dynamic languages, but you get my point.

SomeCallMeTim 13y ago

You're also not writing real-time apps or scripting games. There are a lot of reasons to want speed in a dynamic language.

dasil003 13y ago

In production code paths yes, but I have to admit that the 3 seconds it takes a bare Rails environment to start up has over time made me really pine for a Go or Haskell project. Rapid prototyping is great, but responsiveness at the command line also is another form of rapidity that also serves developer productivity in appealing ways (auto testing harnesses for instance).

theseoafs 13y ago

What on earth kind of programs are you writing where the dynamic language is blazingly fast but you have a bunch of IO bottlenecks? Are you writing a database driver in Ruby or something?