Fortran.CodeCompared.To/Odin

The shapes correspond directly: program/end program becomes package plus a main procedure, and print * becomes fmt.println. Odin needs no implicit none because implicit typing never existed — every name must be declared before it can be used.

This removes a specific Fortran chore: the dependency ordering that .mod files impose, which is why a Fortran project needs a build tool the moment it exceeds two files. What Odin does not give back is a package registry — like Fortran before fpm, dependencies are source you copy into your own tree.

Two habits transfer immediately: explicit types (Odin has no implicit typing to switch off) and initialization. Fortran leaves an undeclared-value variable genuinely undefined, while Odin guarantees zero unless you write = --- to opt out — so the = 0 initializers that discipline demands are unnecessary.

This maps almost exactly onto parameter: both are compile-time values with no runtime storage, both can be used as array bounds, and both reject assignment. The difference is that Odin does not need a separate attribute — the declaration operator itself says "constant".

This removes the portability question iso_fortran_env was introduced to answer: f64 is 64 bits everywhere, so the real(kind=8)-versus-real(real64) ambiguity that made older code non-portable has no equivalent.

This is a real safety gain over Fortran's mixed-mode rules. The ratio = count / 2 bug — where the division happens in integer arithmetic before the assignment widens it — cannot be written in Odin, because the compiler stops at the mixed expression rather than silently promoting.

This is one of the strongest points of agreement between the two languages, and it is rare — most languages a Fortran programmer would consider make complex arithmetic a library type with method calls instead of operators. Here first * second means the same thing in both columns.

Short-circuiting is the substantive difference. The Fortran standard permits — and gfortran sometimes performs — evaluation of both operands of .and., which is why the guard-then-index idiom in the last block is not reliably safe in Fortran and must be written as nested if statements.

The sentinel return value (-1, -999, huge(0)) is a deeply worn Fortran habit, and its flaw is that the sentinel is also a legal value. Maybe removes the ambiguity, and unlike allocated() it does not require the value to be on the heap to express absence.

This is the single largest source of bugs when porting numerical code, and it is worth handling deliberately rather than by care: do i = 1, n becomes for i in 0 ..< n, and every hand-written index expression drops by one. Losing the chosen lower bound also matters more than it sounds — a stencil indexed (-1:1) now needs the offset written at every use.

Very few modern languages kept this, and its presence is a large part of why Odin suits a Fortran reader. The limit is that it applies to fixed-size arrays only, so a []f32 slice needs the loop — and the reduction intrinsics (sum, maxval, product, dot_product) have no operator form at all.

Two things differ beyond the indexing. There is no stride, so values(1:10:2) becomes an explicit loop. And an Odin slice always aliases, where Fortran decides between aliasing and copying based on context — which is safer here, since writing through the view visibly writes the original.

The storage order inverts, and this is a performance trap rather than a correctness one: the loop nesting that streams cache lines in Fortran walks memory in strides in Odin, and vice versa. The rule to carry over is unchanged in substance — make the last index the inner loop here, where Fortran wants the first.

This is where Odin gives the least back to a Fortran reader. Fortran's array intrinsics with optional mask= arguments are genuinely expressive and have no equivalent — though writing the loop does fuse what sum, count, and where would each traverse separately.

The mechanism is nearly the same; the difference is that it is visible and unconditional. A Fortran assumed-shape argument only works when an explicit interface is in scope, which is exactly why modules and contains exist. An Odin slice carries its length everywhere, with no interface block to keep in sync.

Modern Fortran deallocates an allocatable automatically at scope exit, which is genuinely safer than what Odin offers — defer is a line you must remember, and forgetting it leaks. The compensation is control: the memory-allocator rows below let you choose where the storage comes from, which Fortran cannot express at all.

The Fortran idiom in the left column is quadratic: each values = [values, x] allocates a new array and copies everything. Growing a collection is common enough that having the amortized version built in is a genuine improvement, and it is why Odin needs no equivalent of the manual double-and-copy routine that Fortran codebases usually carry.

Fortran keeps pointer association (=>) syntactically distinct from assignment (=) precisely because confusing them is disastrous; Odin distinguishes them by the ^ on the left-hand side instead. The target attribute has no equivalent — any variable's address can be taken, which removes a declaration chore and removes an aliasing guarantee the optimizer used to have.

This is the capability Fortran has no way to express, and it is what makes manual memory management practical rather than merely possible. Scratch workspace for one timestep, one iteration, or one solve stops needing individual deallocation: allocate into the arena and reset it when the phase ends.

This is the tool that makes the loss of automatic deallocation manageable. Instead of reaching for valgrind, you wrap the allocator for one run and get a list of allocations with the exact line that made each of them — which is a considerably shorter investigation than the Fortran equivalent.

Fortran's character(len=n) is a fixed-width field that pads with blanks and silently truncates anything longer — which is why trim() appears in almost every print statement in real code. The deferred-length character(len=:), allocatable form is the closer analog, and Odin's string behaves like that one by default.

Odin's string library is much larger than Fortran's handful of intrinsics — case conversion, splitting, joining, and prefix tests all ship with the language rather than being written per project. The price is that the allocating half needs a matching delete, which Fortran's deferred-length assignment handles for you.

The Fortran version does two awkward things this avoids: it needs an internal write to a fixed-width scratch variable just to format an integer, and each // concatenation reallocates and copies the entire accumulated string. The builder makes both costs disappear.

Fortran's internal read/write pair does this job through the I/O system, which is why converting a number to a string requires declaring a fixed-width scratch variable and remembering to trim it. Both languages report failure rather than raising, so the discipline is the same — Odin just spells it in one line.

Both languages store text as bytes and both report byte counts from len, so the starting point is the same. What Odin adds is a decoding iteration and a rune type, where Fortran's only standard route to non-ASCII text is a selected character kind that few compilers implement usefully.

The if statement; condition form has no Fortran equivalent and is worth adopting: the variable exists only inside the branch, so a value computed for one test cannot leak into the rest of the procedure. Fortran's single-statement if has no counterpart — braces are always required.

The counted loop translates directly once you account for the bounds: do index = 1, n becomes for index in 0 ..< n when it indexes an array, or 1 ..= n when the number itself matters. The one loss is the stride form — do index = 10, 0, -2 needs the explicit three-clause loop.

This is a close correspondence, and the no-fall-through behavior means the C habit of a forgotten break never arrives. Odin's switch also has a form that matches on the active variant of a tagged union, which the derived-types section uses.

This transfers almost verbatim, which is not something most languages allow: labeled loop exit is one of Fortran's quieter good ideas and C, C++, and C# all lack it. Odin only labels the loop being exited, not the end do, so there is no closing label to keep in sync.

Fortran's automatic deallocation covers the allocatable case, so the left column is worse than real code needs to be for memory alone. It is exactly right for everything else: closing a unit, restoring a saved setting, printing a trailer. Those cleanups genuinely do have to be repeated on every exit path in Fortran, and defer is why they do not here.

The function/subroutine split disappears, and with it the call keyword and the result(name) clause. Declaration order does not matter either, so the contains block that makes an interface explicit has no equivalent — every procedure in a package is visible to every other.

Fortran's intent attributes are one of its best features, and Odin arrives at the same discipline by different means. The improvement is at the call site: call adjust(total, doubled) gives no hint that either argument is modified, while adjust(&total) marks it and a returned value needs no out-parameter at all.

This removes the main reason Fortran code reaches for a subroutine over a function. It is also the shape the error-handling section builds on — a value paired with a status is the standard Odin signature, and it is a genuine function call rather than a call statement that cannot appear inside an expression.

This is strictly simpler than the Fortran pattern: no optional attribute, no present() test, and no local variable holding the effective value. The one thing lost is the ability to distinguish "not supplied" from "supplied with the default value" — where that matters, a Maybe(T) parameter says so explicitly.

This is a direct correspondence, and it is unusual: most languages express overloading by letting several declarations share a name, while Fortran and Odin both make the grouping an explicit declaration you can read. Odin adds a second route the next section covers — a single parametric procedure, which handles the case where the bodies would be identical.

elemental is the real loss: lifting a scalar function over an entire array is expressive and lets the compiler vectorize it. Odin recovers part of it — arithmetic on fixed arrays is element-wise natively, as the first line shows — but a user-defined procedure has to be applied by a loop.

The semantics match closely: both are plain value types with no hidden header, both copy on assignment, and both lay their fields out in declaration order. What Odin adds free is formatting and comparison — fmt.println(first) and first == second work on any struct, derived from the layout rather than written by hand.

The type_verb naming convention does the work shape%area() does in Fortran. Losing the binding also loses what class(...) enables — dispatch to an extended type — and the tagged union in the next row is the replacement for it.

Odin does have using on a struct field, which embeds another struct and promotes its fields — that is the closest match to extends for the data. What it cannot do is dispatch, so class(shape) polymorphism becomes this union, which the compiler checks for missing arms instead of leaving to a select type you wrote by hand.

Fortran gives you swarm%x as a component section, but the storage is still interleaved, so reading it strides through memory. Splitting the array of derived types into parallel arrays is the standard hand optimization in HPC codes; #soa is that transformation as one directive, with the field syntax preserved.

This is close to what Fortran modules do, with the ordering problem removed: no .mod artifact to build first, and no rule that a module must be compiled before its users. What is lost is use, only: — Odin always qualifies, so geometry.circle_area is written in full every time, which also means nothing can be shadowed by an import.

The models correspond well, with Odin defaulting to public and Fortran modules conventionally declaring private and then listing exports. Odin's extra level is @(private = "file"), which hides a helper even from the other files in its own package — finer than anything Fortran offers.

Both languages zero-initialize this storage, so the = 0 in the Fortran declaration is doing what save plus initialization implies rather than what it looks like. The habits around it should transfer too: package-scope mutable state is as awkward to test and as unsafe across threads here as a module variable is in Fortran.

The correspondence is direct: i5 is %5d, f8.3 is %8.3f, a10 is %10s. The thing to unlearn is the repeat-count and slash syntax of complex format strings — Odin has no equivalent, so a multi-line record is a loop over printf calls.

The unit-number bookkeeping that newunit= was introduced to make safe simply has no equivalent, and neither does the read-until-iostat-is-nonzero loop. What replaces the iostat= discipline is the same idea in Odin's shape — a second return value reporting success, which the caller must name to look at.

The Fortran version needs a fixed-width buffer, a returned length, a status code, and a trim to recover the actual text, because character(len=256) cannot describe a string of unknown size. This is the fixed-length character problem from the strings section in its most visible form.

Fortran already works this way — stat=, iostat=, and sentinel returns are all error values — so the discipline transfers directly. The two improvements are that the error type is a named enum instead of a magic integer, and that a sentinel like -1 is no longer needed, since the status travels beside the value rather than inside it.

This is the piece Fortran has no answer to. Checking iostat and returning early has to be written by hand at every call, which is exactly why so much Fortran code checks it once and then stops bothering. or_return makes forwarding shorter than ignoring.

Both languages draw the same line, which is unusual and worth noticing: an expected failure is a status value, while a violated invariant halts the program. Odin adds the stack trace and the ability to compile assertions out of a release build, neither of which error stop offers.

The defaults are inverted, and Odin's is the safer one: Fortran compilers ship with -fcheck=bounds off, so an out-of-range read in production silently returns whatever was next in memory. The compile-time rejection of a constant index has no Fortran equivalent at all.

Very few languages ship a matrix type with a real product operator, and Odin is one of them — matmul(a, b) becomes a * b. Note the layout difference in the literal: Fortran's reshape fills down the first column, so the same visual arrangement means different matrices in the two columns.

The set corresponds nearly one for one, including the mod/modulo distinction: % truncates toward zero like mod, and math.floor_mod follows the sign of the divisor like modulo. That difference causes real bugs with negative operands in both languages.

Fortran's inquiry intrinsics are more systematic: epsilon(x) takes any variable and answers for its kind, so generic numerical code can query the precision it was instantiated with. Odin names each constant per type, so a parametric procedure needs a when on the type to pick the right one.

Fortran's random_seed is process-global and its size is compiler-dependent, which is why seeding it portably takes four statements. Putting the generator in the context means a routine can be given its own reproducible stream without changing any signature — useful when a simulation needs each worker seeded independently.

This is the largest capability gain on the page. Fortran's answer to a generic algorithm is duplication — the same body written once per kind and per type, collected in a generic interface, which is why numerical libraries ship four copies of every routine and why preprocessor-based code generation is so common in the ecosystem.

A Stack(int) and a Stack(f64) are separate types the compiler generates from one declaration, with no possibility of mixing them up. Fortran's parameterized derived types aim at the same thing but have had unreliable compiler support since 2003, so the practical Fortran answer remains duplication.

The consequence is that the compiler can fully unroll or vectorize the loop, because the trip count is known when the copy is generated. Fortran can only get there with an explicit-shape dummy argument declared for one specific size — the assumed-shape form used above learns its extent from the descriptor at runtime.

Fortran leans on the C preprocessor for this, which is why so many projects carry .F90 files and a -cpp flag. when is a real language construct with real scoping, and it composes with $ parameters so a generic procedure can specialize its body per instantiated type.

The two approaches are structurally the same: declare the foreign signature with C types, name the symbol, and call it. Odin needs no value attribute because pass-by-value is already the default, where Fortran passes by reference and must be told otherwise on every scalar argument.

Fortran needs bind(c) because its own derived types carry no layout guarantee, and it has no standard way to express a packed structure at all — matching a wire format or a file header means reading bytes and assembling fields by hand. #packed is a real improvement for anyone parsing binary data.

This is a step backward in convenience and a step forward in explicitness. do concurrent and an OpenMP !$omp parallel do parallelize a loop with one line and no restructuring; Odin makes you partition the range yourself. What Odin does not have any answer to is coarrays — distributed-memory parallelism is entirely outside its scope.

The base Fortran language has no threads and therefore no mutex — synchronization arrives through OpenMP directives, coarray sync statements, or a C binding, all outside the standard language. Odin puts real threads and real locks in the standard library, and puts the responsibility for using them correctly entirely on you.

This is the page's clearest win for numerical work. Splitting an array of derived types into parallel arrays is the standard hand optimization in HPC codes, and its cost is that the grouping disappears from the source: xs, ys, zs, and masses no longer say they describe one body. #soa gives the layout without the loss.

Both languages express the computation without a loop, which is more than most can say. The difference is one of guarantees: Fortran's whole-array expression is permission for the backend to vectorize, while an Odin fixed array of a hardware-friendly width maps onto the register directly — and the reduce half (sum, dot_product) is a procedure call here rather than an intrinsic.