
Is Nim unsafe? - Pharohbot
https://github.com/Araq/Nim/wiki/Unofficial-FAQ#is-nim-unsafe
======
gjm11
The same FAQ has a question "Why is it case/style insensitive?" and an answer
giving four reasons, _none_ of which supports "style insensitivity" in any
way.

"Style insensitivity" means that in Nim the following identifiers are treated
as equivalent: nOpenFiles, no_pen_files, Nope_NFiles. Insertion and removal of
underscores, as well as case, is ignored. I hope you weren't expecting to find
anything in your codebase using grep.

It seems a reasonable guess that, oh, maybe 99% of people wondering why Nim is
"case/style insensitive" are more worried about "style insensitivity" than
about mere "case insensitivity". (The other 1% haven't yet learned that Nim is
"style insensitive".)

~~~
SamReidHughes
Nim also has an experimental feature for a+b * c to parse as (a + b) * c, and
for a -b to get parsed as a(-b), because of the whitespace. The documentation
itself gives an example of echo (a,b) getting parsed as echo((a,b)).

Nim also allows passing by non-const reference without any indication of such
at the call site. Also it has semantic indentation, which is cute and clean-
looking but more effort to safely edit than the popular alternatives.

Everything I see in Nim is designed around being clever. Even in the
documentation they have clever extensions to BNF syntax that save such
precious characters.

~~~
dom96
> and for a -b to get parsed as a(-b)

It almost looks like you're suggesting that `a -b` will be parsed as a*(-b).
Let me just clarify, that is not the case. With the 'strongSpaces' feature, `a
-b` results in a compile-time error. Without that feature, it works as
expected (`a-b`).

> Nim also allows passing by non-const reference without any indication of
> such at the call site.

Why is this a problem?

> Also it has semantic indentation, which is cute and clean-looking but more
> effort to safely edit than the popular alternatives.

Could you give an example of how exactly semantic indentation makes the
language less safe? I have been using Nim (and Python) for years and have not
found this to be the case.

~~~
SamReidHughes
> With the 'strongSpaces' feature, `a -b` results in a compile-time error.

Unless there's a function named a? It doesn't matter, you're cherry-picking
your response.

> Why is this a problem?

Go ahead and tell us what benefits and detriments you're already aware of,
having thought about the question, and I'll tell you if you've missed
anything. e: I recommend looking at why C++ has non-const reference parameters
and how C# handles the problem and considering whether the benefits of this
feature could be had without its detriments.

> Could you give an example of how exactly semantic indentation makes the
> language less safe?

I said that it was more effort to safely edit. Your question drops the
specificity that we're talking about making edits to the code, and also that
we're talking about an effort/safety trade-off. Also, it's specifically the
kind of semantic indentation found in Python, not (to such a degree) the kind
typically found in Haskell. It's easy to find examples: Almost every edit that
moves code around takes higher cognitive load than the equivalent done in a
language where blocks are explicitly delimited.

~~~
beagle3
> Also, it's specifically the kind of semantic indentation found in Python,
> not (to such a degree) the kind typically found in Haskell. It's easy to
> find examples: Almost every edit that moves code around takes higher
> cognitive load than the equivalent done in a language where blocks are
> explicitly delimited.

I disagree. Moving code around in Java or C++, pure brace languages, has at
least as much cognitive load as Python does, and as most languages do. Are the
variables referenced defined in the new scope? do break/continue still
function as expected? Are exceptions properly handled and propogated?

The indentation is usually the least of one's worries when moving code around;
and at the very least, Python (and I assume Nim, though I hardly have any
experience with it) guarantees that the visual and logical code hierarchies
match; The fact that they might not is a constant cognitive load in curly
brace languages (and a source of bugs if you ignore it).

~~~
rwallace
> guarantees that the visual and logical code hierarchies match; The fact that
> they might not is a constant cognitive load in curly brace languages (and a
> source of bugs if you ignore it).

Well it's a cognitive load if you deal with it manually and the source of bugs
if you ignore it, but if you use an automatic indenting program, that solves
it once and for all, along with a few other problems.

~~~
beagle3
Same is true of Python (and I assume, Nim)

------
overgard
> It's not hard to "fix" this issue anyway. Where "fixing" means "pretending
> Nim created Ansi C code in the first place" (which it doesn't).

They should probably fix the wording of this -- as an outsider I can't really
parse the message conveyed here. If it doesn't create C code then why does the
comparison matter? Or is it just about the "ansi" part? But then why does that
matter?)

------
PopeOfNope
When I read between the lines, this section says to me: "Yes, Nim is unsafe,
but there are features on the way to help it be more safe."

'not nil' sounds like a great addition to the language, but what if you wanted
that to be the default behavior without having to pepper it throughout every
variable in your codebase?

~~~
Pharohbot
Well the biggest concern for most is null pointers, so invoking not nil on the
pointers would suffice for most

------
pyre
> Is Nim unsafe?

Are the binaries hosted on SourceForge?

------
Dewie3
Good old null pointer.

