It’s not one but two compilers. My sense is an array temporary will be needed anyway if the callee had CONTIGUOUS attribute for the proxy argument, so the implementors probably defaulted to doing so. Chances are rather high a bug report here will be ignored for ages, so I will not bother.
It is completely the opposite. If Julia is to attract a person like me, it must do MUCH better than Fortran, not only in speed, but also, in other respects. To begin with, can one create a portable shared library with Julia already? Can one create a binary with Julia already? (whether these will be fixed in the future is not enough for a person like me, because I am doing research right now and I need the tools right now) The truth is Julia and Fortran are not much different in syntax readability and speed, although Julia is more concise at the cost of more easily generating inefficient code (the verbosity of Fortran virtually guarantees fast code generation, regardless of programmer’s experience). So in the end, the deciding factor will likely be the ecosystem, and the presence of for-profit companies behind either language to advertise it well. Fortran currently does not have one. Julia does.
2 Likes
A lot of people also prototype in Python or Matlab and then port the code to some lower-level language. It is a fact that the syntax of Julia is not that different to that of Fortran. The codes I have written in Julia can be quite easily translated to Fortran. While LFortran is not ready, Julia is also the best platform for prototyping aiming porting code to Fortran later, for better portability.
Fortran can be seen as a statically typed version of Julia. Julia has other features which will not be easily portable, but you can perfectly well write code as if they were not there, and write Fortran-like code (dicts, iterators, etc).
3 Likes
Thanks for that information. Just before reading your message, I was asking myself exactly that question after reading the following link:
We are working hard! 
You can follow our progress in compiling this Fortran 95 code: MVP: Roadmap to compile the SNAP project (#313) · Issues · lfortran / lfortran · GitLab, once we can compile it, LFortran will become quite usable for first users.
3 Likes
I agree with much of what you said. I also feel like the discussion we have here has the potential of turning into the endless old discussion we had on a separate thread. The bottom line there was that language maturity is the deciding factor for most Fortran programmers. Even if I want to move to Julia right now, it does not have the tools I need the most. But I feel like there is a hidden but strong drive within the Julia community to flip the facts about Julia weaknesses, perhaps it is not the community but the aggressive advertisement by the for-profit company behind Julia. But whatever the source, it is more repelling than attractive to me and certainly keeps people like me away from this language because I feel it claims it has what it does not have, or tries to hide them under the rug by not showing them to me upfront and inviting me to a hole instead of helping me with my current research needs, tools which are essential for my daily work. Julia can be a good language but it does not need (what I perceive as) twisting facts to prove it. I hope the Julia community, especially the younger members understand this before it is too late.
1 Like
Well, sad you have this impression. I have been very welcomed and got a lot of help from the Julia community, and I even learned about Fortran there. As I mentioned, I think part of the source of that feeling is that a lot of people think they will just translate their codes from other languages to Julia and get fast code, and that is not true, one needs to learn how the language works, so first impressions can be disappointing and misleading. At the same time, the true weaknesses of the language are discussed to exhaustion there (lack of small binaries, compilation time lag), and while improvements have been made on those fronts, it is possible that they will never be completely solved. Also I do not think we should be stuck to a single language in our life, it is probable that no single tool will be the best to all tasks.
3 Likes
Is it flipping the facts or is it focusing on strengths and de-emphasizing weaknesses? Even if true, I don’t see what’s wrong with that. It’s marketing and fair game. Users and customers are the ultimate judge.
Am I being dishonest or flipping the facts if I omit to write in my book that:
- Large Fortran projects are moving to C++;
- Fortran is slow to adopt modern features;
- Most compilers struggle keeping up with the standard;
- The tooling and library ecosystem is lacking?
I don’t think so. I want my book to sell and I want more people to discover and enjoy Fortran. So I’m not absolutely honest, but I focus on strengths while not trying to oversell it for an application domain where it’s suboptimal. Just an analogy.
Such generalizations (e.g. a community or business is flipping the facts) and comparisons (e.g. language X is better than Y) don’t help either community or language. Julia learned a lot from Fortran. We have a lot to learn from Julia and its community. They’re both fine languages and communities.
7 Likes
@shahmoradi I felt your post could be interpreted as accusing the Julia community of things, so I edited it to make it clear that you are just presenting how you feel, but are not accusing them of wrongdoing. I hope that’s ok.
I am interested in having a productive discussion. I think how to market a language is important and should be discussed, but we have to be careful how we communicate. As Milan said, we have a lot to learn from Julia. Julia has been an inspiration for LFortran for me, etc.
4 Likes
The more I was told that “Julia is faster than Fortran”, the more I wanted to see it for myself. I even went back to the other thread about the sine summation and ran the code. Then I was surprised to see that NVFortran won that benchmark for me. I didn’t want to bring that topic back up because everyone seemed sick of it. The way Julia markets their language is a lot more careful, “this particular team rewrote this particular project and then gained a 3x speedup”.
1 Like
I think the solution is to simply raise the bar, and do benchmarks in a way that anyone can easily rerun them, and make their own conclusions. Which is precisely what we are trying to do at: GitHub - fortran-lang/benchmarks: Fortran benchmarks, but I didn’t have time yet, but maybe I should just start contributing benchmarks, and others will join.
3 Likes
I am oversimplifying it too much even. They mostly talk about the other features and just that they were pleasantly surprised to instead of seeing a performance decrease, see a performance increase.
Fortran compilers are trying to build nearly optimum machine code for 65 years, adapting to so many architectures for decades. So I don’t see how another language could do really better, except for a specific algorithm/benchmark, but the Fortran compilers can then be improved to obtain the same results. Same thing for C language.
There may be something to gain concerning parallel programming, but on a single core you can not run faster than the CPU, like you can not propagate faster than light.
But I can imagine a language that can try to tend toward the speed of Fortran with fewer source code lines. Or have libraries easier to use. And that is probably Julia (I never used it, so that’s what I understand by analogy with Python).
1 Like
IMHO, for Fortran this is not a necessary selling point. Is like benchmarking against C, C++, it is quite clear that all these languages can generate fast code. Every benchmark that claims that one is significantly faster than the other will be followed by a thread of replies showing how to get the same speed in the other language(s). (and I again stress that for Julia this is an important selling point, getting to the same speed as C, C++ and Fortran is something that Julia can do and but has to convince the world that it can).
I think the modern fortran selling point should go through the publicity of its modern syntax and features, as well, soon, with the new tools.
4 Likes
I haven’t had that impression from official marketing, the official marketing seems much different from what is happening on these Discourse topics.
The bottom-line here: how that blog post @martin.d.maas is titled which is the same as this thread – “faster than”, “cleaner than” – is at the crux of the issue, it veers in the direction of objectionable, toward language wars.
Combine that with the fact the example in it is not even sophomoric quality means the discussions will have lots of unproductive aspects.
Add to it there are burgeoning posts showing up in web searches “better than xx”, “replace yy”, etc. ostensibly by Julia bloggers means there is a lot of questionable intent out there.
So I wouldn’t be inclined to open a thread at fortran-lang anytime a micro benchmark of highly questionable relevance and accuracy shows up online comparing Fortran with some language, particularly Julia.
3 Likes
Only “surprised” because a result had been “established” in the other topic. But, I think I’ll go back to their official marketing and documentation.
“Once you understand how Julia works, it’s easy to write code that’s nearly as fast as C.”
I had to dig into the documentation to even find that, it’s not the focus on the home page.
Or this quote, “efficient enough for deploying performance-intensive applications”. That’s fine for me, no conflicts.
1 Like
I fully agree with your edit, it was an oversight by me.
1 Like
Milan, most people in this post are scientists. The whole point of science is being objective when presenting facts and results. The Julia creator presenting at a research conference is no exception to this rule. If I publish a paper and do not disclose some important aspects of my study that affect the conclusions drawn from the paper, it is considered an act of dishonestly and scientific misconduct. Similarly, if the Julia creator claims in the SC19 conference that switching from Fortran to Julia has led to 3X speedup, they should present all the circumstances around that scientific report. Did they try to similarly modernize the old Fortran code? and did they observe this only after they put the same effort on both code bases? That may well be the case they did so. But I personally doubt. If they had done so, they would have proudly mentioned it. But I don’t see it anywhere being discussed. This is an example of (what I personally consider) scientific dishonesty that I would personally never do and no one should commit in a scientific discipline in my opinion, because it totally changes the conclusions of the research.
2 Likes
I agree on the crux of the issue, but we need to be careful not to generalize and ascribe intent to a community as a whole, but to constructively criticize only specific instances.
4 Likes