Hacker News Reader

Comment by losvedir | Hacker News Reader

I'm really excited about the code formatter. I'm glad more and more projects are following Go's lead on this.

How was the default style decided? And very importantly, what's the forum for users to bikeshed endlessly about how it should be different?

More seriously, as someone who's literally updating a bit of code to use a :simple_one_for_one supervisor right now - is the new DynamicSupervisor more about naming, so people understand it better, than semantics? I was under the impression that :simple_one_for_one, :rest_for_one, etc, were all standard erlang OTP supervisor strategies and that Elixir mostly deferred to them. Is it still using the same erlang semantics under the hood?

Oh, and edited to add: does that mean using `:simple_one_for_one` with a `Supervisor` is now deprecated? If so, what's involved in transitioning to the new approach?

View on HN

>is the new DynamicSupervisor more about naming, so people understand it better, than semantics?

It is mostly about naming, the semantics are the same. The DynamicSupervisor has a new feature called max_children that Erlang doesn't but that's it.

> Oh, and edited to add: does that mean using `:simple_one_for_one` with a `Supervisor` is now deprecated? If so, what's involved in transitioning to the new approach?

It will be eventually, probably on v1.8. Good question about transitioning. We should have some docs on that. I will work on it.

Just adding for others who might not have been aware otherwise:

> A `.formatter.exs` file can also be defined for customizing input files and the formatter itself

https://github.com/elixir-lang/elixir/blob/master/lib/mix/li...

While it's clear that a std formatter is a big win (I absolutely love elm-format), I'm somewhat afraid of this sort of change. Stuff like line length isn't only a personal preference, changing the width e.g. from 80 to 100 would seriously "break" my IDE window layout. At the same point, making it configurable would decrease the benefit of OneTrueStandard. Definitely a tough decision either way.

I think having something is way better than nothing.

I too like 80 max chars since it lets me fit 3 side by side code windows. From what I gathered this is configurable at a project level.

To me it seems like a huge step up from having to use a tricked out rubocop/flake8 config to detect issues while you have to manually fix them.

Just knowing I never have to deal with formatting again because Jose and gang put a crazy amount of effort into ensuring it does the right thing is really nice.

80 character max also fits nicely with the 4-6 inch column width for optimal readability.

I love the formatter but sometimes I arrange macros with uneven spacing to align categories of things in columns. It would be nice to have sections where you could disable the formatter.

You can have a .formatter.exs file where you'd specify input files for the formatter. You can't exclude files but you can achieve the same this way.

Agreed! I've always found formatting debates to be quite silly. Good to see that the community just enforces one format. How did it work out for the Go people? Some probably grumbled at first and then got used to it.

Go had the advantage taht the formatter came along very early in its usage. That meant that there wasn't an existing installed base of people with entrenched formatting ideas, so comments have mostly been positive about consistent code everywhere rather than complaints.

Reply on news.ycombinator.com