lambda

I tried out SDF when I wanted to give someone some basic intros to how to use the shell and do shell scripting, and was looking around for something that provided some kind of free shell access.

The problem is, unless you donate or find someone to sponsor you, you don't actually get shell access; you get some very limited BBS functionality. And even once you do donate to get the basic access level, there are a number of basic programs (like Python and a C compiler) that aren't executable without getting a higher access level.

I wound up installing my own local version of pkgsrc in my home directory just to see if I could use that work around the issue, but that's not really a good option for the "teach someone how to use a Unix shell" use case.

It's easier to just spin up a free tier VM on one of the cloud providers than it is to use the "Public Access Unix" on SDF.

Yes, that's why I included the second part, "or the Book provides at least an introduction to the topic and then a reference to the more detailed information in the Reference."

For example, I don't think that every last detail of #[repr(...)] needs to be covered in the Book; but as the entry point for most people, it's how they discover features, so it should at least provide an introduction, and link to the reference for more information.

Likewise, while I think that the std::ops documentation does a good job of covering all of the details of operator overloading, I think the Book could provide a slightly more discoverable introduction to operator overloading which isn't just being used as an example of another feature, default generic type parameters, and provide some links to std::ops which might help with the Googleability problem.

One thing that I think really needs to be focused on is some SEO for the docs. For some reason, the way the Rust docs have been organized over the years, with old versions of docs and the old book being replaced by the new one, means that a lot of times, when I search for something I find old, out of date docs.

For instance, with operator overloading, if I search for "rust operator overloading", I find Rust by Example, which is OK but has a lot of text in comments which is harder to read, followed by a first edition link which warns about being out of date and then provides a link to the new book but not where in it to look, as well as a link to the 1.30.0 version of the first edition book, then a link to std::ops (which if I were a newcomer, I might not realize was relevant), then a 1.5.0 edition of the book.

The first edition operator overloading chapter seems pretty reasonable, actually, and it's present in the table of contents so its more discoverable, and it contains a link to `std::ops`. But because of the new structure of the second edition book, the first page I see if I try to check the book tells me that it's outdated, and directs me to the new book in which this material is harder to find.

And in the new book, even once I find it, there's not much to direct me to where to learn more about the topic. There's no link to `std::ops` documentation; I have to separately look that up.

Part of the problem was that the first edition book was a bit more like a more accessible reference, while the second edition has a more narrative or tutorial structure. So there's no longer a place to go for an accessible reference to all of the language features. There's the Reference, but that's written for detail and precision and not accessibility, and as discussed, is incomplete. There's Rust by Example, but that's mostly just code examples with commentary in comments. The second edition book covers a lot of the same material as the first edition, but because of the different structure, some of the "reference information" on more advanced features is just buried in a couple of "Advanced X" chapters.

I'm not sure of the best way to address this; I admit that getting this right isn't easy.

One option might be to have the new book be in two halves; one of which was the narrative/tutorial portion; chapters 1 through 18, and 20, perhaps, though they might be able to be slimmed down a bit and some material moved to the second portion. The other half which is more of an "accessible reference" for advanced features; the material in chapter 19, but expanded a bit and with more discoverable per-topic chapters like the "Syntax and Semantics" section of the first book, plus the Nomicon material, and any of the topics which are missing.

Or, alternatively, just expanding on and integrating the "advanced X" material, Nomicon, and missing topics into the overall structure of the book.

Or another option would be to have the Book just be the Book focusing on the main narrative/tutorial introduction to the most common features, and have a Reference in two portions; one longer one which covers every major feature but in an accessible style with examples, followed by a more formal appendix covering each last little detail.

I guess ultimately what I'm saying (sorry for taking so long and so many diversions to say it, but as you point out, it is hard to get this right, and I've been thinking about what I'd be looking for as I write), is that there should be some place that has an "accessible reference" to all major features which is organized somewhat like the "syntax and semantics" section of the first edition book. The second edition book, chapters 1 through 18, is definitely a better organization as a book than the first edition, but that structure doesn't lend itself well to covering every feature, and as you point out, you wouldn't want it to.

But the Reference also isn't a friendly place to point people, both because of the "incomplete" warnings but also because it's written in a more formal style.

And the fragmentation into the Book, Nomicon, Rust by Example, stdlib docs, 2018 Edition Guide, Cookbook, Reference, Cargo Guide, Unstable Book, along with some of the reorgs along the way, can sometimes make it a bit hard to figure out the right place to look. I feel like there should be one document somewhere that has a reasonable accessible introduction, with examples, to every feature, in addition to the more formal and succinct Reference.

Maybe I should put my money where my mouth is and try to compile something like what I mean. It would help to have a little bit of buy in from docs team leadership, though, so that there would be a hope of it getting merged and maintained. Perhaps a docs RFC would be appropriate?

I'd say that most of these are language features. The only that are mostly library features are operator overloading and simd, but they both have associated language features supporting them.

I agree that completeness is hard, but I feel like it could be a bit easier if there were some consolidation of the material.

At the very least, make sure that everything covered in the 2018 edition guide is also covered in the Book, in at least a similar level of detail. I'd also make sure that everything covered in the Reference is covered in the Book, or the Book provides at least an introduction to the topic and then a reference to the more detailed information in the Reference.

Their FAQ says they are planning on offering matrix displays next year (https://rdotdisplays.com/faq):

> We expect to introduce an entirely printed passive matrix version in 2019.

It will definitely help to have some competition in this space.

The borrow checker allows for one mutable reference, or multiple immutable references. There are also primitives for allowing interior mutability through shared references, which enforce single access at a time by other means (mutexes, copying data in and out, etc).

References are always guaranteed to point to something that lives longer than them. What they refer to could either be on the stack, or it can be allocated and deallocated on the heap via smart pointers. Box<T> is similar to C++'s unique_ptr; there is a single owner, and when that owner is dropped, the referenced value is dropped. Arc<T> is similar to C++'s shared_ptr; it's an atomically reference counted pointer, so the value will be deallocated when the last clone is deleted.

These combine in ways that allow you to use most of those "best practice" patterns from C and C++, but with actual language guarantees that you will follow them and the compiler will catch it if you don't. In the internals of data structure implementation, you may need to go beyond what this allows with use of unsafe, but you can limit that just to a few small critical pieces of code that can be more thoroughly audited and tested.

In a large project "try to avoid doing that" doesn't really fly; in a large codebase, with dozens of developers, developed over multiple years, people are going to make mistakes. They will need to do some kind of refactoring, and one of the guarantees will get missed.

If you've done a decent amount of work in a large C or C++ codebase, you might appreciate this description of the process of storing a reference to a slice of a Vec in Rust, without having to manually reason about all of the places in which that slice could be invalidated: https://manishearth.github.io/blog/2015/05/03/where-rust-rea....

This article, written as a way to help introduce Rust 1.0, provides a few more examples, though they are artificial rather than from a real-world project: https://blog.rust-lang.org/2015/04/10/Fearless-Concurrency.h...

> If you follow the established best practices (and the compiler will warn you if you don't)

There are a lot of best practices that can be quite hard to follow without language support, and would generate too many false positives to warn about. For instance, use after free. There is no lifetime information available in the type system that the C compiler could use to tell you whether you are doing something that could result in a use-after-free. How do you propose the compiler could catch these, except in the most trivial cases?

Conditional compilation? There's still just a placeholder referring to the first version of the book or the reference. https://doc.rust-lang.org/book/conditional-compilation.html

pub(crate) doesn't seem to be mentioned in https://doc.rust-lang.org/book/ch07-02-modules-and-use-to-co....

Some things that are covered are a bit hard to find. For example, I didn't know if operator overloading was covered; it turns out, it's mentioned in https://doc.rust-lang.org/book/ch19-03-advanced-traits.html, but it's not in the outline and there's no table of contents on that page, and it's only actually mentioned as an example of how default generic type parameters work. The topic it is covered well by the `std::ops` docs (https://doc.rust-lang.org/std/ops/index.html), but since it's a language feature as well as a library feature, I'd expect it to be covered by the book as well.

Raw string literals are only covered very briefly in the appendix: https://doc.rust-lang.org/book/appendix-02-operators.html

#[path = "path/to/file.rs"] doesn't seem to be mentioned; there are probably a bunch of other obscure attributes like this that aren't mentioned.

repr? I didn't find any mention of #[repr(C)], #[repr(packed)], #[repr(align)] etc. I also didn't find union.

simd? Seems to only really be covered by the 2018 edition guide. Googling "rust simd" turns up references to the old, unstable std::simd.

The first two examples are a couple of things I've recently looked for and couldn't find; the others are ones that I noticed browsing around just now looking for other things that might have been missed.

Now, some of these are documented in the reference, in the nomicon, in the 2018 edition guide, or in the standard library docs. But that's one of the problems; that there's no one, or even two or three, places you can go to find everything you need.

The reference has large warnings at the top about being incomplete, although it's actually not as incomplete as I remember, it might be a good idea to remove the scary warning from it, or to do an audit of it and only put the warning on the sections that are found to be incomplete (like the memory model, which is clearly incomplete as it hasn't actually been formalized yet), but take it off of the sections that actually are up to date.

And Google doesn't always help. It still sometimes gives me first edition book links at the top. When I was trying to look up all of the `#[cfg(target_...)]` forms I could use, I tried to search for "rust cfg target", https://www.google.com/search?q=rust+cfg+target, but that gives me Rust By Example, a first edition link, and a link to a placeholder that refers to both the first edition and the reference. It took a lot of clicking through to actually find the reference page on it.

I see references to John Gilmore being the original author of pdtar, and John Gilmore using the gnu handle, but I don't see any references to his usage of the name predating the GNU project or pdtar being referred to as gnutar before it became part of the GNU project.

I'm not saying that I disbelieve you, I just haven't been able to find any references for your claim.

ChangeLog.1 and NEWS only go back to after it was migrated to the GNU project (http://git.savannah.gnu.org/gitweb/?p=tar.git;a=tree), his personal site, http://www.toad.com/gnu/ seems to be down but an archive (https://web.archive.org/web/20180623140434/http://www.toad.c...) just says 'In 1985 I wrote the "pdtar" program, which eventually became GNU Tar.'

He clearly uses the name "gnu", but did that usage predate the GNU project? I haven't found a reference for that.

> It's the other way around. The book isn't better because we evolved for the book. The book is better because it evolved for us.

But computer interfaces are evolving for us as well.

I'm not arguing that they are currently better; just that there isn't much about the form of the book that we are "hard wired" to prefer, but rather some inadequacies in both human interface as well as some other practical issues of e-book distribution.

The first paper you link is the only one that I would say really supports your point, but it only compares one way of reading on a screen (a PDF) against paper for a short document, and it doesn't probe very deeply into why reading comprehension was worse on the screen than paper. Is it the spatial location, is it the fact that you can spread out pages and see more at once on paper, is it the reduced eye strain from reflective vs. backlit presentation?

These are all things that could be relatively easily compared; provide paper with a scrolling interface rather than letting you turn the pages by hand, provide a paginated interface for the screen, use an e-ink display rather than LCD for the e-book case.

The second is about spatial memory of information on paper, but doesn't compare with a computer screen, and you can have a memorable spatial arrangement on a computer as well.

The third one compares paper to screen for proofreadig, but is from the 1983 and using white on black text on an Apple II. I think the differences in screen technology and UI design, along with the subjects having to learn a special purpose UI for copyediting on the screen, make that not all that relevant simply for the comparison of reading a book.

So anyhow, while there is some research on a screen being not as good as paper, it doesn't look like it goes into very much depth as to the reason for the difference, and whether it's based on spatial memory, deficiencies in UI on the computer, eye strain due to backlighting, or some combination.

No, the difficulty is based on the average rate of generation of blocks over the last few weeks.

If people put less computational power into generating blocks, fewer blocks will be generated. After each n blocks, nodes adjust their difficulty based on how long it took to generate those blocks, to try and achieve an average of a block every 10 minutes.

But how much computational power people are willing to put in depends on price. It only makes sense to mine if you get more out than you put in in the cost of buying the hardware, amortized over the life of the hardware, plus the cost of the power used in mining. If the price of Bitcoin drops, there are fewer people for whom it makes economic sense to continue mining, so some will turn off their miners, reducing the hash rate.

When global hash rate reduces like this, and the difficulty drops, then the people remaining will get more BTC per unit time from mining, so it can make economic sense for them to continue mining, as long as the price doesn't drop further. So indirectly, the total hash power of the bitcoin network is linked to the price of bitcoin; or, the price of bitcoin relative to the price of electric power.

> 3. Consequently, most of the processing units now deployed in 4-core-and-up machines are doing nothing most of the time but generating waste heat.

While it's true that most of the time a 4-core or more machine has idle cores, I'm not convinced this is a problem.

Yes, most of the time spent on a modern computer consists of doing things that aren't particularly computationally expensive. But our perception of the speed of a personal computer isn't based on some kind of steady state performance on batch jobs, I think that worst-case latency is a lot closer to how we perceive the speed of a computer. Of course, in specialized domains like HPC the steady state performance on batch jobs is important, but this article seems to be discussing personal computers.

Even if they come up rarely, you still hit computational bottlenecks at times when latency is important. Whether it's some bloated web page, some big Excel computation, a compilation for us programmers, or the like, there are plenty of times where you hit some kind of bottleneck in which you can make effective use of all of your cores, so even if 99% of the time you have idle cores, that 1% of the time can shape your perception of how fast your computer is.

And the fact that most of your CPUs are idle most of the time doesn't mean you are wasting power. Modern CPU cores conserve power when idle, via P-States (frequency scaling) and C-States (turning off idle cores).

It is probably true that there is a lot of software out there which could take better advantage of parallelism but doesn't, in some cases due to performance not being prioritized, in some cases due to some essential complexity of parallelizing the code, but also in many cases due to accidental complexity of parallelizing code due to unsafe languages like C and C++ that can make it quite difficult to refactor serial code into parallel without worrying about introducing significant bugs.

> Our brains are wired

Any time this phrase appears in an argument it's a good indication that I can ignore the argument.

Our brains are not "wired." They are pretty malleable and adaptable, and while a lot of that happens during childhood, they do remain fairly malleable throughout life.

While there are neural structures that are specialized for certain tasks genetically, it is incredibly unlikely that the form of the book has had any significant evolutionary effect that would lead to some genetic predisposition for a book compared to some other form of conveying written information. Books have only existed for a couple thousand years, but originally were quite expensive to produce and only available to the wealthy; mass market production of books has only happened for a couple hundred years.

There are probably reasons why many people prefer physical books to e-books, but to make a claim that it's based on some kind of "wired" preference in our brains rather than practical factors like battery life, compatibility issues, screen refresh rates, or any of a number of other simple, practical explanations is a bit extreme, and would need to be backed up with some kind of evidence.

I personally don't consume much in e-book form, but the reasons are because of DRM, ecosystem lock-in, poor formatting in e-books, and the like. I actually consume a lot more content electronically than I do in dead-tree form, but it happens to be web pages and DRM-free PDFs.

Are you sure you're not confusing GNU tar with gnuplot? http://www.gnuplot.info/faq/faq.html#x1-70001.2

Looks like this is the actual paper: http://advances.sciencemag.org/content/4/12/eaau3275

Note that this is about replacing the use of gold as a catalyst for synthesizing alcohol from coal, not any electronics usage.

I don't know enough about the science to say if this is promising for electronics usage or not.

Yikes.

There's a story from Reuters with more detail and more balanced coverage than this press release from Qualcomm: https://www.reuters.com/article/us-apple-qualcomm-court/germ...

Apparently, there have been rulings in the US that Apple and Qorvo (supplier of the modem chip in question) hadn't violated this same hardware patent, based on a detailed technical analysis. So there's a chance that this ruling could be overturned on similar grounds in Germany, hence the bond that Qualcomm has to pay against possible damages.

For anyone curious who isn't likely to need to avoid knowing infringement, I think this is the patent in question: https://patents.google.com/patent/EP2724461B1/en

Oh, wow. They've also changed the license a couple of times in 2016 and 2017 to make it more restrictive.

Early 2016: https://web.archive.org/web/20160411070811/https://www.virtu... Late 2016: https://web.archive.org/web/20161208112443/https://www.virtu... Current, last changed July 2017: https://www.virtualbox.org/wiki/VirtualBox_PUEL

In the earlier licenses, "personal use" was just defined as the person using it being the same person as who installed it, and only one person remotely accessing the desktop at a time. So I had interpreted this as being OK for developer VMs in which the developer installs it themselves and uses it for their own development purposes. It also contained an "evaluation use" with a vaguely defined period.

The current license now defines "personal use" as explicitly non-commercial use, and adds more restrictions on client access that applies to any type of clients and not just remote desktop access, as well as explicitly defining the evaluation use period to being 30 days.

So while I didn't really have a concern about developers using VirtualBox with the extension pack previously, given the new license and the fact that they seem to be enforcing it via phoning home, it looks like it's time to set a policy of no one using it.

Luckily, we've already pretty much transitioned everything over to libvirt/KVM on Linux hosts, and people have generally been using VMWare or VMWare Fusion on Windows and Mac hosts.

When I mentioned "multiple vendors," I was talking about hardware implementations that have actually shipped.

I've been looking for RISC-V chips that I can buy right now, and from what I can tell, there are only a handful. Two from SiFive (the E310 embedded processor, and U540 supervisor mode/Linux capable processor), one from GreenWaves (the GAP8). Turns out since I last looked (around the beginning of October) it looks like the Kendryte K210 has been released, also available in the Sipeed M1 module (https://www.cnx-software.com/2018/10/22/sipeed-m1-risc-v-com...). Anyhow, that makes 3 vendors shipping hardware implementations.

It's possible there are other special purpose chips not widely available for sale, or not advertised to English speaking customers, but I haven't found much evidence of them.

There certainly are a lot of RISC-V projects under way, which was what I was referring to by "that likely means that there are a number of others where it's fairly far in the pipeline." I think the "hundreds" from the article you quote is about total number of projects, not total number of vendors.

Some of these are just academic projects, some are multiple projects at the same vendor, and so on. I wouldn't be surprised if it was dozens of vendors that have projects at various stages of completion, however. I can imagine we'll be seeing a lot of releases over the next couple of years.

And there are a number of cores you can run on FPGAs, from high-end cores like BOOM that can be run on big expensive Xilinx FPGAs (or on Amazon's cloud FPGAs), to low-end like PicoRV32 that you can run on a $5 Lattice ICE FPGA.

You mean RISC-V or MIPS?

There's a reason why I said SIMD/vector extension, since RISC-V first started down the SIMD route, but then they took a step back and decided that a vector extension might work better, so from what I can tell more work has been going into the vector extension than SIMD. But neither SIMD nor the vector extension are finalized yet.

I'm unaware of a MIPS vector extension, it seems to just have standard packed SIMD instructions, though I'm not that familiar with MIPS.

Probably not at this point. If they had done this right when RISC-V was first announced, then maybe, as at that point they had the advantage of much more ecosystem and tooling integration.

However, it's now at the point where there are shipping RISC-V Linux distros, it's supported in GCC and LLVM out of the box, there are more than a dozen open-source RISC-V cores (https://riscv.org/risc-v-cores/, several of which are actually parameterized families of cores), and there are companies like SiFive offering commercially supported proprietary cores. There is hardware that has shipped from multiple different vendors, and that likely means that there are a number of others where it's fairly far in the pipeline.

With MIPS being behind Intel on the desktop and server market, behind ARM on the proprietary embedded core front, and behind RISC-V on the open source ISA and cores front, it's a bit hard to see why someone would buy MIPS who hasn't already invested in it.

If you want something more well established with a wider variety of cores available to purchase, you'd go with ARM. If you want something with no ISA licensing fees and even potentially no charge at all for an open source core, you can go with RISC-V.

I suppose there is some chance that MIPS could win some folks over from RISC-V for already having stable SIMD and DSP extensions, and more overall architectural maturity than RISC-V. But given that this seems to just be opening up the ISA without opening up any cores, and right now is a press release without having decided on the governance structure for the project or released any assets, while RISC-V has a number of fairly mature open cores including Rocket, BOOM, RI5CY, and more, and has a governance structure with a number of different companies involved, it seems like it will be a while if ever for MIPS to catch up on the open ISA front.

These include instructions for saturating arithmetic (arithmetic that give the greatest or lowest possible values, rather than wrapping around), 16 and 32 bit fixed point, fused multiply add instructions, and some SIMD instructions https://en.wikipedia.org/wiki/MIPS_architecture#MIPS_DSP

Basically your usual DSP fare.

ARM has a similar extension; see https://en.wikipedia.org/wiki/ARM_architecture#DSP_enhanceme... for a reference to it, or http://infocenter.arm.com/help/index.jsp?topic=/com.arm.doc.... for details.

I don't think that RISC-V has a DSP extension yet; they are still working on nailing down their SIMD/vector extension story.

There is a link to exactly that at the end of the second paragraph: http://io.livecode.ch/learn/webyrd/webmk

Yes, my point is, either leave the link to the Twitter thread (which also contains a link to the paper), or link directly to the paper. Linking to this summary page, which contains a brief abstract that contains more words but less information than the Twitter post, seems to be worse than any of the other options.

Hmm. The tweet, and thread on Twitter, has more actual information on the vulnerability than the page you linked to. You have to click through to the actual paper to get the additional information. I feel like the Twitter link gives a better quick summary information.

From what I have gathered, much of the reason behind the licensing process for barbers is for shaving, with a straight razor, which does have considerably greater risks of cuts and infection.

However, very few people go to a barber for a shave anymore. It used to be that most people would go to a barber for a shave, and shaving yourself was unusual. Since the advent of the safety razor, cartridge razor, and electric razor, it's the other way around, where it is unusual to go to a barber for a shave. But in many states, training on shaving is a large part of the training for barbers.

In fact, it also used to be the case that barbers were the surgeons as well, though I don't know how much of that time overlapped with the licensing era.

I don't know how much of the remaining licensing process for modern barbers has to do with actual safety concerns, or is just inherited from the times of barbers being surgeons or doing the majority of shaving with straight razors.

The documentation on the BOOM processor mentioned in this article seems to be a good source of information: https://docs.boom-core.org/en/latest/sections/RobDispatch/ro.... Link goes specifically to one component, the reorder buffer, the rest of the docs discuss more of the components that are necessary to make it work.

Also range, especially in winter. I have to drive about 180 miles every couple of weeks, and have another trip for a vacation that is about 580 miles (and no, flying would be impractical), which I usually do in one shot or with a single overnight.

There are very few electric cars on the market that make the 180 mile trip without a long charging stop on the way in good weather, the Tesla and the Bolt are the only that I know of (though it has been a while since I've checked), and I'm not sure how I'd trust them for that rage in sub-zero temperatures.

And the longer trip would probably require at least two or three charges. While it requires stopping for gas in a gasoline car, that's a 5 minute stop, not the 30 minutes to an hour for even a fast-charge to 80% you get on an EV.

I always have a hard time using some services when in incognito mode; I get the captchas, and either they are wrong or are really hard, and it can take several tries to get through them.

> Beyond that, it's 0.8-1.2g of protein are recommended MINIMUM daily intake to avoid diseases originating from protein deficiencies.

Eating below the minimum RDA of 0.8 g/kg is unlikely to cause diseases of protein deficiency. The RDA minimum is fairly generous to allow for a certain margin of error. Most of the studies cited by https://www.ncbi.nlm.nih.gov/books/NBK234922/ indicate that 0.6 g/kg is likely a sufficient reference, and that a recommendation of 0.75 g/kg allows for enough confidence to cover individual variation. There was one study cited which found a 0.8 g/kg minimum, but most of the rest found that lower values should be sufficient; it sounds like 0.8 was picked just to be on the safe side.

> At 220# that means 80-120g protein as a minimum. That's a fair amount, and far more than you're likely to get from vegetarian sources at the time alone.

I doubt that most Roman soldiers were 220#. The minimum height requirement was 5'5", and estimates are that the average height was 5'7".

> There's also a minimum amount of essential fatty acids to consider... at the time it's not like they had canola oil.

There's a certain vegetable oil that Rome and Italy are quite well known for.

I'm with you on being skeptical that they were vegetarian, but I think you're overstating the requirements a little bit. I think it's fairly likely that they ate a fairly low meat diet just due to the logistical difficulties of obtaining fresh meat or carrying preserved meat.

It's not even really a replacement for NetworkManager; it's designed to be used to provide basic networking within containers, for systemd-nspawn. It can be used on host systems, but it's deliberately fairly lightweight and designed for fairly simple configurations in containers, rather than as a full fledged replacement for other networking management daemons.

> On the server side, it seems like docker format has already won. Maybe cpu architecture portability doesn't matter there and x86 is good enough?

Docker has won to a degree, though it still requires complex orchestration technologies like Kubernetes built on top of it, which are rapidly developing and not a particularly stable target.

> Although serverless and edge computing often use JavaScript.

Yes, this is where I see WASM really hold its own. Serverless and edge environments want to be able to have code running in a persistent process that is completely managed by the environment. Right now, they frequently offer just JS, or a couple of language runtime environments like Python as well; for serverless environments, you can generally load native modules if you want to, but its awkward, while edge environments will only run JS, though now they're starting to offer WASM.

It's the places where being able to run multiple tenants within a single process, without paying IPC and process isolation overheads, that make the overhead of WASM more likely to be worth it.

> On mobile this seems to depend on Apple and/or Google deciding to support WebAssembly for native apps, which seems unlikely.

I don't think it would be too unlikely for Google to support WASM for native apps. For one, it would allow them to do architecture independent apps without ART, on Fuchsia, for example. Right now, I think Dart + Flutter compiles to ARM code, but if they want to target a wider range of devices then platform independence could be important.