I think that's all it takes to make the front page of HN, right?
-----
I'm curious to understand the use cases they're trying to solve for. I recognize this is experimental, but it's hard to visualize what this is supposed to be for.
1. Yeah, I guess... But I'm not complaining really. There are less interesting things on the front page. :P
2. The way I see it, re-implementing JS from scratch in a language that is designed to help avoid very common, often compromising programming mistakes around concurrency and memory management makes perfect sense. Eventually this might make it into browsers and web servers; environments that are executing untrusted code in the former case and are publicly exposed in the latter case. Having them be fast-yet-secure is important, isn't it?
Of course, it's early days, but you gotta start somewhere after all...
> Eventually this might make it into browsers and web servers
I'm skeptical at least for browsers. Browser JS VMs have integration between their parsers and their interpreter and their JITs, at minimum. You wouldn't really be able to drop in a standalone project like this.
But I agree it's not a bad thing to have more JS parsers out there!
Many are already written in a safe language, though, so this isn't new, for example several are written in JS and TS, there is Rhino in Java, Otto in Go, Esprima .NET in C#, etc. etc. But it's natural to want one in Rust as well.
I guess technically, the title should be "Boa release v0.10." Better?
Rather than curse the darkness, I'll quote the first sentence from the page: "Boa is an experimental Javascript lexer, parser and compiler written in Rust." What's so great about this particular release? "v0.10 has been the biggest release to date, with 138 issues closed!" Also, there's a test suite: 38,706 tests, of which 6,895 passed and 5,748 were ignored, for a conformance rate of 17.81%.
We've changed the title from "Boa 0.10" to the page's description of the project, since the project doesn't appear to have been discussed on HN before.
> Boa is an experimental Javascript lexer, parser and compiler written in Rust. It has support for some of the language, can be embedded in Rust projects fairly easily and also used from the command line.
It's very interesting to see how their benchmarks [1] progress over time. I would love to see a comparison with the alternatives. Perhaps that could show some of the benefits of writing this in Rust.
For another JavaScript parser, but written in TypeScript, check out Seafox [2]. It's also self-hosted [3], which I always enjoy seeing.
Here is another one. Made by the profilic Fabrice Bellard.
"QuickJS is a small and embeddable Javascript engine. It supports the ES2020 specification including modules, asynchronous generators, proxies and BigInt."
Self hosting is interesting, but often times I wish that fundamental tools like compilers were not self hosted when the language in question is a high level one with runtime performance limitations. I'd rather have them be as fast as possible.
It also complicates the bootstrapping process, sometimes significantly.
I understand that it's important to eat your own dog food, in order to experience the pain points yourself. But sometimes people think of self hosting as a symbol of something (pride maybe), and that's the wrong way to approach a programming problem in my opinion.
In practice, I suspect it's less about pride, and more about practical issues. Bootstrapping means you only need to deal with one language ecosystem, instead of two. And, presumably, the author of the compiler would prefer to write code in their language over some other one.
I think it depends. Writing a compiler in a low-level language won't necessarily result in better performance. It can, if you put in enough performance work, of course.
But if you want to keep the code simpler, a higher-level language could potentially give better performance, simply because it's easier to share data structures, avoid copying, etc. Additionally, things like immutable persistent maps are a great fit for environments in a compiler, and they are much easier to implement in a language with garbage collection.
That said, obviously some high-level languages are still going to be too slow without also putting in a lot of work. I think there's a sweet spot with languages that compile to reasonably fast machine code but are also garbage collected. Languages like OCaml, Go, Haskell. Though I personally wouldn't use Go, but that's for reasons other than performance.
Does anyone know what they mean by "compiler"? The README file on their repository didn't expound on this. (I have a very fast parser and lexer for JavaScript written in C++ that is very compliant in Cycript--the main issues I sometimes see are in my hacky "try to do everything in a single pass"semantic optimizer pass I am doing to generate code, but that is of course optional--though I haven't pushed updates to its repository in a few years despite my doing a lot of work on it... I kind of decided at some point I hated users. But I don't have a "compiler" unless the meaning is "compile from JavaScript to JavaScript", in which case it would be fun to benchmark it against boa and I might start doing that. It is just that it sounds a bit like boa is also executing the JavaScript?)
29 comments
[ 4.4 ms ] story [ 67.6 ms ] thread-----
I'm curious to understand the use cases they're trying to solve for. I recognize this is experimental, but it's hard to visualize what this is supposed to be for.
2. The way I see it, re-implementing JS from scratch in a language that is designed to help avoid very common, often compromising programming mistakes around concurrency and memory management makes perfect sense. Eventually this might make it into browsers and web servers; environments that are executing untrusted code in the former case and are publicly exposed in the latter case. Having them be fast-yet-secure is important, isn't it?
Of course, it's early days, but you gotta start somewhere after all...
I'm skeptical at least for browsers. Browser JS VMs have integration between their parsers and their interpreter and their JITs, at minimum. You wouldn't really be able to drop in a standalone project like this.
But I agree it's not a bad thing to have more JS parsers out there!
Many are already written in a safe language, though, so this isn't new, for example several are written in JS and TS, there is Rhino in Java, Otto in Go, Esprima .NET in C#, etc. etc. But it's natural to want one in Rust as well.
All of those have a mandatory GC.
As I said, it's natural to want a JS parser in Rust. Each language has its own benefits, and Rust's are quite unique.
But Boa the web server was discontinued in 2005 so i guess it's fair to reuse the name.
http://boa-constructor.sourceforge.net/
Rather than curse the darkness, I'll quote the first sentence from the page: "Boa is an experimental Javascript lexer, parser and compiler written in Rust." What's so great about this particular release? "v0.10 has been the biggest release to date, with 138 issues closed!" Also, there's a test suite: 38,706 tests, of which 6,895 passed and 5,748 were ignored, for a conformance rate of 17.81%.
@dang could you change it to "Boa release v0.10" ?
For another JavaScript parser, but written in TypeScript, check out Seafox [2]. It's also self-hosted [3], which I always enjoy seeing.
[1] https://boa-dev.github.io/boa/dev/bench/
[2] https://github.com/KFlash/seafox
[3] https://en.wikipedia.org/wiki/Self-hosting_(compilers)
"QuickJS is a small and embeddable Javascript engine. It supports the ES2020 specification including modules, asynchronous generators, proxies and BigInt."
https://bellard.org/quickjs/
I understand that it's important to eat your own dog food, in order to experience the pain points yourself. But sometimes people think of self hosting as a symbol of something (pride maybe), and that's the wrong way to approach a programming problem in my opinion.
But if you want to keep the code simpler, a higher-level language could potentially give better performance, simply because it's easier to share data structures, avoid copying, etc. Additionally, things like immutable persistent maps are a great fit for environments in a compiler, and they are much easier to implement in a language with garbage collection.
That said, obviously some high-level languages are still going to be too slow without also putting in a lot of work. I think there's a sweet spot with languages that compile to reasonably fast machine code but are also garbage collected. Languages like OCaml, Go, Haskell. Though I personally wouldn't use Go, but that's for reasons other than performance.
https://boa-dev.github.io/boa/doc/boa/exec/index.html