The "600 line diff" view that Andrew mentions preferring is how I actually use elm-review most of the time. I run it with --fix-all and auto apply the fixes, then skim through the git diff. Makes it really easy to see what's happening at a large scale.
Would be interesting to roll zls into the compiler executable- so it becomes a runtime param “zig ls” Then it would always be in synch with the compiler version, and benefit from the parser, hot code reload, etc
Golangci-lint has a lint check for long lines which is good, but it also triggers on long lines which sometimes have to be long and sometimes they should be broken up.
The "600 line diff" view that Andrew mentions preferring is how I actually use elm-review most of the time. I run it with --fix-all and auto apply the fixes, then skim through the git diff. Makes it really easy to see what's happening at a large scale.
Would be interesting to roll zls into the compiler executable- so it becomes a runtime param “zig ls”
Then it would always be in synch with the compiler version, and benefit from the parser, hot code reload, etc
they could include it in 1.0 version because everything is changing in the language right now that's why docs is not also complete.
Golangci-lint has a lint check for long lines which is good, but it also triggers on long lines which sometimes have to be long and sometimes they should be broken up.
Right into the part of zig that bothers me the most! I would love more nuanced language server support in Zig, though I realize it's a super tough job
I love it if Zig will take some of the Elm language ergonomics!
@@angeloceccato zig prioritizes reading over writing, hence why lots of things have to be explicit. Despite that the ergonomics are quite nice.
Someone should mention algebraic effects to Andrew.