On Thursday, 5 March 2015 17:49:24 UTC, Stefan Karpinski wrote: > > On Thu, Mar 5, 2015 at 7:43 AM, Christoph Ortner <[email protected] > <javascript:>> wrote: > >> For this reason, while I am happy to talk about how nice Julia is, I >>> will not try to convince people to switch to it. IMO the people who are >>> potential switchers at this stage have already looked at Julia, and >>> evangelizing more aggressively could be counterproductive at this stage. >> >> >> I think this is really important. Personally, I am thrilled with Julia, >> because I write code that does not need any packages other than plotting >> and File I/O. But I really need the combination of rapid development >> (scripting, dynamic) and then being able to optimise certain passages, >> without ever having to switch to C. But I would never recommend Julia >> (at this stage) to a "production user", only to people who might like to >> "play with it". >> > > I think this depends on how much pain the alternatives are causing. I > would never try to sell someone on Julia if they're perfectly happy with > Matlab or Python or R – if those are working for them, great! It's the > people who are desperately unhappy with what they currently use that might > really benefit – and those people do exist. There are people now using > Julia in production for whom the alternatives were to prototype in > Matlab/R/Python and then rewrite everything in C++ or Java for performance; > but the amount of development time and effort entailed in that process just > wasn't feasible. Even with the relative immaturity of the Julia ecosystem, > it is still more productive in some circumstances to be able to prototype > *and* deploy in the same language. It's a matter of picking your poison: > you can go with the established languages and have a lot of pain around the > performance vs. productivity tradeoff; or you can go with Julia and that > won't be an issue, but you'll have to deal with sometimes implementing > things that other language already have packages for and with packages > sometimes breaking when you upgrade them (the secret is don't upgrade > often). As long as that tradeoff is clear, I think it's ok to recommend > Julia, but one does have to set expectations honestly and not oversell it. >
Maybe my statement was a bit too strong and also should have been clear about "production user": people who need mature packages (and in fact here it depends very much on what they need as e.g. Julia has much of Numpy and SciPy in Base already) and a mature development environment. I like Juno and I think ESS is ok, but I would call neither "mature", e.g., missing debugger, profiling is not built-in, auto-complete is far from perfect and getting help text in the editor does not work consistently either. And finally breaking backward compatibility every few months? As I said above I am hugely enjoying Julia, but these are the things I warn people about. (Btw, some of my friends and colleagues have even started mocking me about my enthusiasm for Julia - so it is not as if I am doing a bad advertising-job ;).)
