Jai-Community-Library VS deno_lint

Comparatively

> Incremental rebuilds cause a lot of compilation problems, bugs, and errors. Incremental rebuilds are also slow due to the amount of in between files generated between builds. Jai will contain no incremental rebuild steps. All will be compiled in one fresh compilation. This means that the compiler will need to run fast with high performance. The eventual goal is to compile a 1 million lines of code in 1 second, but as of right now, the compiler can only do 250,000 lines in 1 second.

https://github.com/Jai-Community/Jai-Community-Library/wiki/...

Either ask very politely for years, or be in denial like half the Jai community that writes Jai but is never able to compile it.

Yes, there is a whole Jai community wiki made from half cobbled together knowledge (https://github.com/Jai-Community/Jai-Community-Library/wiki), and a super secret discord made for the super elite, non-compiler-having plebs are banned.

- Philosophical approaches behind project or lack thereof.

Now on the personal, subjective note, the more I look, the more I want to avoid V and get my hands on Jai [1][2]

[1] https://github.com/Jai-Community/Jai-Community-Library/wiki/...

Here's a community wiki that's been kept up-to-date https://github.com/Jai-Community/Jai-Community-Library/wiki

Also this one: https://github.com/Jai-Community/Jai-Community-Library/wiki

There is also the Jai community library, which contains pretty much all the information about the language currently. https://github.com/Jai-Community/Jai-Community-Library

Fast compilation seems very appealing. It is one of the main reason why I am interested into Go and Zig.

I recently started working with Rust for contributing to projects like Rome/tools [1] and deno_lint [2]. The compilation and IDE experience is frustrating. Compilation is slow. I am afraid that this is rooted to the inherent complexity of Rust.

[1] https://github.com/rome/tools

[2] https://github.com/denoland/deno_lint

Though, for large scale projects, I’d wait until https://github.com/denoland/deno_lint/issues/303 is done; if they tackle that, they tackled types, and that’s the single big thing yet to tackle.

There isn't any uniformity that could be reasonably achieved once plugins are added to a linter. Someone will always want an edge case for their project covered even if it's not in the uniform configuration; most large projects either use plugins or custom rules outside of what ESLint provides. Deno understands this too given that plugin support is being considered.

Deno's lint config is under deno.json or deno.jsonc and is limited to the following rules: https://lint.deno.land/

$ deno lint (prefer-const) `order` is never reassigned let order = new Order() ^^^^^ at /Users/dina/try-deno/design-patterns/state.ts:106:4 hint: Use `const` instead help: for further information visit https://lint.deno.land/#prefer-const Found 24 problems Checked 25 files

I built one of the tools mentioned in the article, Deno's linter. Its binary is over 30 MiB:

After a long time, I started contributing to open-source software. For a long time, I had my eye on Deno. This week, I merged my first PR in Deno Lint. Following is the detailed post about the issue.