I think this is more of a "can you do this?" rather than something useful. Sure you can have Pico with this firmware around, but you can have much smaller and faster dongle instead.
Pico is an amazing thing tho, so many weird firmwares that are useful in a pinch.
All WASM can do is transfer bag of bytes between module runtime and host. So yes, so yeah it can just decode into a buffer. Even you use wasm components to give it I/O, you can still make these go to buffer.
How much faster? I have 10G, and in my experience you will very quickly get disk IO limited that it doesn't matter. You can optimize for that, but be honest - how much time you're actually going to save in lifetime.
Only place I saw 2.5G actually be beneficial is Wi-Fi 6E/7 for the APs.
* Not all PS4 games can run on PS5. Granted, it's only a few edge cases. But you still need to pay the PS4>PS5 upgrade if you want to avoid bottlenecks.
* PS3 games and the like require a 150+$ yearly subscription, and it's streaming for many of them. No thanks.
* No PS2/PSP/Vita compatibility, heck no emulation at all.
Exactly. That is just more about the ecosystem you are already in. I've been buying most games digitally since Xbox 360, and they all still run on my XSX. The same would be true if I had been in the Playstation ecosystem.
Yes, you missed people asking for years: away to do interop between languages in WASM, a way to interact with browser APIs without JavaScript from WASM.
This problem stems from the lack of a standardized component model. WASM is merely another casualty of that deficiency - one among hundreds of affected technologies.
The alliance is attempting to solve the problem at the wrong level and only for WASM, rather than addressing the root cause in a way that would benefit everyone.
Fair enough. Isn't that another topic more tied to WASM compare to what initially claimed to be a "System Interface" and not a language interface or a browser interface?
Do you know see how components model solves all three?
If WASI decided to keep bespoke runtime capabilities, then you would have whole zoo of:
- this runtime does support WASI
- this runtime does NOT support WASI
- this one supports WASI, but only older spec
- this claims to support WASI, but X/Y/Z capabilities are bugged
I think WASI switching to components was the right move. Sure, tooling right now maybe meh outside of rust (and even rust is still meh), but once things stabilize good tooling is to follow.
I've never lived in Los Angeles but the one that gets you in San Francisco if you do street parking is the street cleaning, and the random vandalizations.
Great? Too many variables such as not having to park on the street or bad/good luck. If you live somewhere that has street cleaning, street parking and meters there is a good chance of getting a ticket. Not everyone but the likelihood increases and most of LA does not really check most of those boxes at least in the areas I have been.
Street cleaning days/times are posted and if they aren't - you can contest and win the case. Meters? It's easy to NOT park in one hour zone if you need more than an hour. It's easy to avoid parking next to fire hydrant.
I have a friend that often parks in 30 minutes zone, for her hour-long yoga, sometimes she gets a ticket, but that's a gamble she is willing to make. You don't magically get tickets in big city, you get tickets because you ignored the rules willingly. Couldn't find parking because you were in a rush? Who decided to not account for "time to find parking time"?
Cool story. YMMV but for anyone that has lived in more urban cities it’s pretty normal to get at least a few parking related tickets. Not always but also not rare. In my example I already shared I would get meter tickets especially on my motorcycle where the looked at the wrong meter stall. Too much trouble to bother fighting. Just a cost of living in a city.
Glad it works for you but it’s not unreasonable to consider it a partial cost of living in a city. It’s easy to pick out the folks that have not owned cars in dense cities.
Can you name a single language that can talk to redis and doesn't have these in a form of a library that integrates with an app better than mystical embedded redis?
Every language you can talk to redis most likely has a library to do that, and it probably works much better with the rest of application than "embedded redis". If it doesn't, it probably has C-FFI and there is "fast, robust and well understood" implementations in C.
Sure. But if Redis was embeddable you'd get a robust C-FFI style implementation of those data structures which has been tested a lot more than some random library that has almost no existing users or active maintenance.
(I'm not personally sold on embedded Redis myself, but the question was "Aren’t your own programming language’s constructs much more well-defined / understood?")
> you'd get a robust C-FFI style implementation of those data structures which has been tested a lot more than some random library that has almost no existing users or active maintenance.
What are these mystical random libraries you're talking about? There is a solid C implementation of every data structure on this planet.
Why does it need to be pure C? There are C++ implementations. It's an algorithm not a social media app, it doesn't need to be updated once a week, C also not node.js - it doesn't break compatibility every release. What is wrong with these 10+ years touched ones?
Even the redis version of HLL isn't updated all that often.
That's exactly what I'm arguing for here: it would be useful if Redis data structures like that were available to be easily embedded in other programs.
"You can just adapt X from Redis" is the whole point of this hypothetical.
Well the most basic redis replacement would be just a global hashmap to replace GET and SET, possibly with a background thread to periodically delete expired keys. But obviously that stops working as soon as you get a second node.
The entire value of redis IMO is that is ISN'T inside your normal application, but rather some shared storage that all nodes can use to coordinate and that survives deploys, but that provides more ergonomic data structures than SQL databases. Caches are only one type of such shared data, but things like feature flags, circuit breakers and rate limiters are also super common (and super useful).
Neat. Write that up, match parity, and give all the function calls with the same name as redis, and you're both happy! You get to hand roll something, he gets to use a library that others have perfected over the years!
Unfortunately I have never really used Erlang outside of deploying RabbitMQ. I mostly use Go, Rust, Python, sometimes C/C++.
However, Mnesia seems like it is quite a bit more of a complete distributed database engine than Redis. To me the nicest thing about Redis is just the convenience of what it offers: very fast data structures, serialized, optimized (at least by default) for cases where speed is more important than durability. It is simple on many levels and somewhat constrained in scope. Mnesia seems to be aiming more generally in the distributed database category.
Really it would be more like Nebulex/Cachex which provide a really nice caching interface across ETS (what Mnesia is built off of) or other data stores.
Whole idea of CC is to write commits in away that is easy to generate change logs. If you utilize CC correctly or not, at best you get: commit log that harder to read, changelog that is hard to read and still requires you to write highlights (guess minor and path releases are fine).
Pico is an amazing thing tho, so many weird firmwares that are useful in a pinch.
reply