if anyone is curious about the technical details, I recently gave a talk about BrowserPod's architecture at the Wasm I/O conference. The recordings of the talks are being published on their YT channel (https://www.youtube.com/playlist?list=PLP3xGl7Eb-4P9UDywG2NO...), but mine is not there yet.
Ah and kudos to Syrus and his team for this release. Edge.js's architecture seems to have many similarities with BrowserPod. I see it as proof that we are both going in the right direction!
So using agents forces (or at least nudges) you to use go and tailwind, because they are simple enough (and abundant in the training data) for the AI to use correctly.
Does this mean that eventually in a world where we all use this stuff, no new language/framework/library will ever be able to emerge?
Competing with the existing alternatives will be too hard. You won't even be able to ask real humans for help on platforms like StackOverflow because they will be dead soon.
Looking forward to progress on the memory control proposal(s).
Another reason to want more than 4GB of memory is to have more address space, assuming that you have the ability to map it. With that capability Wasm64 could be useful also for apps that don't plan to use a huge amount for real.
It is a bit unfair to Wasmer, because it incur in the (presumed) overhead of `wasmer run ...`, but I could not figure out if the actual clang binary is directly available after it is downloaded the first time.
I don't necessarily disagree, but implementing these things in your custom runtime is easy. I am more interested in how they achieved them in the more constrained browser environment.
I am curious about the browser compatibility layer.
Does it support networking? (And if so, is it using a proxy to connect to the internet or is it using a virtualized network layer that stays in the browser?)
How is fork implemented? (Asyncify all the code?)
I was looking at the Github org page (https://github.com/wasix-org), but I can't figure out where this stuff is.
I agree. I implemented a subset of WASI, and the best resource was an autogenerated C header with function signatures and very terse comments, buried in the WASI SDK repo.
As an AI language model, I do not collect personal data directly as I do not have access to user information. However, I understand that OpenAI, the company that developed and manages the platform, has been ordered to temporarily limit the processing of data of Italian users and is under investigation by the Italian Data Protection Authority.
As an AI language model, my purpose is to provide conversational assistance and generate human-like text based on the input provided by the user. My training data is sourced from publicly available text on the internet and does not specifically target any individual or collect personal data.
I understand that OpenAI has been accused of not providing adequate information to users regarding the collection and storage of personal data and not having a legal basis for such collection. I cannot comment on OpenAI's specific policies and practices regarding data collection and storage, as I am not privy to such information.
However, I believe that it is important for companies to prioritize user privacy and to comply with data protection regulations. I hope that OpenAI will take the necessary measures to address the concerns raised by the Italian Data Protection Authority and implement appropriate safeguards to protect the personal data of its users.
What we usually suggest is to compile most of the application to Wasm (which is also the default), and move the parts that most interact with the outside world to JS.
This can actually result in a speedup if it avoids multiple back-and-forths between JS and Wasm, which is common if you use a Browser/JS api from Wasm.