There's a big difference between immaturity of development tools – IDE, debugger, etc. – and stability and reliability of the language runtime itself. The Julia runtime is quite stable and usable for production once you've got a set of packages that work nicely together installed. Getting to that point has some rough edges due to the tooling, but once you're there, it's not like Julia randomly segfaults.
On Thu, Mar 5, 2015 at 4:28 PM, Christoph Ortner <[email protected] > wrote: > > > 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]> >> 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 ;).) >
