[forbiddenvoid]

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.

[black_puppydog]

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...

[azakai]

> 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.

[kaoD]

>several are written in JS and TS, there is Rhino in Java, Otto in Go, Esprima .NET in C#

All of those have a mandatory GC.

[azakai]

Indeed, and that may matter in some cases.

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.

[postalrat]

I figure people equate written in rust to mean free of defects and so finalized.