Julia is only at version 0.4 (well, soon). It's too soon to expect miracles. :-). however, I want to restate an old suggestion. a language should have as few surprises as possible. this applies not only to features, but also to performance.
http://julia.readthedocs.org/en/latest/manual/performance-tips/ contains many gotchas. the language interpreter should eventually help non-julian experts with the gotchas. that is, the knowledge in the page on julia performance optimization should be in the compiler---even if just as a jit warning. for example, global variables: julia could give a warning when it guesses that the global variable could be rolled into a local function or that the global variable looks like it may be constant. from what I see, similar arguments can be made for abstract containers and others. (maybe a language pragma would be helpful---unless turned off, help the novice!) common gotcha's come up again and again for a reason. this is why they are on this julia page to begin with. my guess is that checking for gotchas will probably mess up beautiful internal julia compiler-language code (in tryomg to determine whether the julia user code likely has gotchas), but we all hope that julia user code will be a lot more common than julia compiler-language code. suggestion for julia version 1.4, perhaps. regards, /iaw PS: (R drove me nuts [=cost me days and days] to understand gotchas. for example, I learned the hard way that changing one element in a data frame creates complete copies, and thus slowed down my program by a factor of 100 when large data frame were involved? I wasted the time of a lot of good people on the R mailing lists. how should I have suspected this? even if I had read the docs end to end, I would not have remembered them a few weeks later. or, why is read.csv() in R not.data.frame(data.table:fread) ? do I really want my users to have to learn this the hard way, given how common it is?)
