I'm skeptical too (I'm the author of Rome). I know it can be at least performance neutral compared to existing JavaScript tools which is the baseline for most people. However I do think that since Rome is an enclosed system, without external dependencies and pretty good TS typing, that there's some future flexibility using another wasm language that other JS tools don't have.

Awesome to hear you’re open to this in the future. I hope WASM gets some real traction in those sort of use cases.

I was thinking tools would start replacing their typescript code with assemblyscript and build wasm modules for hot paths. Do you have any similar thoughts?

For a compiler, it's probably much more valuable to have parallelism than cherry-pick slow code. You'd have to pick a pretty big hot path for the data conversion to be worth it. JS is pretty darn fast sequentially thanks to the ridiculous effort spent on its VM implementations, and there is next to zero number-crunching in a compiler, which is the main reason people have been cherry-picking with WASM on the web so far. We're talking pretty minimal speedups, compared to giving an embarassingly parallel problem the threading it deserves.

Having written codebases that take a couple of minutes to compile, it seems like a bit of a waste to write a whole new full-stack-no-dependencies compiler in a language that can't be parallelised.

You can usually get behind a self-hosting compiler for language evolution purposes, but for JS there is zero value in having yet another project to try it out on. For a transpiler to work on itself, maybe, but Rome is a CLI tool, not a web bundle, so it will never need to exercise the most demanding features of a transpiler/bundler. JSX, minification, code splitting, async loading, legacy browser support, etc. You can innovate on those things in any other language just as easily.

At the end of the day, the only advantage is that people who want to contribute will already know the language. Is that important enough to deal with another ten years of slow JS transpilation, forcing people to run huge, un-optimised code blobs in development (real life, very annoying problem), and 800MB node processes? I don't see that changing in JS-world for a long time.

(This is snarky, but you might actually be better off without importing the unfortunate churn habits of the JS community.)

This is very true. C++ developers have been using distributed builds (where when you hit "Build" in VS or run "make", it splits your build up and sends different source modules to different build workers on your local network - typically other developer machines or CI servers, then links the results together at the end), for decades now; I remember testing one back in 2005 or so and it worked pretty well.

Node has three different ways of running parallel work: workers, threads, and multi-process.

Especially for threads, how well does this mesh with libraries? I'd assume that most of these are either meant to run in a single-threaded manner or async.

Does not apply since this project is being written from scratch with zero library dependencies?

Is Rome currently suitable for writing a transpiler?

Using those languages comes at a tradeoff: the community isn't as a whole likely to know them or want to use them.

For example, I'm a pretty prolific TypeScript developer these days. And I do know Rust and C++ and Java and a bunch of other languages, but I'm unlikely to contribute to JavaScript-ecosystem stuff written in them because the cognitive overhead is too high--the context switching kills me. And while I do know Golang, having to write it makes me want to chuck my computer in a lake and I'll within epsilon of never contribute to a tool written in it.

You can swap in whatever languages in whatever slots in the above that you want, and you'll probably cover some chunk of the community. The intersection of all of them is JavaScript (and, for this project, TypeScript). I think that's wise.

If you need to optimize certain parts of your runtime or your toolchain once it's correct and does what it's supposed to and you can call the solution set understood, that's one thing. But until it is, defaulting to something that isn't self-hosting is bad for your prospects of community building.

> And while I do know Golang, having to write it makes me want to chuck my computer in a lake and I'll within epsilon of never contribute to a tool written in it.

Why this level of hatred for Go?

The best way I can describe the way that Golang presents itself to me--and this is probably that from-Google ethos, in that they're writing a language for the legion of post-college Googlers--is "you must write stupid code because we are afraid of you being too clever for yourself".

And I would never say that that is an indefensible viewpoint. If I was selecting tools for people who are not me and people who I don't think I can effectively train and coach and lead into being better at what they're ostensibly here to do, I might even advocate for it. But I am not afraid of being too clever for myself. In production capacities, you should be prevented from being too clever by this through the taste that you should have developed as a practitioner of the craft of software development (and your code reviewers should be backing you up on if you don't have that yet). And in exploratory capacities, being too clever should be encouraged--because that's how you become good at your job in the first place.

I believe that, instead of throwing up our hands and just stapling a high-cut filter on programming as a craft, one can and should build better systems that actually use the computer to do the tedious tasks involved in making sure that you've actually expressed solutions to problems in a clear and reliable way. Tools that do exactly what I described do exist; along very different axes, both TypeScript (structurally typed and with really flexible and easily expressed generics) and Rust (lower-level borrow-checker B&D but with a raft of niceties to soften the blow; "good C++ with a great IDE" ends up here too, though there's a lot of bad C++ too) scratch exactly that itch for me.

Those tools (and others, in greater or lesser measure) reward me for thinking deeply about a problem. My reward is being saddled with less and clearer code to deal with in the future. And that's amazing! On the other hand, I have felt, each and every time I have been stuck using it, that by leaving any questions of difficulty to the programmer to handle a bunch of e-janitor stuff--bad error handling, really embracing its actually-just-Java-1.4-self by not supporting generics, etc.--Golang just wastes my time. I end up with more code that's harder to read and is better able to conceal errors both of omission and commission. Golang punts the solving of the actually hard problems of software craftsmanship to the programmer and I resent that. It should be helping me, not fucking off with the job half-done.

Don't get me wrong: I don't begrudge others its use, except when I'm stuck using it because of previous choices made, but it's the only programming language in common use that makes me feel bad to use it. (Which is to say that yeah, there are worse, but I don't exactly have to deal with them.) To me, the repelling effect is strong enough that it really is one of two languages (hi, PHP) on my under-no-circumstances list.

This seems like a complex way of saying that Go is too simple for your taste.

I don't mind simple languages. I'll write code in Kotlin, which is a pretty mild hat on top of Java.

Golang is not a "simple language", though. C# is a simple language, and while it sometimes frustrates me its decisions make sense. Golang is a simplistic language. There is value in being simple; there is little value in being simplistic.

> Using those languages comes at a tradeoff: the community isn't as a whole likely to know them or want to use them.

You don't have to use Rust or Go to use a tool written in it.

If you read my post, one needs to use them to contribute to them. Past a certain point that matters less; early on, it matters a lot.

This is true, but for a compiler project, I think compiler expertise is a much bigger gating factor than language expertise. If you want to maximize effective contribution, you're probably better off picking a language that lots of compiler hackers know.

There's more to this project than compilers.

As an example, I've written custom TSLint plugins before. I'm not writing those in Rust.

There's a lot of wisdom in sticking to your lingua franca until you prove you can't.

On the topic of other languages taking over these tools, fundamentally it comes down to this: At the end of the day, these javascript tools (beyond just npm/yarn, which I think could be written in any language much more easily), like webpack, babel, or rollup etc., create very hard to replicate advanced ASTs. Even microsoft hasn't bothered to port typescript compilation to say, C# or F#, and I think largely because its a lot more complex to create the foundations for those languages to understand javascript on that kind of level.

You could argue (and I can see the validity of it, see the Closure Compiler for a counter example), that it can just as well be done, but it seems like its far easier to implement in JavaScript these kind of tools.

It's much better to be self-enclosed than just to be faster at constant times.

Just like most Emacs functionalities are written in Emacs-lisp, and most Elixir functionalities are written in Elixir. It's more consistent for open source projects, and people would be more familiar and motivated when building and consuming at the same time.

Would compiling it to native using e.g. GraalVM do much for performance?