dherman
My main feedback for the authors would be, the most important problems for sloppiness are global properties, not local ones. In my experience an agent, like a human, has finite capacity for its attention, but if it runs into local sloppiness that gets in its way, it can fix it on a by-need basis. The technical debt issues that matter are usually global issues that aren't so easy to fix: they require global analysis and global refactoring.
I don't know the answer, but I think we're going to need ways to measure architectural properties, like separation of concerns, clear architectural layering, well-defined interfaces, etc.
Weeks later, the rotted fish stench just wouldn't fade from my book of Beethoven sonatas. I ended up throwing it away.
//$HOME/.cargo/bin/rustc "$0" && ${0%.rs} "$@" ; exit
use std::env;
fn main() {
println!("hello, world!");
for arg in env::args() {
println!("arg: {arg}");
}
}
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!
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.
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.
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.
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?
[1] http://www.ccs.neu.edu/home/shivers/ [2] http://matt.might.net/ [3] https://www.lexspoon.org/
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...
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.
- 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.
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 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.
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!
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.
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
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.