This Month with Nim: March 2023 | Hacker News Reader

This Month with Nim: March 2023

nim-lang.org

55 pointsxigoi18 comments

What's up with all the 2-space indentations?

I wonder why they used spaces at all. If they had used tabs, you could at least override the width with a userstyle extension using https://developer.mozilla.org/en-US/docs/web/css/tab-size

From NEP1:

Spacing and Whitespace Conventions

Lines should be no longer than 80 characters. Limiting the amount of information present on each line makes for more readable code - the reader has smaller chunks to process.

Two spaces should be used for indentation of blocks; tabstops are not allowed (the compiler enforces this). Using spaces means that the appearance of code is more consistent across editors. Unlike spaces, tabstop width varies across editors, and not all editors provide means of changing this width.

Their rationale for enforcing spaces over tabs is nonsense, particularly after you dive through their GH issues, find where this is discussed, and see the true reason is implementation simplicity.

Implementation simplicity also sounds good to me. BTW, it's discussed in the manual:

Nim's standard grammar describes an indentation sensitive language. This means that all the control structures are recognized by indentation. Indentation consists only of spaces; tabulators are not allowed.

The indentation handling is implemented as follows: The lexer annotates the following token with the preceding number of spaces; indentation is not a separate token. This trick allows parsing of Nim with only 1 token of lookahead.

Only allowing spaces was a good decision. It was supposedly inspired by a quote from Guido bin Rossum that if he could redo it he’d only allow spaces in Python, or something along those lines.

It eliminates lots of issues mixing code that has tabs or spaces like in Python. I’ve never had to worry about a lingering tab.

I think Deno also standardized on two spaces for indents and I find that’s not enough to be able to quickly identify the structure of code at a glance.

Is Nim requiring this at build time? If so, that would be an odd choice for a language that goes out of its way to let people call functions, capitalize variables, and manage memory however they want.

Indent size is up to the programmer.

You can name your symbols a_b_c, ABC, abc, or aBc - it's all the same! Tabs for whitespace though..? Don't be stupid

Well there is a practical reason that in a whitespace significant language you do not want to mix indentation types. I personally prefer tabs for the user customization, but the actual reasoning that generally speaking it was(is?) hard to get tabs to render as you want in a multitude of environments whereas spaces always render as is.

Quick someone reset the inane "Days since mentioning style insensitivity".

Would it be silly to suggest that a joke about a counter for "Days since mentioning style insensitivity" might point to a legitimate gripe many folk have with the language?

It's not a “legitimate gripe” if you can safely ignore it and it won't affect you (as long as you use a consistent naming style).

My new hobby is replying on every Rust post pushing to replace :: with another symbol. Barely use Rust, don't plan to, but it sounds funny to annoy them on the smallest bikeshed I can find.

done :) https://fosstodon.org/@pietroppeter/110118215100751621

To help save space on our 80 column CRT monitors? /s

You jest, but I do like to save space. If possible I like to have 2-3 editor columns which works well with Nim.

This lets me have context of having a test file in one column, some code in another, and the core types in another say.

Prettier (JS code formatter) defaults to 80 cols and by golly does it butcher code.

What's the problem?

Reply on news.ycombinator.com