Do you have numbers for how much of the web avoids variable hoisting? How much of the web has more than one top-level fn per file? Do these numbers shift significantly between different toolchains or methods of delivering JS?
How is partial execution baked into JS? IIUC, my whole JS file is fully parsed an resolved before it is evaluated. If you're referring to the use of multiple files for parallelism here, then the obstacle there is not wasm itself but the work that's still in progress to define a dynamic linking story for it.
I'd point out that the need for better dynamic linking to enable lower TTI is also a problem faced in the bundling/tooling heavy JS community.
It would be interesting to try for some apples-to-apples comparisons for the parse and initial exec time of js vs wasm. The latter was designed with the goal of streaming validation and compilation, js needs to have a lot of work done before it can load.
Which strongly suggests to me that intuitions about KBs-of-JS vs KBs-of-Wasm are likely to be wrong, especially as the state of wasm implementations improves.
After calling this function, the caller is responsible for the memory
previously managed by the Box. In particular, the caller should properly
destroy T and release the memory. The proper way to do so is to convert
the NonNull<T> pointer into a raw pointer and back into a Box with the
Box::from_raw function.
I would guess that this might become a fun latent footgun in crates.io code -- everyone writes their unsafe code in a way that Just Works under the default allocator, but then things break down in confusing ways when enabling alternative allocators, which should be safe to do even when using external crates.
Re: non-thread-safe items in lazy_static, you can also wrap them in a mutex within just the lazy_static so the struct only uses synchronization when it actually needs to be thread-safe.
There's not a lot of consensus about what primitves good *-native framework needs, implementations are often pretty tied to specifics of the JS libraries they were built to be driven by (go figure), and the whole niche is still discovering what the right tradeoffs might be. On top of that, the technology atop which the star-native frameworks are built is moving forward too. Seems reasonable to expect that eventually a good non-DOM standard for these things might eventually emerge but I suspect it wouldn't be for a while .
FWIW, I read "To an outsider..." to mean "if you are reading this on HN and aren't involved in the community, this might seem like" as opposed to "I am pretending to be an outsider, let me tell you what about my perspective."
I'd actually be interested to find out how Cargo's performance compares in a situation as TheDong describes where all of the dependencies are being fetched directly from git.
Part of me wants to say "well of course Rust's tool is faster" but it would be interesting to see just how much crates.io acts as a performance optimization for running builds, installing deps, etc.
I tend to agree, but I also think that there's a little bit of nuance here. For one thing, I have definitely enjoyed using a large standard library...when I didn't have access to cargo or tools of similar quality.
My impression is that many of those who are asking for Rust's stdlib to grow are also/actually asking "please make it really easy for me to use these APIs that I care about," to which I would respond "it's OK, code can be easy to reuse even if it's not in the stdlib," "try cargo," and "crates.io needs to continue improving on discoverability."
I recently found myself inserting &/*/ref/ref mut into match expressions before I'd even seen a compiler error. My first thought was "aha, look at how experienced I am with Rust now!" Followed immediately by "I can't wait until this isn't something you have to learn to be productive with the language." And now that day has come! Really exciting for me.
I also need to go and find all of my impl Trait TODO comments and get to work on cleaning those up! What a good day.
I should also say that while I haven't read the second edition of the book yet I am excited to have some new Rust-related content to read. The first edition of the book was a really eye-opening learning experience for me (both about computers and Rust and also about how to build a community and prioritize teaching) and I can only imagine what an improvement on that is like.
> David Chisnall is a researcher at the University of Cambridge, where he works on programming language design and implementation. He spent several years consulting in between finishing his Ph.D. and arriving at Cambridge, during which time he also wrote books on Xen and the Objective-C and Go programming languages, as well as numerous articles. He also contributes to the LLVM, Clang, FreeBSD, GNUstep, and Étoilé open-source projects, and he dances the Argentine tango.
If tango experience isn't enough to make his opinion credible, I imagine being an LLVM and Clang contributor are pretty good qualifications.
Awesome! It looks like they have some tests in the directory -- I'd be curious whether they're able to re-use musl's test suite some. I had an experiment a while ago to incrementally port musl to rust while keeping the test suite passing: https://github.com/anp/rusl. Haven't put any time into it in a while, but I think matching musl's program-facing behavior is still a good idea.
AFAIK when most recruiters talk about placement rate, they're not talking about "engineers who we worked with who happened to get jobs," they're talking about "engineers who we placed and received payment for the placement." While Triplebyte hasn't explicitly stated that distinction here, I think a good faith reading of that phrase would suggest that the 40% is actually people who are getting jobs through Triplebyte.
edit: I should also say that I'm pretty excited about flutter, think it has a lot of great qualities and hope that it gets some solid adoption. Someone needs to solve these issues with building mobile apps.
Like any situation in software, there are likely to be tradeoffs. I certainly wouldn't advocate for launching large rewrites except under extreme duress. That said, I'm not sure I agree with how you're characterizing the tradeoffs for using wasm here. For one thing, the library in question sounds like it is a few thousand lines, not some gargantuan project. For another, part of what's awesome about wasm is that it can be somewhat incrementally adopted inside an existing project. I would also point out that for many teams or projects maintaining a consultant's code is not going to be as cost effective in the long run, especially if that code has a lot of language or VM specific optimizationswork done to it. Part of my point here is that the addition of new tech (rust, wasm) isn't complicated where optimizing JS is simple, but that they both carry complexity cost and should be assessed in context as possible solutions to a performance problem.
I agree that rewrites are often taken too lightly, but if they address the original problems I think it would be more accurate to say that they are often needlessly expensive ways to solve problems that can also be solved in other, cheaper ways.
I'd also point out that in the case of many open source projects, finding an optimization consultant is not even remotely an option. For many of those projects, if performance is suffering, someone needs to step up and figure something out. Then the question becomes which approach can be applied by some contributor who's actually willing to do it. If you don't have someone who understands polymorphism in VM runtimes, I think in many cases you'd be well served by sprinkling some wasm on the problem. Of course this doesn't apply in all cases.