To clarify: I'm also not advocating for merging the codebases together, that would be mostly counterproductive (especially since Bun is in Zig, and Oxc and Biome in Rust).

When I think why Rust was successful at establishing community-accepted standard tooling (clippy, rust-lsp), 2 things come to mind:

- Project developers were always promoting each other's tools, pointing them out in docs or blog posts

- Good tools were being pulled into rust-lang GH org (for visibility) and rustup CLI distribution (for ease of system-wide installation)

Both of these things are not technical challenges, they are rather more "political" (require agreements between parties). In JS ecosystem, what would it take for Oxc to say on their website "we are not writing a formatter, please install Biome" and for Biome homepage to say "we are not writing a linter, please install Oxlint"?

Biome is the continuation of Rome Tools. It exists since several years and always featured a linter and a formatter.

If I remember correctly, OXC was born out of its author's desire to learn Rust and his feeling that Rome Tools/Biome had made complex technological decisions (mainly the use of CST instead of an AST). Rome Tools/Biome chose a CST to bring first-class IDE support: you can format and lint malformed code as you are writing it.

I hope more collaboration between Biome and OXC in the future. However, the inherent difference comes from technological choices.

Except Biome can also function as a linter

Happens loads of times. There is some in-built human condition that folk basically see a thing that they could improve but then decide to go off and build their own moon-base rather than work on someone elses project.

In my experience, project maintainers are frequently uninterested in changes to their project, especially if those changes are a significant departure from their current vision or if it involves pivoting away from tools that they like. You're often expected to make years of contributions to the project to earn the rapport to bring significant suggestions before the maintainers. It's often just easier to 'build your own moonbase' instead of politicking.

Just a couple days ago, the curl maintainer published a blog post about why he wouldn't rewrite curl in Rust and a big part of the reason was that he and the other maintainers weren't good at it and weren't the right people to lead a project that used it--he said that he encouraged other people to start their own project in Rust. But then when people follow that advise, they're chided for not contributing to the more established project! To be clear, I'm not a "just rewrite it in Rust" guy, but I think people underestimate the difficulty and frustration involved in petitioning an established project to make the reforms necessary for significant improvements.

Well, when they pretty much succeed at building their moon base, I say good on them.

Except that this is not as good as the original by their own admittance. If they had collaborated they could likely get more done in the same amount of time. (not twice as much, but more)

Maybe this is a better design than the other projects. Maybe people cannot get along and so they are forced to fork. There are many other good reasons to not contribute to an existing project. However we should always look at skepticism on such claims: it is easy to start you own project and you are in control so the amount of work you get done is higher. However working together, while it makes everyone slower normally results in many more features and higher quality code over the long term.

So please when you have an itch technology can solve look to see if you can contribute to someone else's project first. It won't be as fun, but the world and you will be better for it.

[3] https://github.com/bablr-lang

I'm its author and focus solely on the collaboration picture. I don't generate much press because I only build internal APIs for tooling and language authors, where the projects you've shared all opted to prioritize fulfilling specific real use cases over generalizing their core technology.

Cruel as it is, I think all of them have planted the seeds of their own failure by failing to protect their organization's mission and day-to-day work from being jailed by a set of specific opinions about code style, which cannot possibly be "right" or "wrong" but must instead by argued about forever.

I see the core challenge as shifting all editors and tools to share a common DOM representation and be interoperable in a per-node way, where the current solution is to use siloed and reimplemented tools which interoperate mostly in a per-file way, with each tool parsing the text, doing some work, then emitting text for some other tool to parse...

For example:

"The Oxc AST differs slightly from the estree AST by removing ambiguous nodes and introducing distinct types. For example, instead of using a generic estree Identifier, the Oxc AST provides specific types such as BindingIdentifier, IdentifierReference, and IdentifierName."

Already this is getting into matters of style! It is one style, yes, but Javascript's shorthand syntax `({ foo })` already breaks the mental model: the identifier `foo` is technically doing the work of both an IdentifierName and an IdentifierReference. OXC chooses IdentifierReference so any system built on top of it would need to contain additional logic in order to be able to identify all sites in code that are used as identifier names.

There's also Deno:

https://deno.com/

More like JS folks are discovering compiled languages.

Now instead of a new JS framework daily, it's going to be new reimplementation of an existing tool daily. For a while.

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".