Maybe there are SW standards that packages and the base can certify against. To be useful, not only does the analyst or programmer have to trust it, but their management and customers have to trust it.
For engineering to adopt it over MATLAB or hand written C++ it must get equivalently safe and secure results at the benefit of reduced coding complexity and improved execution performance.
Otherwise, Julia will only be a prototyping or an academic tool and will not have solved the two language problem.
Also, all software has bugs. At least with Julia you can fix most of them and submit the fix. With Xilinx and Mathworks and some of the other open source languages, it’s much more complicated to work around their bugs.
With Julia and the professional use case, understanding good Julia coding standards and best practices especially when integrating with non base packages is what is difficult for a new user. There are a lot of assumptions about experience level made in some of the documentation but I am still impressed at how thorough it is. Many times there are a lot of choices and the new user doesn’t understand the consequences of one over the other. Many engineers have a copy and modify work style. Make sure the use cases have non trivial examples as well that don’t require the engineer to rube-Goldberg a series of examples too much to understand what is the right way to do something.
I’m excited for the day when Julia is mature enough to allow algorithm development that targets embedded systems. But simulating fast and developing fast is still a plus.
How the Julia community addresses problems will be more important than if the Julia language has problems here and there.
Problems and bugs are expected. We just want a stable path to resolution. We have to verify and validate our engineering solutions. If we can push some of that off on a robust test process or set of standards that are easily testable, that would be wonderful.