HackerReposA FIELD GUIDE TO OPEN SOURCE
ProSponsor the shelf♧ 0
← Back to top all-time
sagemathinc
cowasm
C2022–2023
sagemathinc / cowasm

cowasm

CoWasm: Collaborative WebAssembly for Servers and Browsers. Built using Zig. Supports Python with extension modules, including numpy.

3Distinct people
7Mentions
0Explicit recommenders
563GitHub stars
REPOSITORY AT A GLANCE

What to know before exploring

What it is

CoWasm: Collaborative WebAssembly for Servers and Browsers. Built using Zig. Supports Python with extension modules, including numpy.

GitHub

Where it is used

No documented product use has been verified yet.

What people are saying

No recommendation phrase was found in the indexed comments.

No classified warning is attached to this page. Read the discussions before treating silence as approval.

Also in these discussions

No other repository is repeatedly linked in the same discussions.

This week on Hacker News

Nov 7–Nov 14 UTC · Direct repository links and separately labeled related project stories. Indexed through 11/14/2026, 5:04:57 PM UTC.

No direct repository links were found in the indexed HN discussions over the past seven days. Older discussions are available below.

Mentions over time

HN mentions by week7 dated mentions

Observed mentions: 2022-10-29 18:13:09 UTC to 2023-03-02 17:32:09 UTC. Weeks start Monday, UTC.

012342022-10-24 00:00:00 UTC to 2022-10-31 00:00:00 UTC (exclusive): 4 mentions; 0 submissions, 4 commentsOct 242022-10-31 00:00:00 UTC to 2022-11-07 00:00:00 UTC (exclusive): 0 mentions; 0 submissions, 0 comments2022-11-07 00:00:00 UTC to 2022-11-14 00:00:00 UTC (exclusive): 0 mentions; 0 submissions, 0 comments2022-11-14 00:00:00 UTC to 2022-11-21 00:00:00 UTC (exclusive): 0 mentions; 0 submissions, 0 comments2022-11-21 00:00:00 UTC to 2022-11-28 00:00:00 UTC (exclusive): 1 mentions; 0 submissions, 1 comments2022-11-28 00:00:00 UTC to 2022-12-05 00:00:00 UTC (exclusive): 0 mentions; 0 submissions, 0 comments2022-12-05 00:00:00 UTC to 2022-12-12 00:00:00 UTC (exclusive): 0 mentions; 0 submissions, 0 comments2022-12-12 00:00:00 UTC to 2022-12-19 00:00:00 UTC (exclusive): 0 mentions; 0 submissions, 0 comments2022-12-19 00:00:00 UTC to 2022-12-26 00:00:00 UTC (exclusive): 0 mentions; 0 submissions, 0 comments2022-12-26 00:00:00 UTC to 2023-01-02 00:00:00 UTC (exclusive): 0 mentions; 0 submissions, 0 commentsDec 262023-01-02 00:00:00 UTC to 2023-01-09 00:00:00 UTC (exclusive): 0 mentions; 0 submissions, 0 comments2023-01-09 00:00:00 UTC to 2023-01-16 00:00:00 UTC (exclusive): 0 mentions; 0 submissions, 0 comments2023-01-16 00:00:00 UTC to 2023-01-23 00:00:00 UTC (exclusive): 0 mentions; 0 submissions, 0 comments2023-01-23 00:00:00 UTC to 2023-01-30 00:00:00 UTC (exclusive): 0 mentions; 0 submissions, 0 comments2023-01-30 00:00:00 UTC to 2023-02-06 00:00:00 UTC (exclusive): 1 mentions; 1 submissions, 0 comments2023-02-06 00:00:00 UTC to 2023-02-13 00:00:00 UTC (exclusive): 0 mentions; 0 submissions, 0 comments2023-02-13 00:00:00 UTC to 2023-02-20 00:00:00 UTC (exclusive): 0 mentions; 0 submissions, 0 comments2023-02-20 00:00:00 UTC to 2023-02-27 00:00:00 UTC (exclusive): 0 mentions; 0 submissions, 0 comments2023-02-27 00:00:00 UTC to 2023-03-06 00:00:00 UTC (exclusive): 1 mentions; 0 submissions, 1 commentsFeb 27

Counts come from the repository’s dated source evidence. Index cutoff: 2026-11-02 08:16:59 UTC.

View mention counts and date ranges
UTC ranges include their start and exclude their end. Select a period to filter the source evidence.
PeriodStart (UTC)End (exclusive, UTC)MentionsSubmissionsComments
Oct 242022-10-24 00:00:00 UTC2022-10-31 00:00:00 UTC404
Oct 312022-10-31 00:00:00 UTC2022-11-07 00:00:00 UTC000
Nov 72022-11-07 00:00:00 UTC2022-11-14 00:00:00 UTC000
Nov 142022-11-14 00:00:00 UTC2022-11-21 00:00:00 UTC000
Nov 212022-11-21 00:00:00 UTC2022-11-28 00:00:00 UTC101
Nov 282022-11-28 00:00:00 UTC2022-12-05 00:00:00 UTC000
Dec 52022-12-05 00:00:00 UTC2022-12-12 00:00:00 UTC000
Dec 122022-12-12 00:00:00 UTC2022-12-19 00:00:00 UTC000
Dec 192022-12-19 00:00:00 UTC2022-12-26 00:00:00 UTC000
Dec 262022-12-26 00:00:00 UTC2023-01-02 00:00:00 UTC000
Jan 22023-01-02 00:00:00 UTC2023-01-09 00:00:00 UTC000
Jan 92023-01-09 00:00:00 UTC2023-01-16 00:00:00 UTC000
Jan 162023-01-16 00:00:00 UTC2023-01-23 00:00:00 UTC000
Jan 232023-01-23 00:00:00 UTC2023-01-30 00:00:00 UTC000
Jan 302023-01-30 00:00:00 UTC2023-02-06 00:00:00 UTC110
Feb 62023-02-06 00:00:00 UTC2023-02-13 00:00:00 UTC000
Feb 132023-02-13 00:00:00 UTC2023-02-20 00:00:00 UTC000
Feb 202023-02-20 00:00:00 UTC2023-02-27 00:00:00 UTC000
Feb 272023-02-27 00:00:00 UTC2023-03-06 00:00:00 UTC101

What Hacker News says

7 sources
CoWasm supports WASI right now via this library https://www.npmjs.com/package/wasi-js, which I actually develop as part of CoWasm . One unusually thing I did, which goes beyond what emscripten does, is I implemented a quite a bit of posix functionality, often by writing extension code to nodejs and calling it from Javascript, because there's a lot of POSIX that Node.js doesn't expose. This only works on Mac and Linux and is also available standalone in this library https://www.npmjs.com/package/posix-node, which is implemented in Zig. You can get a sense of the scope of POSIX functionality that goes beyond what WASI defines here: https://github.com/sagemathinc/cowasm/tree/main/packages/ker... One motivation for doing this is to try to get the full Python test suite to pass, including all the functionality that involves subprocesses, po
Read the rest
six calls, etc. I've only got to about 85% at this point. It can be a ton of tedious work, but at least Zig helps impose some discipline (e.g, it doesn't let you ignore handling errors until later), and makes it easy to test compilation for all supported targets on every change (due to excellent cross compilation support).
In CoWasm: An alternative to Emscripten, based on Zig (demo: Python in the browser)
I am using the Python ecosystem (with full support for dynamic loading of C extension modules) as an initial motivating project. Also, the Python test suite is extremely useful to root out problems. I certainly hope that this can provide a more complete alternative to Emscripten to the community eventually. That said, Emscripten is huge, and the problems involved in creating a more maintainable modular WASM build tool are subtle. For example, when implementing a custom module loader for Python-wasm last week, I discovered several bugs in the memfs and unionfs Javascript libraries (https://github.com/streamich/memfs/pulls?q=is%3Apr+author%3A... and https://github.com/streamich/unionfs/pulls?q=is%3Apr+author%...). I had to learn the code sufficiently to fix all these bugs, submit PR's, etc. Emscripten has its own analogue of memfs, w
Read the rest
hich is optimized specifically for WebAssembly in the browser, where memfs is a more general widely used library (with 10M+ downloads/week). CoWasm has no support for asyncify. Where I've run into setjmp/longjmp so far, I've been rewriting the code instead. E.g., the dash shell uses setjmp/longjmp, and I'm rewriting that to use return error codes instead (see, e.g., https://github.com/sagemathinc/dash/commit/7117e1f6496728af0...). > how would I go about porting a simple C->WASM w/ Typescript library project to CoWasm? That's a great question, which I'm not sure how to quickly answer, so I've created a discussion item here https://github.com/sagemathinc/cowasm/discussions/40 I did a massive refactor of the codebase during the last month, and it makes doing what you want much easier. However, it will help a lot once there are some good examples. I'm probably boing to individually package some of the things I've ported for CoWasm as standalone examples. In any case, CoWasm is extremely open source (BSD 3-clause), and I strongly encourage anybody who is interested to grab a copy, build it, poke around, make a PR, etc.
In CoWasm: An alternative to Emscripten, based on Zig (demo: Python in the browser)
Some of the interesting goals from the repo: https://github.com/sagemathinc/cowasm: - There is no business unfriendly GPL code in CoWasm. CoWasm itself is extremely liberally licensed and business friendly. - Unlike emscripten, we use modern Typescript, our code is more modular, and we make use of existing components when possible (e.g., the nodejs memfs project), instead of using our own. - A core design constraint is to efficiently run on a wide range of platforms, not mainly in the browser like emscripten, and not mainly on servers like wasmer. CoWasm should run on servers, desktops (e.g., as an electron app), an iPad/iOS app, and in web browsers.
In CoWasm: An alternative to Emscripten, based on Zig (demo: Python in the browser)

MAKE YOURSELF AT HOME

A few shortcuts

/
Search the collection
?
Open this guide
Esc
Close dialogs and navigation

Your saved repositories and interests stay in this browser.