While the Noteworthy Differences page is very helpful imho, I think it would be good to add a more general introduction to compare the core Julia design principles to other languages, especially:
I think that the purpose of the list is to provide a short alert to users: “Hey, realize this is different”. Since types require a lengthy explanation, I provide a link to the documentation.
My intention was to use the simplest example of type declaration. One that Fortran users could
recognize, that is why I used a double float. If the example is going to be interpreted as a suggestion for future usage, then I put an own declared type because types in Julia have no performance penalty.
I must admit that my knowdledge of types is very limited because I use them scarcely.
Despite having contributed to the “noteworthy differences” section in the manual myself, I have come to question its usefulness.
Even for languages quite close to Julia, there is no substitute to reading and understanding the manual. Without the manual, these lists don’t really help users write Julia code (differences in surface syntax are usually the most insignificant anyway); but once one reads the manual they are somewhat superfluous.
On the topic of type annotations, often people make the mistake that type annotations makes things faster. Perhaps stating "Type declarations do not generally affect performance. Functions are automatically compiled to use the strictest types possible using a process called “type inference” " can discourage this assumption?
There is a diversity in the Fortran community. Some people know FORTRAN/Fortran only; To them, the difference is something common to popular dynamic languages (Python, Ruby, R, Matlab, etc) i.e., dynamic typing, interactive usage, packages, etc. If they know some dynamic languages, their interest is how easy numerical coding is possible in Julia. Also, they would be interested in parallel computing performance.
The OP lists more technical details than mental model/way of programming. There are some more examples:
str="Fortran"; str[1]='X'. Also, you can’t change the scalar argument of a function because a scalar is immutable.a=[1,2,3]; b=a; a[1]=100; b[1].@inbounds into the code explicitly. Julia has more macros to remove checks or to improve the performance instead of compiler options.PackageCompiler.jl for your purpose).Besides the details, I think, the difference between Julia and Fortran is in a development model, coding style, and tests. This post is already too long, so I may post these aspects in another post.
EDIT: I added some more details.
@.label: do ... exit label. There is no such built-in in Julia; Instead, you can use @goto and @label macros.a[:], Julia always makes a copy of it (even though just look at it). To avoid this, make a view using @view or view().I found the notable differences page to be a very useful introduction grounded in what I was already familiar with. Before committing to switching to Julia and reading through the manual, I read the notable differences section and decided they were all changes I could get used to. Julia had enough of the Matlab things I liked and did away with enough of the Python things I hated to keep me interested in going further.
Now that you are experienced with Julia, do you think that the notable diffs section did a reasonable job in listing the things you have to get used to?
I am asking because a lot of the novelty in Julia is conceptual, difficult to summarize as a difference in surface syntax etc.
I think there’s also a risk of excacerbating a sort of X-Y problem here by encouraging users to look for “how do I replace idiom Y in my old language that I use to solve problem X”, when the better thing to ask would be “how do I solve problem X in Julia, which (potentially) offers very different ways of expressing things”.
So while definitely useful to alert new users to possible traps when switching to Julia, overreliance on them can keep them from making best use of Julia.
Many old and experienced Fortran programmers can write Fortran in any language. Julia is no exception. Fortran in Juila (Foolia?) is, unlike Fortran in C or Matlab, pretty slow.
One major similarity between Julia and F66/77 is that preallocating memory and doing operations in-place is really important. I was delighted to see this.
My first language, and I am not making this up, was Fortran 66. I’m still looking for Hollerith constants in Julia. 
It is certainly true that those items do not encompass all the conceptual differences. I think, however, that many experienced programmers interested in Julia will not read the entire manual.
They will just go directly to control flow syntax, how to install it and how to look up the documentation at the REPL. In a few hours they can be productive. Later, and progressively, they will go through the documentation. In my case it is like that because I knew already Fortran, Python, Octave, and “some” C++.
@Tamas_Papp Notable Differences is the fastest way to start coding in Julia. New users do not want to wait until halfway through the manual to learn that square brackets index and parentheses call functions. It allows people to get in and start playing with the language. The next thing to learn would be style convention, again to be able to keep writing, and then conceptual methodology. Learning Julia is a process learned by experimenting and then referring back to the manual (or forums). I read through most of the manual when I was getting started, but have since forgotten all the parts I haven’t actually used in my code yet.
@nilshg I think replacing code in another language verbatim is the obvious place to start for most people. Direct translation is of course not the best coding practice, but it is the easiest for beginners to grasp. Thinking like a Julian is the goal, but can’t be expected upfront. That is why my favorite answers to these types of questions are “This is the most direct translation, but here is a better way in Julia for this reason.” It is comforting to know that Julia can do everything their old language could but also adds new functionality not possible before.
I am somewhat skeptical that reading only this section would allow someone to use Julia in any meaningful sense (ie beyond “Julia as a calculator”). Eg function definitions and using are not even mentioned here. Furthermore, most of the information in this section of the manual is pretty unstructured.
This part of the manual is possibly useful if someone read some other chapters, and wants to translate some idiom to Julia and is looking for an equivalent construct or replacement.
True, maybe the section could be included as part of a Quick Start Guide. In Matlab, I didn’t really use functions or external packages, but both are pretty much required in Julia. I think I started using Julia as a calculator, then had to learn packages when I wanted to plot my results. Then reading about style somewhere realized I should make as many small functions as possible instead of long scripts with global variables, naturally leading into learning about functions and scope. Then continued to progress from there.
Huh? Isn’t that lots of loops, and somewhat primitively explicit programs (as opposed to generic programming with higher level functions and such)? I would have thought ‘Fortran in Julia’ would be very fast, but quite restrictive.
Gee, maybe my computed goto’s had something to do with my problems. The experiment was porting a Matlab program with many array slices. Very like F90, and I got allocated to death. Perhaps 1.5 is better, but I’ve already fixed the code (with naked BLAS calls, also right from the F77 playbook).
@view is probably what you are looking for, see Could you explain what are views? - #2 by heliosdrm
Yup. I use @view(s) routinely now for most such things. I found that the naked BLAS calls were noticeably faster when I did the experiment with Julia 1.1 for the application I had (classical Gram-Schmit orthogonaliztion twice for an Arnoldi factorization. BLAS.gemv! is still what I use, but I plan to give mp! a shot when I find the time.
Another noteworthy difference:
Julia permits aliasing of procedure arguments. In this respect,Jjulia is closer to C than Fortran. Some code transformations that depend on alias analysis need to be done manually by the programmer, instead of relying on the compiler. The loved/hated restrict keyword from C has no analogue in julia.
I found it really useful the first time I sat down to understand the language, coming from Python and C# and MATLAB.
Afterwards I read the rest of the docs.