You already know Fortran.Now explore other languages.

Where a Fortran programmer stops declaring the machine and starts describing the problem. Ruby trades static types, kinds, and fixed-size arrays for a dynamic, garbage-collected world where every value — even an integer — is an object, arrays are 0-based and grow on demand, and dictionaries, closures, and exceptions are everyday tools.

• No declarations, no implicit none, no KIND — a variable takes any object on assignment, and integers grow to arbitrary precision with no overflow
• Arrays are 0-based and dynamic — the first element is numbers[0], and push/pop resize in place, with no allocatable or allocate
• Blocks and Enumerable — map, select, and reduce replace the index loops and temporary result arrays you write by hand in Fortran
• Hashes — a built-in key–value map with O(1) lookup, the dictionary Fortran never had; no parallel-array workaround, no linear search
• Real exceptions — raise and begin/rescue/ensure replace iostat status codes and the halt-only stop/error stop

The other ubiquitous systems language — but C is row-major where Fortran is column-major, and passes by value where Fortran passes by reference, two classic sources of real interop bugs between them.

• Row-major array storage — the opposite of Fortran's column-major, a classic source of silent bugs when interfacing the two
• Passes everything by value by default; Fortran passes everything by reference — an intent(out) parameter needs an explicit pointer and & in C
• No exponentiation operator at all — pow() from <math.h> is the only way, and ^ means bitwise XOR
• 0-based indexing versus Fortran's 1-based default
• Arrays decay to a bare pointer at a function boundary, losing all size information — Fortran's assumed-shape arguments retain their own size
• The two oldest languages still in everyday use on this site (1957 and 1972) — both ahead-of-time compiled, both manual memory management

Where column-major stops being a rule and becomes a stride constant. The conventions a Fortran programmer works around every day — 1-based subscripts, everything by reference, the trailing underscore, the array descriptor — are all visible here as offsets, addresses and symbol names.

• Column-major means stepping the first subscript moves one slot and the second moves a whole column — which is why the first subscript belongs in the innermost loop, and why the identical nest wants the opposite order in C
• The classic ABI passes everything by reference, intent(in) included, so a call site is a row of lea instructions rather than movs
• subroutine work becomes the symbol work_ — lowercased and underscored, which is exactly what you must write on the C side when linking by hand
• An assumed-shape values(:) argument arrives as a descriptor — a struct holding the pointer and the bounds — which is why size() works inside the callee and why an explicit interface is mandatory
• 1-based indexing costs nothing: the lower bound is a compile-time constant folded into the addressing mode, so a 1-based array and a 0-based one emit identical code

Built for exact money math, not floating-point science. COBOL's PIC 9V9 fixed-point fields store decimal digits exactly — the opposite tradeoff from Fortran's binary REAL/DOUBLE PRECISION, which is precisely why COBOL, not Fortran, runs the world's bank ledgers.

• PIC 9V9 fixed-point decimal fields store money exactly — no IEEE 754 rounding error the way Fortran's REAL always carries
• Four mandatory DIVISIONS (IDENTIFICATION/ENVIRONMENT/DATA/PROCEDURE) replace Fortran's single program ... end program block
• A plain PROCEDURE DIVISION paragraph takes no parameters at all — no INTENT system, just shared global WORKING-STORAGE fields
• 88-level condition names are COBOL's closest thing to a LOGICAL type — there is no boolean type otherwise
• MOVE, not =, is the assignment verb, and CALL can only invoke a genuine subprogram, never a paragraph
• One of the two oldest languages on this site alongside Fortran (1959 vs. 1957) — both still running critical infrastructure decades later

A close cousin from the same structured-programming era. Pascal's var/const parameter modes map almost directly onto Fortran's intent(inout)/intent(in) — but Pascal has no whole-array arithmetic at all, unlike Fortran.

• var and const parameters mirror Fortran's intent(inout)/intent(in) almost exactly — a rare direct correspondence
• No whole-array operators at all — prices := prices * 0.9 needs an explicit for loop, unlike Fortran's native array arithmetic
• Real functions usable inside expressions, just like Fortran — no COBOL-style output-parameter workaround needed
• No ** exponentiation operator — Power() from the Math unit is the only way to raise to a power
• repeat...until is a post-tested loop with no direct Fortran equivalent
• Both languages default to 1-based array indexing — no adjustment needed moving between them

Built for exactly Fortran's audience — high-performance numerical computing — with Python-like syntax and an intent-like argument model.

• mut parameters map onto Fortran's intent(inout) almost directly — borrowed (read-only) is the default, just like intent(in)
• SIMD[DType, width] vector types are an explicit, type-level take on the same hardware vectorization Fortran's compiler infers automatically
• Compile-time square-bracket parameters generalize Fortran's KIND system beyond just numeric precision
• Compiles ahead of time to native code, like Fortran — despite the Python-like syntax, there is no interpreter
• raise/raises gives Mojo a genuine catchable-error mechanism Fortran has never had
• Still pre-1.0 — syntax is actively evolving, unlike Fortran's decades-stable ratified standard

Built explicitly to replace Fortran in scientific computing. Julia arrays are column-major for BLAS/LAPACK compatibility, just like Fortran — but * means real matrix multiplication in Julia, not the elementwise operation it always is in Fortran.

• Column-major array storage, matching Fortran exactly — deliberately chosen for BLAS/LAPACK interoperability
• * between two matrices is genuine linear-algebra multiplication in Julia; Fortran's * is always elementwise, with matmul() for the real thing
• Multiple dispatch resolves at compile/JIT time from an open, extensible set of methods — Fortran's generic interfaces resolve from a closed, fixed list
• JIT-compiled, not ahead-of-time — a script compiles the first time each function runs, in the same process that executes it
• Square-bracket compile-time parameters generalize Fortran's KIND system beyond just numeric precision
• 1-based indexing, matching Fortran and MATLAB — deliberately, not by accident

Array programming taken to its extreme. Where Fortran writes a loop over each element, APL has no loop at all — 2×1 2 3 4 5 doubles a whole array in one glyph, and reduction operators replace both sum() and hand-written accumulator loops alike.

• No explicit loops anywhere — 2×numbers scales a whole array with no do loop, more radical than even Fortran's own native array arithmetic
• Right-to-left evaluation with no operator precedence at all — 2×3+4 is 14, not 10, a rule Fortran's ordinary math notation shares nothing with
• Reduction glyphs (+/, ×/, ⌈/) replace Fortran's sum(), product loops, and maxval() all with one composable operator
• A single character is a complete, working array-processing program — the opposite extreme from Fortran's verbose, fully-typed declarations
• Trains compose functions tacitly with no named variables at all — (+/÷≢) is the average function, something Fortran has no syntax to express
• Both languages are deeply array-oriented, but APL treats the array operator itself as the entire unit of computation, where Fortran still writes ordinary scalar-shaped statements that happen to broadcast

The other vector-native language — but where Fortran demands exact shape conformance for elementwise arithmetic, R silently recycles mismatched-length vectors to fit.

• Whole-vector arithmetic is native, exactly like Fortran — numbers * 2 needs no loop in either language
• Vector recycling silently repeats a shorter vector's elements to match a longer one — Fortran would refuse a shape mismatch outright
• No type declarations at all, not even a LOGICAL equivalent — a variable's type is just whatever value it currently holds
• 1-based indexing, matching Fortran and unlike almost every other language compared on this site
• NA is a first-class missing-value marker with no Fortran equivalent — the closest approximation is IEEE NaN
• No compile step — R is interpreted, so a Fortran-style type mismatch only surfaces when that exact line actually runs

Closer than it looks. Odin is one of the very few modern languages that kept whole-array arithmetic, ships a builtin matrix type with real matrix multiply, and has complex as a primitive — then adds slices that carry their length, real generics, and #soa.

• Whole-array arithmetic survives: prices * 0.9 scales every element, at any length, with no loop and no temporary
• matrix[R, C]T is builtin and * is a genuine matrix product, so matmul(a, b) becomes a * b — and complex keeps its operators too
• Indexing is 0-based with no choosable lower bound, and arrays are row-major — the two traps to handle deliberately rather than by care
• A slice is the array descriptor made explicit: a pointer plus a length, so len is always right and no interface block has to stay in sync
• allocatable becomes make/delete plus defer — no automatic deallocation, but an arena can hand a whole solve its own memory and drop it in one call
• One generic body replaces the once-per-kind duplication that generic interfaces exist to gather, and #soa is the array-of-derived-type split without losing the field syntax