The Dutch national government mandated login system relies on technologies and hosting of a private company that was in conversation with an American counterpart about a possible acquisition.
I don’t understand this comment, yes everything going over the wire is bits, but both endpoints need to know how to interpret this data, right? Types are a great tool to do this. They can even drive the exact wire protocol, verification of both data and protocol version.
So it’s hard to see how types get in the way instead of being the ultimate toolset for shaping distributed communication protocols.
Don’t know about difficult, but at least less elegant. Lazy evaluation, type inference, abstractions like Functor/Applicative/Alternative/Monad make them so incredibly natural to work with in a language like Haskell. Sure, they exist in other languages (made a few myself) but it’s not the same.
We use WASM quite a bit for embedding a ton of Rust code with very company specific domain code into our web frontend. Pretty cool, because now your backend and frontend can share all kinds of logic without endless network calls.
But it’s safe to say that the interaction layer between the two is extremely painful. We have nicely modeled type-safe code in both the Rust and TypeScript world and an extremely janky layer in between. You need a lot of inherently slow and unsafe glue code to make anything work. Part is WASM related, part of it wasm-bindgen. What were they thinking?
I’ve read that WASM isn’t designed with this purpose in mind to go back and forth over the boundary often. That it fits the purpose more of heaving longer running compute in the background and bring over some chunk of data in the end. Why create a generic bytecode execution platform and limit the use case so much? Not everyone is building an in-browser crypto miner.
You’re right here I think, but it is a hard problem in practice I noticed. Hard in the engineering sense, because you’re sometimes writing generic library-level code that needs a domain specific notion of error bars and tolerances. So you need to parametrize everything, sometimes for multiple dimensions. Becomes messy quickly.
I must admit putting a mystery epsilon in my code here and there for that reason. Admittedly the wrong thing to do.
The problem is not 'someone is not correctly following the serialization rules', the problem is 'the serialization rules are quite terrible'.
This is not some interesting trade-off, this problem is fixable on all axes by using non-ambiguous, non-overloaded typing rules for your config format.