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 stops short of that: a bare assignment like count = 5 still compiles, and the compiler warns that implicit declaration is deprecated and asks for var. Write var every time, as this example does, and treat the warning as the error it is on its way to becoming in your own code.

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 import before these functions can be used — from std.math import sqrt, sin, since the standard library lives under std.

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 strings carry no padding either, but they are UTF-8, so Mojo asks which length you mean: len() on a String is a compile error, and byte_length() gives the byte count used here.

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 rejects s[a:b] outright — the compiler explains that in UTF-8 a numeric range is ambiguous between bytes and characters — so the 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 rejects a negative index — numbers[-1] is a compile error — so the last element is 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 (def 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 writes the same dispatch the way Python traditionally does — an if/elif chain of equality comparisons — 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 iterates the elements themselves, and enumerate() pairs each with its index — Python's idiom, and just as short as the Fortran loop.

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 def __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, and the value it catches has the type the called function raises: Error, carrying a message, as here, or a struct of your own when the function declares one — raises DivideByZero — which lets the caller read its fields.

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.

This row used to record an agreement: neither language had a finally clause, so cleanup had to be repeated by hand on every exit path in both. Mojo 1.0 has one — measured running on the body-succeeded, exception-caught and early-return paths — so the agreement is gone, and only Fortran still duplicates the line. Fortran offers no equivalent at all: no finally, no destructors, no defer, so the repetition in the left column is not a style choice but the only option the language gives you.

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 builds the same string by 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 reached 1.0 recently and is still evolving quickly: the compile-time-constant keyword alias has been deprecated in favor of 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 — 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.

gfortran is a mature, decades-old compiler packaged by virtually every OS distribution. Mojo is installed from PyPI instead — pip install mojo==1.0.0 — and the version pin is the part to remember: an unpinned install fetches the newest release the moment it is published, which can already differ from what a tutorial, or this page, was written for.