dikaiosune

great idea!

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.

Many types in the standard library do not consider it sound behavior to have their allocations freed by functions other than their own destructors:

https://doc.rust-lang.org/std/boxed/struct.Box.html#method.i...

    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.

Rust's built-in lints are configurable with compiler directives, so you'll be able to add

    #![deny(bare_trait_objects)]

To the top of your crate and cause a compiler warning if someone uses the old syntax on your project.

EDIT: just realized I mis-parsed "you" in parent. Oh well.

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.

The official (I think?) youtube channel has them: https://www.youtube.com/channel/UCaYhcUwRBNscFNUKTjgPFiA.

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."

EDIT: also, hi!

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.

from the article:

> 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.

One might assume that not every user of HN has the same beliefs and motivations as the others.

The path to stabilizing explicit simd intrinsics for rust should make many of those kinds of errors easier to catch with rusts casting requirements.

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.

I'm not sure when you last tried it, but CRNA apps (insofar as they run in the expo client) have sqlite support these days:

https://docs.expo.io/versions/latest/sdk/sqlite.html

(expo employee)

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.

I suspect that given Facebook's history with patents it has probably been in the works a long time to make this change.

Yeah I think this is fair. Although it might have helped to preface with that. Nonetheless, a small amount of egg on my face.

Since it wasnt clear from my post above, I buy all of this. But since IANAL, and I couldn't easily find a credible patent lawyer who has written publicly about this, I think it's reasonable to be measured in the claims I made. That said, you're obviously personally more familiar with the situation and having seen you around here before I'd give some weight to what you're saying. It's still a shame that it's difficult to find any public references. I also think it's a shame that there hasn't been a direct legal test/precedent for applying MIT style implicit grants to software. It might be a no brainer extension of existing precedent but to a lay person like me that doesn't quite sound like a sure bet.

Granted, the whole patent thing seemed a bit overblown to me. For the vast majority of companies, it's always seemed like you would probably have much bigger things to worry about if you thought protection from Facebook legal over UI patents was your main concern.

Some are of the opinion that MIT includes an implicit patent grant/license. Googling around I don't see many references to support this, but there are a few:

    * http://en.swpat.org/wiki/Implicit_patent_licence
    * https://en.wikipedia.org/wiki/MIT_License#Relation_to_Patents

Regardless of armchair and/or professional legal opinions, I don't believe this has been tested in court in the US at least.

Nit: IIRC one can receive a trait object through a stack based reference.

fn trait_obj(foo: &Trait)...

For clarification, "trait objects" are a subset of the trait system, and have much less use in rust programs than traits overall. A trait object is a dynamically dispatched pointer (often owned through Box or Arc), as opposed to the usually statically dispatched generic usage of traits that's more common in rust.

Destructors aren't guaranteed to run in Rust, they aren't necessary for memory safety. It's a fair concern to note that they aren't modeled, because they are pervasive and can impact memory safety, but they don't exist to support it.

Panics not being modeled is of course also a big gap, although you could always compile your code with panic=abort if you wanted to dodge that issue!

The author of alacritty suggests that there's an IPC performance issue with tmux/nvim on macOS: https://github.com/jwilm/alacritty#faq

> some humility about the boundaries of "correctness" would probably be a good idea for many of the pontificators

I'm probably biased, but in my experience the people actually pushing for correct-by-construction tools tend to be acutely aware of the limitations of their approach, especially when it comes to having to trust hardware to do what it says. For example, all of the people I've seen advocating for seL4 tend to be very transparent that their proofs assume hardware correctness and that they don't think it's realistic to exclude much of the hardware from the trusted computing base. Further, it seems to me that the Rust developers have been extremely pragmatic about what is possible to mitigate and what they have to trust the hardware for.

I'm sure there are some examples of what you're describing, but without any sort of references, the generalizations you're making have a whiff of bad faith.

This is empirically not true if you look at the usage of unsafe in pure Rust kernels. Yes, there is assembly needed, and some unsafe Rust code, but it's very possible to wrap up unsafe operations in safe APIs.

For example, the kernel repository for Redox (a written-in-Rust OS project) appears to have 242 usages of the unsafe keyword (including comments bc lazy), out of 18205 lines of Rust source.

parent's HN bio:

> I run all the production and cloud programming language teams at Google, and am also an open source lawyer.