That's not to say that babel isn't too slow or that this project isn't correct, just that it would scare me to try to work with it. Does babel have a regression suite? Does this pass it?
[1] current project is very slow w/ 250kloc (2.5mm kloc w/ dependencies). even seen it be slow on my last project which was only 40kloc.
Hot reloading _helps_, but it's definitely an issue that javascript tooling spends seconds on tasks other languages' tooling spends tens or hundreds of milliseconds on. (The issue isn't just limited to tsc either; just starting the build system can take a decent amount of time with webpack, while make or cmake starts in milliseconds.)
In terms of perf, I'm sure rust will be much faster than JS. And this project's main goal is to be a faster version than Babel. I would suggest the perf test would be different though because it's testing code I would consider not to be representative of what Babel actually runs on. Example with the transform test: https://github.com/swc-project/swc/blob/222bdc191fcab7714319... it's a very small file with minimal transforms even necessary at all. And the parser test is for all minified js files, none of which are written in ES6+ https://github.com/swc-project/swc/blob/master/ecmascript/pa.... Currently it's not really testing ES6+, just how at a baseline it's much faster to process a ES5 file, so it's possible that it might be even faster.
edit: I will note that Babel does a lot more than what this project is doing currently (plugins, other proposals, ts/flow, sourcemaps, etc) but this is more about what could be so if people are willing to more on this effort in the long run (with funding/support/people) it could be super useful! I'm curious about how that will work when our project has such a struggle with contributors and Babel itself is written in JS. (I work on Babel :D)
Unless we're talking about "understanding neural network internals", which is a big open problem, there just really aren't "black magic" problems inherent to particular subjects. It's almost always poor spec definition or poor code design, if there are any hand-waivey bits to be found.
If anything, compiler design (along with other subjects like text editor development) is a very deeply studied, very well understood, very well documented field. It should be easier than any other fields less central to computer science and software development, just on account of not being so thoroughly studied.
EDIT: fixed autocorrect problems
Compilers are also definitely not well documented. I think they're rather notoriously undocumented with much of our knowledge of the subject passed on orally and existing only in the knowledge of people working in the field.
For example a couple of years ago I went looking for details of a very common compiler technique, called safepoints, used in many major industrial compilers today, and found that there was essentially no written information on them at all. That's pretty extraordinary.
1. Safepoints are kind of off-topic, because they're part of the interplay between a complex optimizing compiler and the garbage collector/runtime. Babel and its ilk are source-source compilers targeting a language that doesn't have manual memory management. To my mind, that makes things much simpler.
2. How long ago were you searching for safepoint info? I've collected several articles and talks relating to safepoints. I don't know of anything that discusses safepoints in a way that you could implement them from scratch just based on the discussion, but they're tied to a complex part of the runtime, so any example/tutorial code would probably be parochial to a particular VM.
The best discussion of them at the moment is this one - and as you'll notice they're essentially having to do analysis of what is already out there because it just wasn't written down anywhere at the time. They don't have much of a 'related work' section or a bibliography because there wasn't much to refer to.
https://dl.acm.org/citation.cfm?id=2754169.2754187
And implementing them from scratch is what I wanted to know how to do. For a lot of compiler topics the only way to learn is to sit down with an existing expert and physically ask them. Compared to other CS fields that’s really bad.
There is some truth to this, but as someone with a PhD in compilers, let me say that this area is very accessible to people without PhDs. The first time I met @dannybee, I asked him where he went to grad school. Turns out he went to law school. Didn't stop him writing the GCC alias analysis framework though.
One of my focus areas during my degree was system programming, including compilers and language design.
Already in the late 90s, there were several good books about compilers.
There are tons of introductory texts, a few intermediate texts, a couple of very narrow advanced texts, and then it just runs out. A great deal of our knowledge is undocumented.
Other bugs such as the goto fail bug are eliminated by dead code spotting and consistent formatting.
You can write bugs in Rust but they tend to be business logic bugs, or incorrect explicit decisions.
I just know that even if the compiler of the language I am writing is very smart and can catch a lot of my silly mistakes, it would behoove me to think that I could write "bug free" code as a result. I would still write my code defensively, even in rust.
I would argue it is much faster to get to a final, 'correct' working version because you spend less time debugging. Time is also drastically cut down the more familiar you are with the language, but still, I'd love to see some data on dev time between languages with robust type systems vs dynamic.
Mostly I would say fewer bugs; the bugs that are avoided vary in severity. Many, probably most, are the severe but obvious bugs where you would have hit the first time you tried running the code in another language, but which are instead now caught by the compiler—that’s why “time to first run” is not a reasonable metric for comparing writing code in such languages, but “time to first meaningfully successful run”! But it’s also common for Rust to catch and prevent far more insidious bugs; especially, in my experience, in two areas: firstly, with respect to ownership—things like passing data structures around and improperly mutating them where you should have cloned it instead, which is structurally impossible in Rust (disregarding things like Rc<RwLock<T>>, which make it possible, but make the intent very much clearer); and secondly, where enums (tagged unions) can be used, due to the greater and more precise expressivity.
I have much greater confidence that my first pass at a piece of code will work correctly in Rust, once it compiles, than I do in JavaScript—and I’ve been working in JavaScript a lot more than Rust in the last couple of years, yet it’s still true.
Expressive type system, strong and static - JS is weak and dynamic. This is not limited to Rust - but if you're aiming for correct code pretty much anything after C/C++ and maybe PHP is better than JS and it's million and one way to write unexpected bugs and 10.000 ways to do the same basic thing (with an NPM package no less) of which each dev/library chooses it's own path for cool factor.
Who would even argue that JS is better for writing correct code over a language that's obsessive about security and correctness. Last time I checked Rust wouldn't even upcast ints FFS, meanwhile in JS you can't even be sure what "this" refers to in any given context and 0 == '0' == [0].
If you change Rust to ML, the phrase would be way more natural.
But there are classes of bugs that the language eliminates. Thread unsafe dataraces (not important in JS), unhandled exceptions, with no GC it helps reduce memory usage and make it more consistent, the type system allows you to build complex state machines easily and correctly, the type system itself can allow you to express states that should never occur as compilation failures, the compiler protects against concurrent updates in iterators and other situations.
The list goes on, but these are the things that make it such a powerful language and allow me to focus on logic and not runtime bugs. Oh, and it’s really fast which is a nice bonus, generally as fast as C.
[1] Naturally excluding the 18 hours of productivity that will have been killed getting said unnecessary javascript->javascript build system set up and running in the first place.