workers-rs
gpuweb
workers-rs | gpuweb | |
---|---|---|
16 | 57 | |
2,288 | 4,589 | |
3.5% | 1.2% | |
9.0 | 9.1 | |
3 days ago | 3 days ago | |
Rust | Bikeshed | |
Apache License 2.0 | GNU General Public License v3.0 or later |
Stars - the number of stars that a project has on GitHub. Growth - month over month growth in stars.
Activity is a relative number indicating how actively a project is being developed. Recent commits have higher weight than older ones.
For example, an activity of 9.0 indicates that a project is amongst the top 10% of the most actively developed projects that we are tracking.
workers-rs
-
Python Cloudflare Workers
- The speed of the Python interpreter running in WebAssembly
Today, Python cold starts are slower than cold starts for a JavaScript Worker of equivalent size. A basic "Hello World" Worker written in JavaScript has a near zero cold start time, while a Python Worker has a cold start under 1 second.
That's because we still need to load Pyodide into your Worker on-demand when a request comes in. The blog post describes what we're working on to reduce this — making Pyodide already available upfront.
Once a Python Worker has gone through a cold start though, the differences are more on the margins — maybe a handful milliseconds, depending on what happens during the request.
- There is a slight cost (think — microseconds not milliseconds) to crossing the "bridge" between JavaScript and WebAssembly — for example, by performing I/O or async operations. This difference tends to be minimal — generally something measured in microseconds not milliseconds. People with performance sensitive Workers already write them in Rust https://github.com/cloudflare/workers-rs, which also relies on bridging between JavaScript and WebAssembly.
- The Python interpreter that Pyodide provides, that runs in WebAssembly, isn't as fast as the years and years of optimization that have gone into making JavaScript fast in V8. But it's still relatively early days for Pyodide, compared to the JS engine in V8 — there are parts of its code where we think there are big perf gains to be had. We're looking forward to upstreaming performance improvements, and there are WebAssembly proposals that help here too.
-
Cloudflare Workers Introduces Connect() API to Create TCP Sockets
Not yet, but we're working on that https://github.com/cloudflare/workers-rs/pull/324
-
How much Rust work is actually going on at Cloudflare?
I'm also in the Workers org but I have had a bit of interaction with Rust. There's some Rust in the Workers runtime using lol-html for HTMLRewriter as well as some tooling and there's the full blown workers-rs framework that I work on, but that's about it for the Rust I work on regularly.
-
std.rs is seeking a new owner
I'm an engineer at Cloudflare working on Workers (and a maintainer of workers-rs) and I'd love to help whoever ends up maintaining this get that PR rewriting it in Rust across the line.
-
Workerd : le moteur d’exécution JavaScript / Wasm qui alimente les Workers de Cloudflare …
GitHub - cloudflare/workers-rs: Write Cloudflare Workers in 100% Rust via WebAssembly
-
Turbopack - The successor to Webpack
I never said it was, but thankfully nowadays there are plenty of other tools that are fast enough to keep the dev cycle quick. Personally esbuild is my go-to when I need a bundler but I've grown really fond of SWC native api, we used to use it at work for our wasm build tool for our workers-rs framework.
-
Announcing support for WASI on Cloudflare Workers
There's actually a rust framework for Workers https://github.com/cloudflare/workers-rs
-
What's your experience with FaaS and Rust?
I'm a maintainer of the of the Cloudflare workers-rs project to allow you to write serverless functions in Rust running as WASM in our V8-based runtime. There's certainly some rough spots (doesn't have complete parity with our default JS runtime apis), but if you're concerned with cold start times and you don't need a full containerized environment I think it's a solid choice.
-
Hey Rustaceans! Got a question? Ask here! (25/2022)!
Most likely, it should, we just haven't had the time to fully implement it or add a library to wrap the FFI. Please let us know you need a feature by opening an issue.
-
Warp or Rocket.rs or Actix Web?
I may be biased, as the original project author, but I’d recommend using Cloudflare Workers https://github.com/cloudflare/workers-rs - totally free their with very generous limits.
gpuweb
-
Show HN: I built a free in-browser Llama 3 chatbot powered by WebGPU
Works for me.
WebGPU support is behind a couple flags on Linux: https://github.com/gpuweb/gpuweb/wiki/Implementation-Status
- WGSL Is Terrible
-
WebGPU now available for testing in Safari Technology Preview
People keep spreading this incredibly misleading statement, and yours is even more misleading (suggesting Apple opposed a 'GPU WASM')
By all accounts, Apple's /only/ stance was that if WebGPU used SPIR-V it would be a non-starter for them, due to ongoing legal issues between Apple and Khronos.
Apple actually proposed WebHLSL in collaboration with Microsoft, to have HLSL be the standard.
Mozilla employee's stance[0] was that SPIRV was too low level, did not fit with the goals of WebGPU portability and security, and expressed concern that Khronos may add functionality to SPIRV they cannot support in WebGPU like raytracing instructions .. 'So we'd always be on the verge of forking SPIR-V in some way.'
It was also noted by many people that even if a bytecode format was used, it would still have to be translated to the target (HLSL/DXIL, MSL, etc.) in almost the same way a text format would.
Nobody proposed a 'GPU WASM equivalent' or an alternative bytecode format.
The hard truth is that shader compilation is a fucking nightmare, people do not realize how bad it is across the different native APIs. SPIR-V is good, but it doesn't solve that - and presents other challenges if you are a web browser API. Vulkan and SPIRV are not the golden goose many make them out to be.
[0] https://github.com/gpuweb/gpuweb/issues/847#issuecomment-642...
-
Show HN: WebGPU Particles Simulation
Yes it is still a bit new. WebGPU is not finished and is still being worked on: https://webgpu.io/
-
Capturing the WebGPU Ecosystem
WebGPU currently doesn't support the "bindless" resource access model (see: https://github.com/gpuweb/gpuweb/issues/380).
The "max number of sampled texture per shader stage" is a runtime device limit, and the minimal value for that seems to be 16. So texture atlasses are still a thing in WebGPU.
-
Why aren't we using highly efficient int8 calcualtions in quants? (maybe eli14?)
There's even an implementation under discussion to have the dp4a instruction added to WebGPU (https://github.com/gpuweb/gpuweb/issues/2677)
- WebGPU – All of the cores, none of the canvas
- How to get Chromium working with the Vulkan driver on a RPi4?
- Anyone has Chromium WebGPU working?
- [Rust_Gamedev] WGSL est-il un bon choix?
What are some alternatives?
realworld-axum-sqlx - A Rust implementation of the Realworld demo app spec using Axum and SQLx.
wgsl.vim - WGSL syntax highlight for vim
worker-kv - Rust bindings to Cloudflare Worker KV Stores
pyodide - Pyodide is a Python distribution for the browser and Node.js based on WebAssembly
boringtun - Userspace WireGuard® Implementation in Rust
noclip.website - A digital museum of video game levels
workers-wasi
BestBuy-GPU-Bot - BestBuy Bot is an Add to cart and Auto Checkout Bot. This auto buying bot can search the item repeatedly on the ITEM page using one keyword. Once the desired item is available it can add to cart and checkout very fast. This auto purchasing BestBuy Bot can work on Firefox Browser so it can run in all Operating Systems. It can run for multiple items simultaneously.
litestream - Streaming replication for SQLite.
wgpu-rs - Rust bindings to wgpu native library
ssr-workers - Rust based Cloudflare Worker with SSR
WASI - WebAssembly System Interface