Hacker News Reader

Hacker News

Comment by otabdeveloper4 | Hacker News Reader

Parent Full thread

otabdeveloper4

V8 is written in C++, not Rust.

View on HN

They're talking about deno, which _is_ written in Rust. https://github.com/denoland/deno

Deno is a simple, modern and secure runtime for JavaScript and TypeScript that uses V8 and is built in Rust.

So it's probably a rust wrapper around a C++ project (unless they reimplement V8 in rust... )

Yeah the communication with V8 and all the API are in rust, V8 is still in c++

Yup, it uses rusty_v8 which are Rust bindings for V8's C++ API - https://github.com/denoland/rusty_v8

Sure, although the rust v8 bindings don’t appear to support FreeBSD as i just found out when i tried to install deno on FreeBSD 13:

  > cargo install --locked deno

     Compiling rusty_v8 v0.22.2
  error[E0308]: mismatched types
     --> /home/craig/.cargo/registry/src/github.com-1ecc6299db9ec823/rusty_v8-0.22.2/build.rs:157:18
      |
  157 | fn platform() -> &'static str {
      |    --------      ^^^^^^^^^^^^ expected `&str`, found `()`
      |    |
      |    implicitly returns `()` as its body has no tail or `return` expression
  
  error: aborting due to previous error
  
  For more information about this error, try `rustc --explain E0308`.
  error: could not compile `rusty_v8`
  
  To learn more, run the command again with --verbose.
  warning: build failed, waiting for other jobs to finish...
  error: failed to compile `deno v1.10.1`, intermediate artifacts can be found at `/tmp/cargo-installwrTFWi`
  
  Caused by:
    build failed

That looks like a pretty simple problem. Deno probably doesn’t work on FreeBSD simply because nobody has done the work of making it compatible yet. Rust, V8 and nodejs all run great on FreeBSD.

If you care about FreeBSD support, I bet the community would be delighted to receive some pull requests patching the problem.

I gave it a whirl:

  > git clone https://github.com/denoland/deno.git denoland/deno
  > git clone https://github.com/denoland/rusty_v8.git denoland/rusty_v8
  > cd denoland/deno
  > vi Cargo.toml

  ...
  [patch.crates-io]
  rusty_v8 = { path = "../rusty_v8" }
  ...

  > cargo build --release
  ... as expected same failure - good ...

Make rusty_v8 build.rs aware of freebsd

  > vi ../rusty_v8/build.rs

  ...
  #[cfg(target_os = "freebsd")]
  {
    "freebsd"
  }
  ...

Have a quick squizz to see where this is used:

  > rg "platform\(\)" ../rusty_v8

  build.rs
  157:fn platform() -> &'static str {
  180:    .join(platform());

Attempt to fix... and bang! It's using the platform() result to call a python script that pulls binaries from here:

https://github.com/denoland/ninja_gn_binaries/

And there's no FreeBSD build there. To much yak shaving for idle curiosity on my part.

Hm. Looks like gn refers to: https://gn.googlesource.com/gn

Guessing it is inspired by v8/chrome build system? Maybe have a look at nodejs for freeBSD for inspiration? Or just provide ninja/gn some other way.

Little sad to see a build process import binaries from the net either way...

I'm pretty confident we'll see a JS engine written in Rust at some point in the future, it'll just take a very long time to get parity with V8 and will likely introduce its own slew of issues.

Parts of the Firefox JS engine (SpiderMonkey) are written in Rust (although nothing really significant I believe).

I rather imagine we'll see a wasm vm/runtime in rust, and a typescript/js to wasm compiler written in typescript...

> I rather imagine we'll see a wasm vm/runtime in rust

Like Wasmtime? https://github.com/bytecodealliance/wasmtime

Yes, but we would also need an event loop I guess. As I understand it nodejs is essentially a (c++) js runtime inside a c++ event loop. But I think we already have a rust event loop (or two?)

I don't see any benefits (for me, the user) if its written in Rust. Yes, Rust has nice features for more security+stability for the developer, but just because a JS Engine would be written in Rust wouldn't mean its automatically better than V8. It's not the programming language that gives the edge in this case, it is the amount of time, sweat and grease that went into V8. And other engines would have a long way to come.

I don't know about a JS engine written in Rust. Well, I'm sure it will be attempted (no doubt it's being done right now), but I don't see a path to success.

Like you say, it would take a long time for a Rust JS engine to reach parity with V8. But long-running projects need real use-cases to succeed... they drive support and provide direction/feedback. How much will a half-baked Rust JS engine be adopted when a mature, stable V8 or SM is available? Will the projects that do so be successful themselves? A pure Rust JS engine might be destined to peter-out well before becoming viable.

A better approach (though less satisfying) might be to convert an existing engine incrementally. But even there, there probably needs to be continuous, compelling benefits along the way to justify the increased complexity and large amount of additional work. Imagine release after release where the main item in the release notes is "rewrote another subsystem in Rust"... followed by a bunch of bugs in the previously stable subsystem. I know SM has some Rust bits, but I'm not sure how far that is really going to go.

Reply on news.ycombinator.com