# Version 1.0 released of Nim Programming Language

**URL:** <https://discourse.julialang.org/t/version-1-0-released-of-nim-programming-language/29099>\
**Category:** Offtopic\
**Created:** [September 24, 2019, 2:48am UTC](https://discourse.julialang.org/t/version-1-0-released-of-nim-programming-language/29099 "2019-09-24T02:48:42Z")\
**Posts on this page:** 1\
**Showing post:** 81

<div class="post-metadata">

**Author:** ![Tamas\_Papp](https://sea2.discourse-cdn.com/julialang/user_avatar/discourse.julialang.org/tamas_papp/32/25949_2.png) [@Tamas\_Papp](https://discourse.julialang.org/u/Tamas_Papp)\
**Post date:** [September 29, 2019, 8:27am UTC](https://discourse.julialang.org/t/version-1-0-released-of-nim-programming-language/29099/81 "2019-09-29T08:27:26Z")

</div>

> [@ninjaaron](#):
>
> I’d take type errors from the compiler before type errors at runtime every day of the week.

My understanding is that the key problem is that in general, proving something about types is difficult or infeasible, so for a large class of valid programs, even a very sophisticated compiler just can’t figure it out. Eg for

```julia
function fermat(a::Integer, b::Integer, c::Integer)
    # let's pretend there is no overflow
    if a > 0 && b > 0 && c > 0 && (a^3 + b^3 == c^3)
        "a fish"
    else
        42
    end
end

```

the result type is `Int`, but I am not sure very many compilers would figure this out (yes, this is a contrived example — but type inference can fail very easily in practice, too).

When this happens, traditionally “static” languages just consider your program invalid (not proven correct, it is considered incorrect). Instead, Julia will just try to work with it.

In general it is very difficult to prove that some code is incorrect in Julia _in advance_, because new methods, functions and global variables can be defined at any point between the definition and the AOT compilation.

---

_[View the full topic](https://discourse.julialang.org/t/version-1-0-released-of-nim-programming-language/29099)._