That is not fully true, as foo:bar is not the same as foo: bar. Elixir is whitespace sensitive language (it just to not use off-side rule).

Tabs weren’t designed for indentation. Tabulation character was designed for tabular data (it is in the name). So some people say “tabs for indentation, spaces for alignment” this is explicitly against design purpose of tab, as tab was exactly for alignment purposes (that is also why tabs are elastic, so you can adjust the tab stop to match your table data).

But going back to the argument, while I agree that for some visually impaired people tabs have more sense than spaces I still prefer spaces over tabs, because tooling around tabs is enormous pain in the arse.

1. You want to enforce the maximum line length? Good luck with doing that just in editor when there are elastic tab widths. You can enforce it with formatter, but for me it will be enormously irritating during work if I would use different TS than rest of the team, as it would constantly move stuff around.
2. Online tooling is super inconsistent wrt to the support of the tab stops. GitHub only recently (2-3 years ago) gained support for custom tab stops and support for defining tabs stops in the project (via .editorconfig). Earlier it was defaulting to 8 and you either like it or you can GTFO. Other tools not always provide such flexibility.
3. Support for multiple tabletops in single project is poor in case of CLI/TUI tools. You want to have different TS for Makefile (8), Rust (4), and Elixir (2) files? Good luck when you will fire git diff and you will have changes in different files.

Some may say, “well, we can fix these tools to allow that stuff”. Yes, we can, but at the same time we can fix these tools to

• Support displaying leading spaces with different width than the rest of line
• Add support to the editor to support braille reader in a way that will for example start line with <indentation width><space> to provide a way for the user to know how deeply indented they are without shifting through N characters (no matter what these are) or just simply display the leading spaces differently from other spaces (just like editor in general often do).

So yes, this is a problem, but saying that “spaces are the problem, and the only solution is to move to tabs” is the same as saying “you are the problem, fix yourself”.

Finally, a topic worth a discussion.

I don’t disagree with any of these arguments. The braille one is especially compelling. I think there are a couple of things that make this awkward for Elixir, though.

One thing you can’t do with tabs, which the Elixir formatter makes use of, is line up code with odd/random spacing. Take with for example of how multi-head anonymous functions get lined up when reaching the line length. There’s no way for the formatter to do that in a way will reliably look nice across editor configurations.

The other thing is line length. With Elixir being a dynamic language it encourages full names for variables whereas I believe Go encourages single letter variables. When you start having longer variable names, larger indentations are going to make for very long lines. Maybe I’m not thinking through it well enough, but it would require the formatter to figure out how to collapse indentation that isn’t necessarily even (as per the first paragraph) in order to figure out if the line length is all right.

Accessibility concerns are very important but it’s just so hard to please everyone. Different editor tools can help—dimming code outside the current block or highlighting ends differently, for example. I don’t like saying “just rely on your editor” though it applies here since that’s the idea behind using tabs. Editors are also capable of retabbing when opening a file and converting back before saving, though that is far from ideal.

I am sympathetic to people with poor or no eyesight – I am at -6.75 dioptres of myopia myself.

It’s just that statistically it doesn’t make sense to inconvenience most of the people to cater to a smaller portion of people. Plus those with special needs already have specialized tools, as far as I am aware.

Bringing this to VScode, Emacs and [Neo]Vim will cause a huge stink.

Though realistically I don’t see a problem to just f.ex. make an Emacs or NeoVim function that changes tab width at the press of a keyboard shortcut either.

Yeah, noise for me too, but I also generally avoid deep nesting because it’s usually an indicator of some other smell.

I have to admit that with breakindent, breakat and showbreak I really don’t care about line width, although like nesting it’s definitely another indicator for smell.