732 karma · joined September 25, 2013
From the authors:
> We agree with Dr. Kawada that no casual conclusion should be made in the present study, as it is an association study. We avoided using terms that imply causal inferences in the paper.
1. Lack of support for `externref`, AKA opaque references to host data. Sure, the Wasmer 2.0 blog post _claims_ they added support for it, but that amounts to allowing you to read the type signature in an existing module, but not actually use the feature yourself. With some digging, my educated guess is they wanted this to be their headlining 2.0 feature but weren't able to get it working, so they just pretended in their blog post and left the incomplete version behind a development flag.
2. An awkward context API for host calls. All host data associated with an instance must be `Send` + `Sync`. In practice I've found this leads to wrapping your entire context object in a `Arc<RefCell<T>>`, even if your data could otherwise live on the stack. Wasmtime does not have this limitation, so it's not a hard technical requirement.
3. It took me about 2 weeks of development to run into a use-after-free bug bubbling up into Rust.
4. The performance, at least for my use case, was not meaningfully better than Wasmtime. This may not be true if you're doing a lot of intense number crunching.
5. Lack of support for instance resource allocation pools. Wasmtime allows you to pre-allocate / reuse the resources associated with an instance, whereas you would have to roll this on your own with Wasmer.
6. Lack of support for the module linking proposal. This proposal may be incomplete, but it is still helpful ahead of its replacement.
This is on top of, as others have mentioned, their questionable business practices[1][2].
All of this may improve, but as things currently exist, Wasmtime should give you everything you would want from Wasmer in a more stable, more complete and more ergonomic package.
Evidence for this is that pepper varieties tend to be spicier in wetter environments, where the biological resources spent on producing capsaicin to fight fungus are more valuable than preserving them in case of drought.
> Höschen means panties, and ficken means, well…
Hint: Dutch is a close cousin to English. Try just pronouncing it.
I don't believe it is yet implemented in browsers, but I know Chrome at least is working on it.
This would assumedly let you use an image of your signature rather than printing and signing.
Edit: from rqlite's FAQ
> Raft is a Consistency-Partition (CP) protocol. This means that if a rqlite cluster is partitioned, only the side of the cluster that contains a majority of the nodes will be available.
Disconcertingly, this sounds like they assume that only one side of a partition can contain a majority of nodes. This isn't true if the partition is partial, eg A<-->B, B<-->C, A<-/->C.
A related point: numerically there are far more low level developers now than there were in past he idealizes. No such knowledge is being forgotten, it is used and innovated upon regularly. It may be in less frequent use, but is still there if needed.
[1]: https://en.wikipedia.org/wiki/Wikipedia:Unsolicited_redesign...
They are instead fuzzy classifiers, and thus have non-zero error rates.
> As such, any sort of failure either with ZomboDB itself, between Postgres and Elasticsearch (network layer), or within Elasticsearch will cause the operating Postgres transaction to ABORT. [1]
In my defense, there is a fairly important distinction between "any error that ES is capable of reporting back" and "any sort of failure within Elasticsearch".
That said, I and trust that you're more familiar with consistency levels than me, so I'll bow out here.
Doing so would require ElasticSearch to reach consensus on every read/write, which would remove most of the point of a distributed cluster. Despite this, ZomboDB's documentation says "complex aggregate queries can be answered in parallel across your ElasticSearch cluster".
They also claim that transactions will abort if ElasticSearch runs into network trouble, but the ElasticSearch documentation notes that writes during network partitions don't wait for confirmation of success[1], so I'm not sure how they would be able to detect that.
In short: I'll wait for the Jepsen analysis.
[1] https://www.elastic.co/blog/tracking-in-sync-shard-copies#:~...
It still seems to me that bowl-stacking is solved by sorting alone, though, which is of course much simpler.
Have you seen a difference yourself, and if so, could it have been from the overhead of loading gems instead?
Likewise, async IO has high throughout but often trades that off for increased latency jitter, since requests can block each other because of the limited thread pool. This is less a problem with threads because of preemption (though they of course compete for shared resources like database time).
I hope there's a plan to standardize this with the relevant organizations! I worry that's the only way to see widespread adoption.
https://en.wikipedia.org/wiki/Droughts_and_famines_in_Russia...