This type of test does work as expected. The "sync" means that it does not feature a full event loop (yet) so cannot easily support async I/O or some more "advanced" use cases.
Yep! Also as it is technically more of an engine/runtime (sometimes) than "just" a compiler, folks in the JS space are more familiar with engine as a term :)
Exactly. The versioning system is definitely unique and controversial, but I think it fits for a fast moving project like this, so I don't have to really consider versioning which could slow development. When it becomes more stable, I'll likely move to a more traditional semver scheme from 1.0.
There's the commit hash. Basically the "version number" is the commit hash, the human-generated (version) numbers added to it are merely progress indicators, which might be randomly useful. But for a project that has 1 branch, 0 tags and nearly 2000 commits, that's not really important.
yes, the entire exercise isn’t important. It just breaks the monotonicity that version numbers typically have. At that point, just call your version <progress>.sha
Good comparison and thanks! A few minor clarifications:
- Porffor isn't fully self-hosted yet but should be possible hopefully! It does partially compile itself for builtins (eg Array.prototype.filter, Math.sin, atob, ...) though.
- As of late, Porffor does now support basic async/promise/await! Not very well yet though.
Agreed, I have it behind a flag because of this, in the (far) future I could enable by default if I write a type checker built-in or something. Thank you!
Unfortunately yes, optimizer at high levels is very unstable/aggressive at the moment. Currently working on refactoring things for perf generally instead of just an optimizer, but definitely will fix in the future!
JS is a language I can cobble together something hacky in and I don't have to care about types or anything yet, just making something work. It's fun! :)
