Personally I hate tooling for one language written in another. I hate python used to generate C++. I hate go used to generate C++ or JavaScript. Every added language adds more knowledge needed to contribute.

For every 1000 JS developers and every 1000 Zig developers there are 25 that know both. Only those developers can modify the system.

Further, you double the dependencies. JS pulls in library to do X that requires 50 dependencies, Zig pulls in a library to do X that requires 50 dependencies.

You also have 2 toolchains to maintain.

And you have 2 dev environments to maintain. Get all your editors/IDEs to understand both language. Get double your checkers, double your testing, etc etc.

You effectively increase the tech debt exponentially.

I get your point, but once in a while, you get a gem like uv for python.

The fact uv is not in python means it's immune to the many bootstrapping problems the language suffers, which in itself is a huge win.

Granted, it works only because it's well engineered. The python integration is fluid, it respects standards, you never actually feels you are dealing with a separate tech.

This is rare.

Usually the experience is more something like asdf which gets 70% there then left you hanging.

However, when that works, it brings many benefits. An unconspiscious one for uv is that we now have a packaging tool compatible with pip that you can call from any other language with no need for a python runtime, and no risk of breaking if other runtimes exist and move.

JS culture is to pull a dependency for anything, in Zig land I assume it is more conservative like C or C++: pull one or two for your specific bigger picture or often enough none at all, because people pride themselves with projects having the minimal amount of dependencies. Otherwise there is truth to what you are saying.

The thing about the tooling is often that most users do not have the ability to contribute even if it is in a language they are proficient in.

Oh and until there is a good enough AOT compiler for JS there will always be a lot of tooling that is not in JS.

The worse is when your CLI tool depends on some random runtime[1] being available on your system, most notably cloud provider CLIs relying on python being available in the system (GCP CLI still does this, AWS CLI used to).

When step 1 of your tool is "install ruby/python/nodejs/JVM"[2] it means you do not care about your users. Either bundle[3] the runtime with your tool or make it in a statically linked binary.

Like why am I, as a go/nodejs developer, need to figure out how to install python2 and pip and make them work just to have the privilege of paying you money to host my code.

[1]: Some runtimes come pre-installed in some OS (like Ruby in Macos) so tools often rely on it, that is NOT okay either. OS gets updated, versions change and tools break.

[2]: The only runtime under this sun that is acceptable to rely on is Bash and even that it is not great because Windows.

[3]: I think the cloud providers specifically don't bundle like that because the CLI gets too big to download which makes it hard to use in automated process (like CI pipelines). But this is no excuse, just make your tool in a different language.

Unfortunately, "JS tooling in JS" is a dead end.

Countless people before me have tried, and I myself have written and maintained a (proprietary) JS toolchain that has caused a some trouble with users over the years.

In the end, using a systems language is what I've settled on.

> Further, you double the dependencies

I'm acutely aware of this problem. Which is why if you look at Jam now, it has zero dependencies. Not even libc (which is mostly thanks to Zig).

The only "dependency" is a Unicode property detection library I wrote for Jam itself. And it is currently the fastest implementation for Unicode identifiers to exist. This simply isn't possible in JavaScript.

Same story with the Parser, etc. Parsers for JS already exist, but it's already known how far one can go, stitching together existing tools that aren't meant to work with each other.

Some dependencies can't be avoided in the long run, But I try to be very cautious, and vet every dependency thoroughly before considering it an option.

Ultimately, the dependence on two languages is a tradeoff that I've accepted, and the problem you mentioned with dev environments is one I'm going have to live with.

I think it ultimately is a sign of the need for better languages. Of course, there are always engineering compromises. But I think a better world is possible, in which we don't have massive software projects written in JavaScript or Python.

> You effectively increase the tech debt exponentially.

You're generally right, but the JS eco system has true culture problems, a barrier like Zig brings lots of virtue to such a project, there is space for a good tradeoff on that front.

While i can agree, Js is such an inefficient beast that using more efficient languages is IMHO mandatory.

No JS written tool will ever be faster than, for example, esbuild (Go).

[dead]