Do you think it's gonna be a tool used by these "average teams" or like a standalone self-serve product without any service human involved? I'd bet on a former, but why do you think?
One thing I'd say as a UI/Web designer is that often you are responding to a unique set of requirements to a specific brand / use case / functionality. I can 100% see how tools like this will influence and redefine the idea phase of a project but at the moment I can't see how it will make the leap from something that looks like a fuzzy representation of an end product to something that IS the end product.
One of the target audience are distributed systems researchers: we provide a high-level strong-statically typed prog language for distributed systems.
Looking for:
- Scala / Haskell people who are into writing compilers and designing prog langs are most wanted;
- Distributed systems engineers and researchers;
- People proficient in scaling p2p networks (if you exist!);
- Engineering Manager;
As jpgvm mentioned, yes Rust is a compiled language so it works well with eBPF!
The full picture is always a bit nuanced though so to expand on that: I have tried it cursorily with rust [using wachy to trace wachy :)] and it appears to work. The one issue I would say is that wachy is currently hardcoded to use C++ symbol demangling, so rust function names are not completely accurate (although it's surprisingly decent) - please open an issue if you want that fixed (or if you run into any other issues)! I decided it's better to get it out there and improve things that people actually use rather than fix all my TODOs (excuses for being lazy).
And with rust async, I haven't tried it myself but looked into the details some time back. Wachy works by simply looking at function entry/exit timestamps, but the rust aysnc impl is using futures + poll rather than saving and restoring stacks, so it's not gonna work. You can presumably trace the future's poll function, which may or may not be useful. Although, perhaps with some custom eBPF logic and examining the poll return value it could be made to work...
My guess is no /s here. Rust has introduced a whole new batch of folks to native code that probably don't yet understand the blocks debugging and tracing are built on.
To answer the GP though, yes. This will work with Rust but you might have to check release mode settings to ensure its not stripping symbols etc.
Even so, the scope is different. I don’t use WebAssembly to define networks. Limiting privilege within the WebAssembly runtime is weaker than limiting it at the OS namespace.
Multiplexing between several WASM modules is exactly how services are organized on https://fluence.network
Each peer in a p2p network can host multiple services and expose their API to the network. Each service, then, is a collection of WASM modules that interact with each other in FFI manner.
How about XMPP performance on low-performance networks like mobile ones?
I believe poor networking performance was one of the reasons XMPP had to be customised in WhatsApp and overall didn't become as widely used as I'd like it to be :)
Is it still the case? Or was that problem addressed at standard level somehow?
I first started using XMPP heavily in 2014 when I was thru-hiking the Appalachian Trail. Much of the trail has extremely limited cell coverage (even if you can get Edge some of the towers are so bad you can literally only get a few bytes per second). I evaluated several different protocols and apps for communication with family, and XMPP beat them all hands down every time. The long lived TCP connections meant that once a connection was established I could keep it up and it would sit there slurping up the bits as it came. That experience later led me to get involved with the community and even write a spec about using XMPP on high-latency low-bandwidth networks.
It may have been bad at this at one time, I don't know, but at least since I've been using it's been fantastic with poor network quality, I suspect the people saying otherwise are just repeating something they learned in the early 2000s that's no longer true.
XMPP is routinely used on HF radio and SATCOM networks field-deployed by militaries. It's deployed with channel compression (so the links themselves are compressed), but it routinely operates down to way way below mobile. In general, the really bad links are used for federation (s2s) rather than client connections which demand lower latency for user interaction. I've personally watched it operate on HF radio modems down to single-figure bits per second - those are simplex links with a 30 second turnaround. It's slow of course, but it does work - and this is on the base standard. Any server can do this, there's three I know of in use.
WhatsApp decided, at some point in the past, that XML was too verbose and compressed it using a technique borrowed from WAP - essentially a fixed-dictionary compression. Newer WhatsApp systems don't ever bother decompressing to XML, and it's likely it can't be anymore, but it's fundamentally the same traffic patterns even now. Your WhatsApp account still has a jid (with a very short, fake domain) and so do your groupchats (also a very short fake domain). The WAP compression choice was unfortunate, as it only really had an effect back in GPRS/EDGE days, only on certain networks, and only on certain traffic patterns, because it's the number of packets that matter in most cases, not the number of bytes. There'd still be some rare benefit on 3G, but by 4G the benefit had all gone.
Meanwhile, clients like Siskin and Conversations work just fine on modern mobiles. Conversations (an Android client) does work better when given permissions to keep the sessions live rather than rely on push notifications, but testing has consistently shown that battery life in unaffected. There's a number of extensions that are widely deployed that help efficiency, for sure, and I'd not want to run without for preference - though it is possible, and not as bad as you'd think.
So I'd say that XMPP has no performance problems at all on "long thin" networks way beyond mobile.
To get the same performance out of anything based on HTTP, you need to recode to use the parallel protocols of CoAP and friends. Matrix have done this, but it means specialist clients and servers are needed, and as far as I'm aware there's only a single implementation.
That is a situation documented by people years ago, and has been wrong for years. See https://gultsch.de/xmpp_2016.html. Unfortunately the legend lives on because "it doesn't work" is a better soundbite than "it works"
Some extensions like XEP-0352 Client State Indication have been developed to fit the mobile world. XMPP on mobile is nowadays very reliable, except for iOS preventing 3rd party notifications.
