HN user
My high school Latin classmates and I made garum and left it to ferment in my back yard for a month. Young and foolish as we were, we stored it in a plastic Tupperware container. The day I brought it back to school for the class tasting, I had it sitting on a stack of piano books in the passenger seat of my car.
Weeks later, the rotted fish stench just wouldn't fade from my book of Beethoven sonatas. I ended up throwing it away.
Cool!
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}");
}
}
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.
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/
If you're interested in playing with any of these ideas feel free to hop onto our community Slack and chat!
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.
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.
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.
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?
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?
The reason for layering is that the lower layer code remains compatible and even, let's say, idiomatically acceptable if excessively verbose.
By way of update from the standards trenches: threads are indeed a part of the WebAssembly plan, and we're also actively working on standardizing the SharedArrayBuffer API for JavaScript, which would allow an asm.js implementation with threads (either as a direct compilation target or as a WebAssembly polyfill). Shu-yu Guo has been working on drafting the SharedArrayBuffer spec and is planning to present an update in the next standards meeting in a couple weeks.
I think part of what pcwalton and metajack are getting at is that Servo isn't "just a research vehicle" but rather intends to keep seeking adoption. I don't believe adoption and research are nemeses -- in fact, I'd say adoption is a core part of Mozilla Research's MO. I talked about this a little bit in a talk I gave this summer:
Maybe it's a clue that Mozillians are secretly building a handlink:
I can tell you from where I sit at Mozilla, everyone is very excited about Servo. It just takes time to build things! :) It wouldn't make sense to wait for Servo to reach full web compatibility before starting to integrate it into production uses. This is really just a natural next step in the progression of adopting Servo at Mozilla.
[disclaimer: I co-founded Mozilla Research, which sponsors Servo]
It's awesome to see the Gecko team continue to tackle big, ambitious projects now that electrolysis is rolling out. And I'm so excited that they're betting big on Servo and Rust. Servo has really been taking advantage of one of Rust's promises: that you can reach for more aggressive parallelism and actually maintain it. I believe recent numbers showed that effectively all of Firefox's users have at least two cores, and about half have at least 4. The more we fully utilize those cores, the smoother we should be able to make the whole web.
Over the last year, all three communities have been laying groundwork to be able to land Rust components in Firefox and share components between Gecko and Servo, and now it looks like that's teed the Gecko team up to commit to making use of some big pieces of Servo in the coming year. Some of the initial builds of Firefox with Stylo that Bobby Holley has showed me look really amazing, and WebRender could be a game-changer.
And the Servo project is just getting warmed up. ;) If you're interested in what they're up to next, check out Jack Moffitt's recent presentation from a browser developer workshop last month:
https://www.youtube.com/watch?list=PL4sEzdAGvRgCYXot-o5cVKOo...
It's frustrating but unfortunately all-too-common to see the number of posts in this thread subtly (or not-so-subtly) questioning the "seriousness" of the speaker. In my opinion, this talk is doing one of the most important things for Rust in particular and our industry in general: demonstrating that badass technology is not exclusively reserved for the Very Serious People of the world, but that enabling technologies and communities with the right attitude, like Rust, can unlock people's potential and give them opportunities that were otherwise unattainable for them.
Nothing makes me more excited about Rust than its enabling potential, and this talk hits on all the most important themes. (In my own small way, I'm trying to help push on this Rust theme by helping the Rust subcommunity of language bridges, to create better on-ramps for programmers in other ecosystems to make use of Rust.)
I think it behooves all of us, particularly those of us who haven't had to deal with being a member of a class of people whose credentials are constantly questioned, to ask ourselves what unconscious biases may be causing us to doubt the validity of a presentation based on signifiers like "too many doodles" or "I happen not to have known <some specific fact>," instead of addressing the actual content.
But again, I just want to say that I am over the moon that this was the closing talk at RustConf. Rust could have no higher calling than to be an instrument of opportunity for new systems programmers.
There are a few basic use cases I envision being the most common:
- When you have a portion of your Node app you really want to optimize (Rust's baseline computational performance is generally much faster than Node's and is easier to optimize predictably). - When you have a part of your algorithm that you want to parallelize. - When you want access to native libraries and need some glue code to expose it to JS.
One important caveat: there's a significant cost to calling back and forth between Node and Rust (I hope I can improve the cost over time but it'll never be free), so the use cases that fit the best will be ones where you're doing a lot of work in Rust so the amortized cost of crossing that boundary is small compared to the savings you get from Rust.
I don't know if there's a uniform Mozilla position on this, but here's mine! :) The main reason I care about the Web is because it's the world's biggest software platform that isn't owned. If someone can deliver their app to the world without submitting it for review by an app store and without paying a company a %-age of the revenue, and if they can market it through the viral power of URLs, then they have a lot more control over their own destiny. That's why I think it's important for the Web not to give up on hard but solvable problems.
But also I think there's a false dichotomy between "the Web should just be for documents" and "the Web should just be for apps." The Web is simultaneously an application platform that blows all other platforms out of the water for delivering content. First, there's a reason why so many native apps embed WebViews -- despite its warts, CSS is the result of hundreds of person-years of tuning for deploying portable textual content.
But more importantly, you just can't beat the URL. How many more times will we convince the entirety of humanity to know how to visually parse "www.zombo.com" on a billboard or in a text message? It's easy to take the Web for granted, it's fun to snark about its warts, and there's a cottage industry of premature declarations of its death. But I personally believe that the humble little hyperlink is at the heart of the Web's power, competitive strength, and longevity. It was a century-old dream passed on from Vannevar Bush to Doug Englebart to Xerox PARC and ultimately to TBL who made it real.
[I'm a colleague of the OP and Mozilla/TC39 member, i.e. someone who cares a lot about the JS programming model :)]
I'm enthusiastic about SharedArrayBuffer because, unlike threads in traditional languages like C++ or Java, we have two separate sets of tools for two very separate jobs: workers and shared memory for _parallelism_, and async functions and promises for _concurrency_.
Not to put too fine a point on it, shared memory primitives are critical building blocks for unlocking some of the highest performance use cases of the Web platform, particularly for making full use of multicore and hyperthreaded hardware. There's real power the Web has so far left on the table, and it's got the capacity to unleash all sorts of new classes of applications.
At the same time, I _don't_ believe shared memory should, or in practice will, change JavaScript's model of concurrency, that is, handling simultaneous events caused by e.g. user interface actions, timers, or I/O. In fact, I'm extremely excited about where JavaScript is headed with async functions. Async functions are a sweet spot between on the one hand the excessively verbose and error-prone world of callbacks or often even hand-written promise-based control flow and on the other hand the fully implicit and hard-to-manage world of shared-memory threading.
The async culture of JS is strong and I don't see it being threatened by a low-level API for shared binary data. But I do see it being a primitive that the JS ecosystem can use to experiment with parallel programming models.
Yeah, I won't try to speak for Eric or the SpiderMonkey team. Maybe Eric is firmly in support of STC, but in my experience he's very good at going beyond just implementation concerns and considering all the design constraints (one of which is the cost/benefit analysis of new syntax to the user model). IMO the important question isn't who supports what but what's the best outcome. AFAICT, all three of PTC, STC, and no tail calls are on the table, but there's more hashing out to be done.
Your new wording seems totally fine -- sorry if I was pedantic, and I'm really not bent out of shape about your blog post. I just want to be sure that people don't get confused about where things stand. New features such as STC require time to bake (which is part of what the multi-stage lifecycle for proposals is all about) -- I only meant to clarify the state of the discussion.
Edit: Grrr, re-reading this it still feels like I'm speaking for Eric. He's his own guy, I should shut up about his position! All I mean to say is, I don't think anyone should be staking out strong positions at this point in syntax design. The design process is iterative and uncovers new constraints and effects, and we should all keep open minds and work collaboratively. I'm open to all possible outcomes: PTC, STC, no tail calls at all. Tricky space!
Still, I wouldn't say nobody cracked a smile at the last TC39 meeting... ;P
(TC39 and Mozilla member here.)
FWIW, this:
For these reasons, the V8 team, along with TC39 committee members from Mozilla and Microsoft, strongly support denoting proper tail calls by special syntax.
All that said, I'm interested to see where the explorations go, and I'm looking forward to subsequent discussions.
Not at all -- my goal is simplicity and clarity so a confused (potential) user is a bug report!
Ah, I see!
So neon-bridge is a utility npm package I published that automates loading your Neon project (so it's not the name of an example module). And the expectation is that you only have one Rust package ("crate" in Rust parlance) per Node package, which is why you don't need to pass it the name of anything -- it's looking for _the_ native module in the package, as opposed to _a_ native module.
However, that single Rust crate may have multiple modules in its implementation. They live in the src/ directory of your Neon project and are picked up by the Rust compiler and build tool.
And yes, deeeeefinitely need to get some docs going... :P
Rust is a compiled language, so the JS files don't directly load a .rs file but instead they load a native Node extension, i.e. a .node file, which is generated by compiling and linking the Rust sources. (The node-cli tooling automates the whole build process.)
The line you cited is automatically locating the .node file, loading it, and returning the module object associated with it.
On IRC a couple people have been questioning this part of the API, suggesting that just using the standard npm module `bindings` might be better. It's a reasonable idea and I'll probably open a discussion in a GitHub issue.
Agreed! In fact it would also be useful in Node: you could build an almost-full-performance but portable version of a native module as a fallback for clients who don't have the requisite software to build a Neon library (say, one they only indirectly depend on) on their machine.