About time, js cli apps were never a good idea.

They exist because it's significantly easier to distribute js apps than it is to distribute a compiled app. npm install works on Linux, Mac and windows, regardless of what libc, Msys, crt, you have installed. It could be python, but pip is a usability nightmare

Not particularly true especially in this case. You can get a rust binary and run it anywhere regardless of libc or having cargo installed on the users machine. A Javascript CLI requires nodejs and npm to be installed before running it.

Same goes for Go BTW. I even find it easier to install Go (haven't done it for Rust that often yet) and compile a binary (of a "pure" project that doesn't involve C libraries or other complications) than installing node/npm/nvm/whatever to get something up and running...

In this particular case, you wouldn't be installing oxlint unless you had npm installed already?

For their main use case they do package it up for npm, but the crates folder have each portion available to build/distribute as a stand alone binary you can run against javascript without node or npm installed.

I've had significantly fewer issues with `cargo [b]install`ed compiled Rust programs than `npm install`ed ones. Getting nodejs/npm installed (and at an appropriate version) is not always trivial, especially when programs require different versions.

OOTH, Precompiled Rust binaries have the libc version issue only if you're distributing binaries to unknown/all distribtuions, but that's pretty trivially solved by just compiling using an old glibc (or MUSL). Whereas `cargo install' (and targetting specific distributions) does the actual compiling and uses the current glibc so it's not an issue.

I wish the nix programming language wasn't so rough because it can be pretty great at this problem. Being able to compile from source while just listing out package dependencies is powerful.

Cargo and crates.io is easily as simple as npm for installation and distribution. I find it to be more reliable than npm in general. Generally it’s very easy to write system agnostic software in Rust, as most of the foundational libraries abstract that away.

So when you say “compiled app” you might be referring instead to C or C++ apps, which don’t generally have as simple and common a distribution model. Rust is entirely different, and incorporated a lot of design decisions about how to package software from npm and other languages.

Cargo is still a dev tool and isn't a great distribution solution.

I disagree. Cargo is a great distribution tool, for Rust projects. I just tell people, first install rust, then just `cargo install`

Second, this was in response to an npm is simpler comment; npm and cargo are absolutely the same category of tool.

> I just tell people, first install rust, then just `cargo install`

local compilation may work for you and other individuals, but "just cargo install" can immediately run into issues if you're trying to deploy something to things that aren't dev workstations

> npm and cargo are absolutely the same category of tool

as a dev tool? absolutely. as a production distribution solution? definitely not

> as a production distribution solution? definitely not

If you’re talking about distributing Rust projects, sure it’s fine. Generally though, if you’re orchestrating a bunch of other things outside the rust software itself, I’d turn to just.

npm is still mainly used in JavaScript and Typescript scenarios, so I think you’re kinda splitting hairs if you’re suggesting it’s a general purpose tool.

there's a reason `cargo install` is usually the last distribution option that maintainers of rust software provide ¯\_(ツ)_/¯

The overlap between people who want to run something like ESLint and people with dev workstations is very close to 100%.

There's a significant difference between a machine that compiles rust quickly and a machine that can execute JS.

You just need to compile it once in a while. It's slow, yes, but really not that big of a deal.

I actually recommend cargo install cargo-binstall first, then cargo install <crate>. This is because it is quite annoying to compile packages every time you want to install something new whereas binstall distributes binaries instead, much faster.

Feels like we need a single command for that, I have two goals for my workflow (like maybe bininstall should be included in Cargo):

1) what’s the easiest way to give people access to a tool I just wrote, `cargo publish`

2) what’s the easiest way for someone to use it, as few steps as possible, right now it’s `install rust` && `cargo install`.

Once I get to three or more steps on 2 I tend to turn to just or make depending on the context.

You should combine step 1 and 2 in CI. Just tag a version in your git, push to remote and have CI auto build a release for you.

Use github actions or other setup for other backends.

(this is language agnostic and a reasonable thing to learn as a dev).

Or if you must live in the cargo command, go nuts with cargo-release.

https://github.com/crate-ci/cargo-release

https://github.com/cargo-bins/release-pr

I think more like tools for a language tend to be written in that language. Obviously the author needs to care enough about the target language and if they support plugins then it’s also desirable for the plugins to be written in the target lang.

If only we are so lucky. Still waiting for a faster typescript compiler.

Bun, Oxc and Biome are all great but a typescript rust compiler is something I'm really looking forward to. Right now my web application I've been building just crossed 25k lines of TS code and running `tsc` is becoming a pain point. What used to take 2-3 seconds now takes upwards to 10s, even with incremental compilation enabled in some cases.

STC by the SWC author should be coming along, I hear. It still will take a while though.

Semantic nit: STC is a type checker, SWC already compiles TypeScript well. TSC does both (unless flagged to do one or the other) so it depends on what needs replacing.

Why it matters: in GP’s case it sounds like compiling is the problem, so migrating to using SWC as the compiler but keeping TSC as the checker (noEmit flag) in a lint step may ease that pain a bit. Though it might be nicer to migrate both in parallel.

Can you elaborate? Typescript has existed for a long time and has been the standard over vanilla js for a long time. Bun, oxlint, and biome are all replacing existing tools with build steps. How could it be that their popularity signifies some new appreciation of compiled languages?

Typescript is not a compiled language. It is a "transpiled" language. Transpiled to another interpreted language Javascript which in turn again is not a compiled language.

> Typescript is not a compiled language.

Compilation or not isn't a feature of languages but of language implementations, but, yes, the primary TypeScript implementation is compiled.

> It is a "transpiled" language.

Transpilation is a subset of compilation.

It's not compiled to native machine code for the target system, but that doesn't make it not-compiled.

If going with that lax definition and concept wrangling, Python is also a compiled language. Python source code can be compiled and byte code can be cached and then Python runtime can load it.

Just like Typescript compiles the source to Javascript which is then loaded by the V8/Node etc.

And thus programming languages can be only of one type - Compiled.

Being compiled or not isn't a property of the language. It's a property of whether you compile it or not. Pure interpreters can exist. They're not very common for "practical" languages. Parse to AST, then call evaluate(ast). No target language necessary.

JS seems to be like a great language for discovering what's worth to be written. I think rewriting stuff in some compiled language is a sweet spot of "build first one to throw away".