I guess I can take a shot at addressing some of these.
reliability for critical apps with minimum response time and high availibility,
Minimum response time is generally dependent on two things:
- language speed and
- whether there is a garbage collector with long stop-the-world pauses.
Julia is fast when used right and presumably for something so critical, you’ll do some benchmarking and use the other tooling the language has for performance analysis to make sure the code itself is fast.
Julia does use a stop-the-world mark-and-sweet garbage collector. However, Julia’s support for and widespread use of immutable data and APIs for mutation of preallocated memory (
f! name convention for mutating functions) makes it fairly easy to write zero- or low-allocation code. This means that pressure on the garbage collector is much lower than many other garbage collected languages where memory pressure tends to be quite intense since the design of such languages usually makes it hard to avoid allocating objects.
That said, Julia is probably not the right choice for writing real-time systems.
reliability for long-life process (memory recycling management ?),
I guess you’re asking about whether the garbage collector works? It does. There have been a few memory leaks over the years, but they get fixed and there haven’t been any major ones in quite a while (the most recent one seems to have been due to an OS resource leak, if I recall correctly). In any case, writing and running long-running, reliable programs in Julia is as doable as it is in any other language. You, as the programmer, need to write correct code and make sure you handle error conditions, but you have to do that in any language.
reliability with intensive processing computation and capacity to manage big amount of data (which explains my question about K. Bouman) compared to classical langages in app. math. (eg Fortran/C/C++),
Yes, you can load huge amounts of data and do compute-intensive work on it. These have been design goals of the language from the very outset. This is one of the reasons, for example, that Julia does not use copy-on-write arrays. Matlab and R both do this, which effectively forces you to have several times the memory of your largest data, because it’s often impossible to avoid implicitly copying. There are many other similar considerations that have been made along the way. In Java, for example, array indices are 32-bit, which means you can’t have more than 4 billion elements in an array. Usually that’s not a problem, but sometimes you have a data set with more than 4 billion elements. In Java, you cannot load such a data set into a single array. Julia uses 64-bit indices on 64-bit systems and has configured all the libraries it ships with to also use 64-bit indices (this is often why Julia cannot use system copies of these libraries which have usually not been configured to use 64-bit indices). This means that the only limit on the size of the data you can work with is how much memory you have.
reliability of bug free developpement regarding the use of a dynamic type langage compared to a static type langage.
If you want a static language with type checking, then Julia is not such a language. On the other hand, it’s way safer than C, C++ and Fortran, which don’t even do array bounds checking or protect you from memory errors, so segfaults and accidental memory corruption are a standard part of daily life in these languages. Even Java and C# still leave you open to null pointer exceptions and other runtime errors that the type checker can’t prevent. So if you consider C, C++ and Fortran safe enough for your purposes then Julia is definitely safe enough.
The academic research is not really conclusive about whether static or dynamic languages are more reliable (this is a good survey with a slight self-acknowledged bias towards preferring static languages). The research itself is fairly split at a high level, with half of the papers leaning one way, and half the other way. Moreover, the conclusions tend to reflect researcher bias in a fairly obvious way, and the results can generally be interpreted to support whatever position you wanted to come to in the first place. If there was slam-dunk evidence that using a static language was, say, 10x more reliable than using a dynamic language, then I think we would know it by now. And that doesn’t seem to be the case.
My personal interpretation of the research on static versus dynamic reliability is that static type systems do probably catch a decent number of bugs that would go unfound in duck-typed dynamic languages, but that it’s not a huge portion of bugs—probably only some 10-20% of bugs and 20% is probably too high. I also think that these are the easiest bugs to catch by testing; moreover this class of bugs is considerably less likely to go undetected in Julia since most methods have type annotations and throw method errors if called with unexpected types. That said, I do think there is some reliability advantage to static type checking in safe static languages, but I also think that the cost in productivity and expressiveness is quite high.
A little more opinion and interpretation… It seems fairly widely accepted that unsafe static languages like C, C++ and Fortran are the least reliable and the least productive—they win on performance and maturity, however, which many people prioritize. Safe static languages like Rust, Scala or ML seem to be the most reliable languages and more productive than the unsafe static languages—the improved compiler support helps both safety and productivity. Duck-typed dynamic languages like Lisp, Perl, Python, Ruby, Matlab and R seem to be more productive than static languages by a significant margin but are somewhat less reliable than safe static languages but still much safer than unsafe static languages—they catch bounds errors and don’t allow unsafe memory access. Julia falls into a relatively new category of language: typed dynamic languages. TypeScript and Dart are also in this category. Since these languages are pretty new, there hasn’t been that much research on them, but they seem to retain the productivity of the dynamic languages while approaching the reliability of safe static languages.
Static language advocates seem to me to significantly overstate how much static type checking helps with catching serious bugs. Statements like “if it compiles, it probably just works” seem very foreign. What kind of programming are people who say things like that doing? How often do I make a mistake where I’m passing the entirely wrong type of value to some function or returning the wrong type of value? Sure, it happens, but not that often and it’s usually trivial to find such a mistake given even cursory testing during development. (Again, especially in Julia where functions can and do declare argument types and typed data structures are used pervasively.)
What is much more important in my opinion for the reliability of software in both dynamic and static languages, is having a strong culture of testing. Yes, there are type bugs that type systems can catch before you even run tests—but testing can also catch all the other kinds of bugs (80-90% of them by my previous guess). Julia does very much have a strong culture of testing. Julia’s own test suite is massive: 136,985 lines of test code, with 38 million individual tests for Base alone. Many of the widely used packages are also very thoroughly tested. Tooling for testing ships with Julia in its standard library. Test stubs are automatically generated when you create a new Julia package—just add the tests. If you host your package code on GitHub all that’s required to turn on continuous integration to test every commit that’s made is to turn on the Travis/AppVeyor apps—the configuration files for also are autogenerated for you. And doing continuous integration is very much the norm.
Bottom line: Julia is a good language for reliable programming. It is much safer than unsafe static languages like C, C++ and Fortran. It is also safer than most dynamic languages, which are duck-typed, whereas Julia can and does have explicit type annotations on function arguments. Finally, testing is the most important aspect of making any language reliable, and Julia has extensive tooling support for testing and a widespread culture of testing.