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.
About 30:00+ - D has ability to declare "pure" functions explicitly which enforces some limitations but gives you and compiler some additional ability to reason about this code by providing additional guarantees on compile level. I dunno if something like it aligns with Zig's vision. But being able to get some additional guarantees and optimizations for cheap by just declaring "hey, Zig, my function sum(a, b) never does side-effects" - would be cool.
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
About 30:00+ - D has ability to declare "pure" functions explicitly which enforces some limitations but gives you and compiler some additional ability to reason about this code by providing additional guarantees on compile level. I dunno if something like it aligns with Zig's vision. But being able to get some additional guarantees and optimizations for cheap by just declaring "hey, Zig, my function sum(a, b) never does side-effects" - would be cool.
Doesn't comptime give you basically the same guarantees while being more capable? Are there use cases for which comptime is not strict enough?
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.