Fortran.CodeCompared.To/Mojo

A Fortran program is a single program name ... end program name block. Mojo, like Python, always begins execution at a specific function named main, marked raises since almost any Mojo function that does real work might raise an error — there is no equivalent of Fortran needing no special execution-entry marker at all.

Fortran comments use !; Mojo, inheriting Python's syntax, uses # — both run to the end of the line, and neither language has a block-comment syntax.

Despite Mojo's Python-like syntax, it compiles ahead of time to native machine code, just like Fortran — mojo build produces a standalone binary. This is a deliberate design choice distinguishing Mojo from Python's interpreter, aimed squarely at Fortran and C's traditional performance-critical audience.

Fortran with implicit none makes explicit declaration truly mandatory — omitting a variable's declaration is a compile-time error, full stop. Mojo's var keyword looks like it plays the same enforcing role, but it does not: a bare assignment like count = 5 silently declares a new local variable, with no var required at all. var is best understood as an optional, explicit-declaration style choice in current Mojo, not a mandatory gate the way implicit none is in Fortran.

Both languages require declared types for every variable in their strict mode: Fortran's character(len=20)/integer/real map onto Mojo's String/Int/Float64 — note Mojo capitalizes its type names, and Int is machine-word-sized (64-bit on modern hardware) rather than a fixed 32-bit width the way an unqualified Fortran integer typically is.

Fortran's parameter attribute and Mojo's comptime both create true compile-time constants substituted at compile time, rejecting any attempt at reassignment. (Older Mojo code uses the now-deprecated alias keyword for the same thing — comptime is the current spelling.) Mojo comptime constants can additionally appear in compile-time parameter positions (such as a SIMD vector's width), a role Fortran's KIND-parameter system plays for numeric precision.

Both languages reassign with a bare =. Mojo additionally has compound assignment operators (+=, -=, and so on) inherited from Python, which Fortran lacks entirely — Fortran always spells out counter = counter + 5 in full.

Fortran's boolean literals are .true./.false., surrounded by dots. Mojo's Bool type uses the capitalized Python-style literals True/False. Both are genuine boolean types requiring an actual boolean value in an if condition, with no truthy/falsy coercion of numbers or strings.

Fortran's plain / performs integer division when both operands are integers. Mojo, inheriting Python's operators, uses a dedicated // for integer (floor) division and % for the remainder — plain / in Mojo always produces a floating-point result regardless of operand types, similar to the distinction R and Julia also make.

Both languages agree here: Fortran and Mojo both use ** as a dedicated exponentiation operator, unlike C or Pascal, which have none at all (Mojo inherits this operator from Python).

Fortran's sqrt and sin are intrinsic — always available with no import. Mojo, like Python, requires an explicit from math import sqrt, sin before these functions can be used.

Fortran's KIND-parameterized integer(kind=int8)/integer(kind=int64) map onto Mojo's explicitly-sized Int8/Int64 types — both give the programmer precise control over storage width, chosen by picking a type name in Mojo versus a kind parameter in Fortran.

Fortran concatenates with the dedicated // operator. Mojo, like Python, reuses the ordinary + arithmetic operator for string concatenation. Mojo strings are dynamically sized with no declared maximum, unlike Fortran's fixed-width, blank-padded character(len=n) fields.

Fortran needs len_trim() to get the length ignoring trailing blank padding. Mojo's len() always returns the exact character count, since Mojo strings carry no fixed width or padding to account for.

Fortran has no built-in case-conversion intrinsic — converting case requires a hand-written loop over character codes. Mojo, like Python, provides .upper() and .lower() string methods directly, a case where Mojo's standard library is considerably more convenient for a common text operation.

Fortran's phrase(1:5) extracts a substring directly by numeric position with bracket syntax. Mojo's String type in current versions restricts plain bracket range-slicing (it requires an explicit, currently awkward byte-vs-codepoint disambiguation to stay UTF-8-safe), so the more robust everyday idiom is .split(delimiter), which returns a list of pieces — well suited to extracting words separated by a known delimiter, though less general than Fortran's arbitrary-position slice for extracting a substring at an exact numeric offset.

Fortran arrays are fixed-size, declared with their length up front and filled with a literal in one step. Mojo's List[Int] is dynamic and typed, built incrementally with .append() rather than a single literal — closer in spirit to Fortran's allocatable arrays than to a plain fixed-size integer :: numbers(4).

Fortran arrays default to 1-based indexing. Mojo's List is 0-indexed, matching Python — but unlike Python, Mojo's List does not support negative indices at all in current versions, so numbers[-1] is not available; the last element must be reached with numbers[len(numbers) - 1], exactly the pattern Fortran's 1-based numbers(size(numbers)) already uses.

Fortran has no built-in hash map or dictionary type at all — an equivalent key-value lookup requires a hand-rolled derived type with parallel arrays, a manual search, or a third-party library. Mojo's Dict[K, V], inherited conceptually from Python, provides one directly with familiar subscript syntax.

Fortran applies arithmetic to a whole array directly — prices * 0.9 scales every element with no loop, and the compiler decides internally whether to use SIMD (single-instruction-multiple-data) CPU instructions. Mojo makes this explicit at the type level: SIMD[DType.float64, 4] is a vector type that maps directly onto a CPU SIMD register, and prices * 0.9 compiles to exactly one vectorized instruction rather than relying on the compiler to infer that opportunity — a more explicit, but also more constrained (the width must be a power of two), take on the same underlying hardware capability.

Fortran's sum() intrinsic totals an array in a single call, letting the compiler vectorize internally. Mojo's .reduce_add() method on a SIMD vector performs the equivalent horizontal sum — on modern hardware, both compile down to genuinely vectorized machine code, just reached through different levels of explicitness.

Fortran's KIND parameters (real(kind=real64)) let the compiler generate code specialized to a chosen numeric precision, decided once and used consistently. Mojo's square-bracket compile-time parameters (fn sum_batch[batch_size: Int](...)) generalize this idea beyond just precision: the compiler generates a fully specialized version of the function for each distinct batch_size it is called with, including the exact SIMD width — a more general, user-extensible mechanism for the same underlying goal of compile-time specialization.

Fortran's if / else if / else / end if and Mojo's Python-inherited if / elif / else read almost identically. Mojo uses indentation to delimit blocks, exactly like Python, rather than an explicit closing keyword like Fortran's end if.

Fortran surrounds its logical operators with dots (.and., .or., .not.). Mojo, like Python, spells them as bare lowercase words: and, or, not.

Fortran has a dedicated select case construct for matching one subject value against several branches. Mojo, inheriting Python's control flow, has no direct multi-way value-matching statement of its own — an if/elif chain of equality comparisons is the standard idiom, more verbose than Fortran's compact case labels but functionally equivalent.

Fortran's do i = 1, 5 is an inclusive range. Mojo's range(1, 6), inherited from Python, is a half-open range — the upper bound is exclusive, so counting 1 through 5 needs range(1, 6), not range(1, 5).

Fortran's do while (condition) and Mojo's while condition: are functionally identical — both test the condition before each iteration.

Fortran's cycle (skip to the next iteration) and exit (break out of the loop) map onto Mojo's Python-inherited continue and break — the same two concepts, different names for the first one.

A Fortran do loop already gives you a numeric index for free, so iterating "with index" needs no special construct at all. Mojo's List currently has no built-in enumerate()-style helper (unlike Python), so the standard idiom is range(len(collection)) with subscript access — a case where Mojo is, for now, more verbose than Fortran for indexed iteration.

Older Mojo documentation describes two function keywords: def for a loosely, dynamically typed Python-compatible mode, contrasted against a strictly typed fn. First the gap closed — an unannotated def parameter became a compile error. Then, in Mojo 1.0, fn was removed outright: writing it now gives error: 'fn' has been removed; use 'def' instead. There is one function keyword and it is the strict one. Fortran's single, uniform strictness under implicit none — one mode, applied everywhere, with no looser alternative to opt into — now describes Mojo exactly, which it did not when this page was first written.

This is the headline parallel between these two languages. Fortran's intent(inout) and Mojo's mut parameter modifier serve the identical purpose: both let a function both read and modify the caller's actual argument in place, with the caller needing no special syntax at the call site (unlike C, which requires an explicit pointer and &). This is a far more direct correspondence than most languages compared to Fortran offer — Mojo's ownership-aware argument model was deliberately designed around the same "state your intent explicitly" philosophy Fortran has always had.

Fortran's intent(in) is an explicit annotation stating a parameter is read-only. Mojo makes read-only the default: any parameter without the mut keyword is automatically borrowed immutably, so displayScore needs no annotation at all to get Fortran's intent(in) behavior — the safer default is simply assumed unless mut opts out of it.

Fortran returns multiple values through several intent(out) parameters on a subroutine. Mojo, like Python, returns a genuine tuple that the caller destructures directly — no output-parameter convention needed at all, since a Mojo function can return more than one value as naturally as it returns one. The return type must be spelled out as Tuple[Float64, Float64] rather than bare parentheses, since Mojo requires an explicit, named type for every value, including compound ones.

Fortran requires the explicit recursive keyword before a function may call itself. Mojo has no such requirement — any function may call itself freely with no special declaration needed.

A Fortran type and a Mojo struct both group named, typed fields, accessed with a member operator — % in Fortran, . in Mojo. Both automatically generate a memberwise constructor from the declared fields in order (Fortran always does this; Mojo needs the explicit @fieldwise_init decorator, plus listing the Copyable and Movable traits that must be enabled deliberately).

Both languages agree here, unlike Python or Ruby: assigning a Fortran derived-type value or a Mojo struct value copies the entire value — the two variables become fully independent, and modifying one never affects the other. Mojo requires the type to explicitly list the ImplicitlyCopyable trait to allow a plain = to copy it this way (the more basic Copyable trait alone permits only an explicit .copy() call), making the capability opt-in and precisely spelled out, rather than universal and implicit the way it is for every Fortran derived type.

Fortran's derived-type constructor is always the automatically-generated, positional one — there is no way to write custom initialization logic (validation, computing a derived field, and so on) inside the type definition itself. Mojo structs support an explicit fn __init__(out self, ...) method, letting arbitrary logic run during construction — the out self parameter marks that this function initializes a not-yet-existing instance, rather than receiving an already-built one.

A plain Fortran derived type has no methods bound to it by default — area() is a free function taking the type as an ordinary parameter, called as area(my_circle). Mojo structs support genuine instance methods defined inside the struct body, called with dot syntax (myCircle.area()) much like Ruby or Python. (Later Fortran standards do support type-bound procedures for a similar dot-call style, but the plain free-function form remains the simpler, more common default shown here.)

Fortran has no exception-handling mechanism — an error condition is communicated through a status flag the caller must check explicitly. Mojo's raise Error("message") raises a genuine, catchable condition, and a function that might raise must declare raises in its signature (verified by the compiler along the whole call chain) — a recoverable middle ground Fortran has no equivalent of.

Since Fortran has no exception mechanism, distinguishing error kinds always means checking a sentinel value or a status code by convention. Mojo's try/except catches a genuine Error condition — but unlike Python's rich exception hierarchy (ValueError, TypeError, and so on), Mojo currently has only one Error type carrying a plain message string, so except error: always catches everything with no type-based filtering available.

When a Fortran subroutine calls another that can fail, every caller in the chain must remember to check the status flag manually and decide what to do — nothing propagates automatically, and forgetting one check is a silent bug. When a Mojo raises function calls another raises function without a try block, the error propagates up the call stack automatically, compiler-verified at every step by the raises annotation each function in the chain must declare.

Both languages agree here, unlike Python, Java, or Julia: neither Fortran nor current Mojo has a finally clause that runs unconditionally regardless of success or failure. Cleanup code must be duplicated after every exit path by hand in both languages — a genuine similarity between an ancient language and one of the newest on this site.

Fortran's use module_name, only: names and Mojo's Python-style from module import names both selectively import specific names from a larger module — a close syntactic parallel, differing mainly in keyword order and punctuation.

Fortran has no built-in mechanism for calling into a dynamic scripting language's ecosystem — bridging to Python from Fortran requires a separate tool such as f2py, built and maintained outside the language itself. Mojo can import and call arbitrary Python packages (including ones with no Mojo-native equivalent, like NumPy here) directly through Python.import_module(), a genuinely unique capability with no Fortran parallel at all — a deliberate design choice letting Mojo code incrementally adopt the vast existing Python ecosystem.

print *, ... in Fortran and print(...) in Mojo both accept a comma-separated list of values and print them on one line with automatic spacing between them and a trailing newline — one of the closer syntactic matches between the two languages.

Fortran builds a formatted string by writing to a character variable used as an "internal file," with a FORMAT descriptor controlling the layout. Mojo has no distinct formatted-write mechanism of its own yet — string building goes through ordinary concatenation and explicit conversion (String(year) converts an Int to its text representation), the same approach a Rubyist would use with to_s before string interpolation became idiomatic.

Fortran 2018 is a fixed, ratified standard — example code from a decade-old tutorial still compiles today with the same meaning. Mojo is still pre-1.0 and evolving quickly: the compile-time-constant keyword has moved from alias to comptime, len() on a String has been withdrawn as ambiguous (it now insists you choose byte_length(), codepoints or graphemes), the math module has moved to std.math, and the fn keyword has been deleted from the language — all during this page's own lifetime. Assumptions carried over from earlier Mojo material stop holding remarkably fast. A Fortran programmer's instinct that "the language reference from a few years ago is still accurate" does not transfer to Mojo yet — always verify against the actual compiler in use.

Every Fortran array, with no exceptions, supports whole-array arithmetic — there is no separate "vector type" needed to unlock it. In Mojo, only the dedicated SIMD type gets elementwise operators; the general-purpose List type does not support * or + across its elements at all, so scaling every element of a List still requires an explicit loop, just like C or Pascal. A Fortran programmer's reflex that "arrays always support whole-array math" only transfers to Mojo's SIMD type, not to its everyday dynamic collections.

This is a maturity gap rather than a language-design one, but worth knowing: gfortran is a mature, decades-old compiler packaged by virtually every OS distribution and package manager. Mojo, being far newer, requires installing the Modular SDK directly rather than using a system package manager — installing it is a deliberate step rather than one line of a package manager, which is the practical difference a newcomer meets first.