For those coming from matlab or fortran that is not the case.
24 Likes
or R or Mathematica (Wolfram)
17 Likes
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.
2 Likes
I don’t really get what you mean by being equivalently safe to C++. C++ is extremely unsafe and the vast majority of security issues is from code written in it (or in C). Julia has automatic memory management which avoids a whole set of security issues immediately and it also checks index bounds by default. It is possible to turn off bounds checking but that should very rarely be needed since it is only really useful in those cases where it enables the compiler to do significant extra optimizations.
Also, if you are worried about problems as described in the blog you can just run with --check-bounds=yes to force bounds checking to be on (when you run the tests with Pkg.test that is done for example).
27 Likes
I think the gap between C++'s portrayal and reality is rather large.
Using llvm::SmallVector (a C++ data type for dynamically sized arrays, like Vector) memory management is also automatic, it checks bounds by default, and some polynomial code I wrote is about 3x faster than the Julia version using the same data representation and algorithms.
21 Likes
There are almost infinitely many subsets of the language which people call “C++”. I think that’s the major issue with it at this point, not necessarily any of its features in isolation. Every person’s code looks like a different language, using different standard libraries, different code conventions, different features for generics, etc. So there are many unsafe variations of C++ that people use, and there are some that are safer but don’t seem to get as much use for various reasons. Both are simultaneously the same language.
18 Likes
And yet, as an example, 70% of vulnerabilities from Microsoft are from memory unsafeness (/blog/2019/07/we-need-a-safer-systems-programming-language/). No one will ever be able to explain away that in reality memory unsafeness from memory unsafe programming languages are the largest contributors to security problems in modern software.
16 Likes
[Meta-comment] I don’t know who Yuri Vishnevsky is, but I’m sure that after all the attention his thoughts have received here, he will reconsider his position on Julia.
3 Likes
Tbh, my interest in Julia was mainly due to Flux/Zygote due to ease of creating custom NN models. I believe each language have a set of libs/tools which drive a community interest to that language, I’d say they are mission critiacal part of a language community. So it is pointless to reason about some abstract beauty/composability of language if its main practical goals are failed. Incorrect computation of gradients or incorrect behavoir for stdout definitely would play dramatic impact on Julia. And to fix that Julia community should have much more develpoers who capable contribute to the ecosystems, and I believe thaere are lot of such, but may be languge lack of interfaces or protocol or whatever other contract mechanisms to make Julia capable efficiently assimilate voluntiers efforts.
5 Likes
Well, machine learning is not the main practical goal of Julia… I use it very successfully for solving differential equations where I do not need automatic differentiation for calculating gradients… I would say you are looking at a very specific field of application of Julia, and making conclusions about weaknesses of a language from weaknesses in one specific field of application is not correct.
Julia provides a lot of very advanced technologies, and some are production ready and some are not (yet).
13 Likes
My impression is that machine learning is one of the main applications of Julia. One of the best known parts of the ecosystem is SciML.
3 Likes
Well, there is a lot of hype about machine learning… But I would say for 90% of the tasks in the fields of modelling and control you do not need it… And Julia is very good in modelling and control…
9 Likes
Do the Zygote bugs have anything to do with the composability of Julia (as are the OffsetArrays related bugs there)?
1 Like
Sure there Julia is used for many things, but you cannot seriously dismiss the importance of machine learning for the Julia ecosystem like that.
But ok, I agree that this:
is dramatically overstated.
1 Like
Is that a question for me?
Only if you know the answer 
I’m afraid I don’t really know 
I was reacting more to the dismissal of the point than to the point itself (which I think was over the top.)
ML is not one of main goals of Julia? Just, wow. Do you think the Julia was born to became just yet another tool to solve differntial equations which already successfuly solvable by packges in Python, R, Matlab, Fortran, etc? For such a well known task like solving DEs numerically, it is doubtful that relevant community needs a whole new language. Also you mentioned control. I am sure, you don’t want your your airplane would be controlled by program on Julia due to aforementioned correctness problems.
1 Like
Well, not for me.
Is it such a minor goal?
Common people don’t program air plain flights. (not pretending that those who do are not common people)
4 Likes