Ha, I just tried the same trick with Rust:

  //$HOME/.cargo/bin/rustc "$0" && ${0%.rs} "$@" ; exit
  
  use std::env;
  
  fn main() {
      println!("hello, world!");
      for arg in env::args() {
          println!("arg: {arg}");
      }
  }

Total hack, and it litters ./ with the generated executable. But cute.

Fortunately this hack isn't necessary for rust, shebangs are syntactically valid and single-file scripts can be executed with cargo nightly: https://doc.rust-lang.org/nightly/cargo/reference/unstable.h...

I wish this was faster, in my tests it’s about 200ms startup consistently on my M4 MacBook. Otherwise very cool

Interesting! That seems unexpected, for a minimal hello-world program I'm averaging 14ms after the first execution:

```

$ echo 'fn main() { println!("hello, world!") }' > file.rs; hyperfine --warmup 1 'cargo +nightly -Zscript file.rs'

Benchmark 1: cargo +nightly -Zscript file.rs

  Time (mean ± σ):      14.0 ms ±   1.0 ms    [User: 7.7 ms, System: 9.7 ms]

  Range (min … max):    12.2 ms …  17.5 ms    203 runs

```

Ah I think it’s because I was testing with an external library in the top level TOML metadata

Cool!

Neon maintainer here, happy to answer any questions folks might have!

It's a pretty exciting time for Neon. We're nearly feature-complete for a 1.0 release, which will come with a bunch of benefits and should help us build momentum for future improvements:

  * No more legacy backend -- just one simple and clean way to use Neon, fully audited for safety.
  * Strong ABI and API stability guarantees.
  * Convenient APIs for general-purpose multithreading and creating custom async Node events.
  * Ergonomic and modern use of JS promises, which interact beautifully with async Rust code.

Some of the things I'm looking forward to exploring post-1.0 is even more ergonomics and performance improvements.

Is there a way to generate automatic bindings for rust/js code from the AST of the language and a list of definitions to specify? I'm imaging how powerful a Bazel ruleset for this could be. Something like

  js_rust_library(... defs = ["someFunction"] ...)

That's a cool idea! The closest thing today is probably neon-serde, a cool community library that lets you generate bindings from lightweight Rust annotations:

    https://docs.rs/neon-serde2/0.8.0/neon_serde2/

Another thing I'd love to explore is using TypeScript declarations (e.g. from a .d.ts file) to auto-generate bindings.

If you're interested in playing with any of these ideas feel free to hop onto our community Slack and chat!

Thank you for building it! I haven't kicked the tires yet, but as a node developer, this feels like the future: we can move fast with node when it makes sense, and get rust level performance when we need to. Best of both worlds!

Did you consider compiling to WASM/WASI, and if yes, what were the reason to go with native DLLs?

I assume this question was directed at me (author of the post).

I've considered it. But honestly, I don't know a lot about WASM (I should explore it more), so I haven't compiled it to WASM. Maybe some members of the community can provide more insights.

It is definitely something I'll try to check at some point later.

In case it was directed at me, I’ll say yes, it’s on my mind, but my first goal was to have the full power of the entire OS facilities, the full Cargo ecosystem, and full native performance with the safety of Rust. That said, I think wasm has still only just begun to take off and it’s on my radar.

I just wanted to say: Thank you! Neon is great!

For context, one of the co-authors is Niko Matsakis, a recent hire at AWS and one of the longest-running leaders in the Rust community (among many things, inventor of the borrow checker and Rust's ownership system). So even if Amazon's involvement in the Rust community is only recently ramping up, I think this post suggests that they intend to invest in the Rust project itself.

I'm happy to see so many companies stepping up and investing not only in using Rust but in investing in its ongoing sustainability. And the fact that many companies are doing it, not just one, makes me optimistic that decision-making can keep happening in the community, not behind closed doors.

The Bayeux Tapestry Museum is hands down the best museum experience I’ve ever had. It’s really something else.

The apocalypse tapestry in Angers [0] is bigger, not quite as old, but in my mind almost has a more interesting history to it. Well worth a visit.

[0] https://en.wikipedia.org/wiki/Apocalypse_Tapestry

I remember sitting outside a Mountain View Starbuck's with Lars Hansen, then at Opera, and Brendan Eich, then at Mozilla, and listening to Lars explain that he'd lost faith that ES4 was realistically implementable. I think that was the day I knew it was dead.

I spent years working on ES4 and I'm not sorry it failed (namespaces in particular were just a disastrously bad idea). The whole affair was a formative experience for me.

And yet a good part of ES4 been realistically implemented in ActionScript 3 and used by many developers for over a decade.

And those namespaces in AS3 (much simpler than in ES4) I think are quite a good idea, they allow to control what is visible or not and/or to switch which implementation you use.

For example when some AS3 builtins do not support some methods defined later in ES5.1 then ES6 etc.

    ES5 function trim():String
    ES6 function repeat(count:Number):String

So yeah you not gonna use namespaces everyday for everything, but they do have allow to solve specific problems while "programming in the large".

No matter how many years, decades pass, the connections the Internet makes possible never cease to astonish me. Thanks for your work on ES4.

How did namespaces in ES4 differ from namespaces in Java?

In Java you would use packages to group together class definitions

same as with C++, C# where you would use namespaces to do that

aka define the scope of classes

in AS3, the packages are used the same, group collection of definitions, not only classes and interfaces but also variables, constants.

The namespaces in AS3 are used to define the visibility of definitions at the class level, a bit like being able to define your own "public" attribute.

In ActionScript 3, by default the AS3 namespace is open, for example with a builtin like Array instead of using the push() method defined in the prototype, it uses the push() method defined in the AS3 namespace.

See https://github.com/adobe/avmplus/blob/master/core/Array.as#L...

But you also have mode to compile with -ES to not open that AS3 namespace by default.

In ES4, namespaces could do more advanced stuff like namespace shadowing (only a proposal at the time), see https://web.archive.org/web/20070629024201/http://developer....

For AS3, see 1.9 Namespaces / 12 Namespaces / etc. https://github.com/as3lang/ActionScript3/wiki/Specification

My recollection was that there were modules, packages, and namespaces. Which was kind of a problem.

I’m excited about Actions generally, so I’m glad to hear your team is aware of the challenges of building a reliable ecosystem of third party dependencies by reference to repos.

Still, recommending git SHAs has real ergonomic and maintainability issues, and while it’s more defensive it doesn’t prevent left-pad style broken builds due to disappearing content.

And at the same time, GitHub is investing heavily in package management infrastructure. I don’t say this lightly because designing good dependency management systems is much more subtle and difficult than people typically recognize, but from where I sit this appears to be fundamentally a dependency management concern. It seems a shame not to try to put GitHub Package Registry to good work here. Is that something potentially on the horizon?

This is an excellent point, and should solve the issue I put below about builds taking forever when pulling in a slow-building action.

If I'm using a marketplace action in my workflow, I want "foo/action@v1.0.0" to be treated like a binary package dependency, not a build from sourcecode.

All great points and I think you're onto something with the idea of using GitHub Packages. Definitely something we're considering, stay tuned.

If you ever have the opportunity, I highly recommend the show about Polynesian voyaging at the Bishop Museum planetarium in Honolulu. You learn a little bit about navigation by stars (in particular you get a taste of how unbelievably complex it is), some of the history of Polynesian voyaging and the recent history of the PVS, the Hokule’a and the amazing modern voyagers who’ve revived ancient Polynesian cultural traditions. It just leaves you in awe of Polynesian culture, knowledge, and accomplishments. I always make sure to catch the show whenever I visit Honolulu.

Guy Steele's friend Olin Shivers [1] was the PhD advisor of Matt Might [2] and Lex Spoon [3]. I'm pretty confident the entire field of programming languages research is a Marvel comic.

[1] http://www.ccs.neu.edu/home/shivers/ [2] http://matt.might.net/ [3] https://www.lexspoon.org/

Wasn't it Joe Hewitt?

I'm thinking of http://ejohn.org/blog/webkit-is-the-jquery-of-browser-engine...

The reason for layering is that the lower layer code remains compatible and even, let's say, idiomatically acceptable if excessively verbose.