# Julia: Fast as Fortran, Beautiful as Python

**URL:** https://fortran-lang.discourse.group/t/julia-fast-as-fortran-beautiful-as-python/1405
**Category:** Uncategorized
**Created:** [June 20, 2021, 6:21pm UTC](https://fortran-lang.discourse.group/t/julia-fast-as-fortran-beautiful-as-python/1405 "2021-06-20T18:21:13Z")
**Posts on this page:** 1
**Showing post:** 6

<div class="post-metadata">

### Author: ![FortranFan](https://avatars.discourse-cdn.com/v4/letter/f/96bed5/32.png) [@FortranFan](https://fortran-lang.discourse.group/u/FortranFan)
#### Post date: [June 20, 2021, 7:57pm UTC](https://fortran-lang.discourse.group/t/julia-fast-as-fortran-beautiful-as-python/1405/6 "2021-06-20T19:57:18Z")

</div>

> [@certik](#):
>
> … For simple benchmarks like this, Fortran should not be slower.

@certik,

As was shown in your other [**thread**](https://fortran-lang.discourse.group/t/simple-summation-8x-slower-than-in-julia/1171/44), there is much that can be questioned about such comparisons.

Ok so the previous thread established Julia implementation has somewhat faster **trig** functions compared to readily-accessible Fortran implementations such as gfortran currently and there are some macros with Julia developed by highly zealous enthusiasts that enable convenient **non-sequential** calculations (vectorized/threaded/parallel, etc.) but these are hardly aspects of the language itself, especially Fortran.

Thus, not only do the comparisons posted at GitHub by “mdmaas” appear entirely amateurish technically (who in their right mind posts benchmarks of Fortran function evaluation using a NumPy driver!) they have all the subtle elements of **bias** that can lead to pointless “language wars”.

---

_[View the full topic](https://fortran-lang.discourse.group/t/julia-fast-as-fortran-beautiful-as-python/1405)._