Originally we (Andrey, Marcus, Juho) built MonoLisa in 2020 as we realised there's room for a better monospaced typeface for developers. The key insight was to make the glyphs slightly wider to make more room for design to make letters like m feel less cramped.
Since then we've released a variable v2 (2022) and now we're happy to expand the typeface with a new family called MonoLisa Text. The reasoning was to cover *other* use cases beyond coding with this proportional font.
We hope you give Monolisa a go as there's a free trial to try. We also welcome feedback!
Hi HN,
I think it's safe to say that the majority of developers don't give a second thought to writing code with I/O tangled in business logic. It's all too common to see code like: const user = findUser(email); if (!user) await saveUser(user);
Now, you may ask: what's the big deal? When we write code like this, two things happen:
1. It gets harder to debug production bugs. Unless you have the exact same database and remote API services to connect to, you may fail to reproduce the bug.
2. You have to use mocks and fakes in your tests, or use test containers, which only help somewhat, and they are slow!
To solve these issues, I built Pure Effect, a tiny TypeScript/JavaScript effect library. The core idea is simple: if a function performs I/O, it isn't pure. But if it returns a description of the I/O it wants to perform, it is. So instead of await findUser(email), you return a Command object that says, "I would like to call this function, and when it finishes, here's what to do next." Your business logic becomes a pure function. Same input, same output, every time. The database never gets touched until the interpreter (runEffect) runs.
When I first started the library, I didn't expect just how far that one idea would stretch. Once your pipelines are just data, a lot of wonderful things become possible:
- No need for mocking libraries. You walk the tree in tests and assert on its structure: assert.equal(flow.cmd.name, 'cmdFindUser'). Nothing is executed.
- Wrap any effect with Retry(effect, { attempts: 3, delay: 200, backoff: 2 }). The configuration is plain data, so you can assert on it in tests.
- Every command's input and output flows through the interpreter, so you get a full execution trace for free. You can write a simple timeTravel() function that replays it locally without touching any I/O. Perfect for debugging complex production bugs.
- An onBeforeCommand hook sits between your business logic and the interpreter. Since it sees every intended side effect before it fires, it can be used to enforce runtime guardrails. You can quarantine destructive calls before they happen for example.
- You can review AI-generated code before it runs. Since Pure Effect pipelines are plain data, you can inspect what the generated code intends to do before it touches anything.
There are just six primitives: Success, Failure, Command, Ask, Retry, and Parallel, plus effectPipe and runEffect. Zero dependencies. Under 1 KB minified and gzipped.
How it compares to Effect-TS
Effect-TS is the full-featured option in this space and has a large ecosystem. Pure Effect offers a different tradeoff. It covers the 80% case: testable pipelines, dependency injection, retry, and OpenTelemetry hooks, all in under 1 KB with zero dependencies and no new vocabulary to learn. Effect-TS is a framework you build around. Pure Effect, on the other hand, is a pattern you drop into existing code.
I've been using Pure Effect in production since December. It's at v0.8.0, not 1.0 yet, but stable enough that I wanted to put it out there and hear what people think.
GitHub: https://github.com/aycangulez/pure-effect
I wrote five posts that document how Pure Effect evolved. They are tagged at https://lackofimagination.org/tags/effect/ if you want the longer story.
Hey HN. http://peerd.ai is an AI agent harness that lives entirely in your browser as a web extension. You don’t have to install a separate “AI browser”. You don’t have to bolt on or run some external process or manage a clunky mcp integration. It’s just a fully contained web extension, written in no build vanilla JS with minimal non-browser dependencies, using your own provider keys, and Apache 2.
This isn’t just a fun hack. While it has largely been a solo side project, I genuinely believe the browser and the web could be the most natural platform for AI agents to operate safely, autonomously, and most importantly without A2A middlemen (more on that in a sec). To demonstrate that point peerd doesn’t just drive browser automation. It spins up isolated sandboxes using tabs and worker instances to support various real workload types. Those include headless JS computational work, visual JS notebooks, personal client side apps, and real Linux VMs on top of wasm with full http networking.
The industry discourse over the last several months has been dominated by “which substrate is the best for ai agent sandboxes” with many competing answers focused on different models and use cases. Cloudflare is one of the most prominent examples, positioning its v8 isolate based workers as the best in class solution thanks to faster than container startup times and strong isolation guarantees. The v8 isolate is of course the product of chromium, which runs on billions of browsers around the world for free. The browser as a whole is perhaps the most battle tested sandbox system in the entire software industry. It’s been built on 3 decades of learning from hostile content, hostile code, and hostile users. Native and cloud agents are necessarily rebuilding all or most of this posture from scratch. peerd doesn’t. It leverages everything the browser has to offer and pushes it to its functional limits, while inheriting its security baseline and isolation from the host system.
Robust sandboxing isn’t the only thing the browser offers and peerd uses. It comes with extremely powerful and underrated primitives, from webCrypto, webRTC, webAuthn, webGPU, and ~soon WebNN. Direct web access, with your real live sessions, and api calls with fetch present an alternative model to MCP integrations. The agent can write and spawn web apps right there in a tab, no hosted service necessary. Then there’s the A2A piece: peerd already has a rudimentary p2p (peerd-to-peerd?) network in place using webRTC. Today you can connect with peers on the network, add them as contacts, and share signed apps you’ve created. I’m working on extending these apps to be able to leverage the same p2p network to support decentralized web apps (dwapps), as well as facilitate true p2p A2A with no platform or middlemen.
Given this is an early part time project, this is an extremely experimental build and in a v0.x preview state. I’ve taken care to attempt to address the lethal trifecta: the main agent loops/sessions never ingest untrusted DOM code or possess low level navigation tools. It delegates those tasks to dedicated web runners with no wider tooling or secrets access that return summarized results. Both the DOM and the summarized results are bracketed as untrusted, meaning two stacked prompt injection escapes are needed. All egress goes through a central module that has a customizable deny list, and only models calls to designated allowed endpoints are possible. See more in the docs, site, and the code itself. Ultimately, use at your own risk.
Today anthropic, open router, local ollama, and even an experimental WebGPU instance of Gemma are supported.
Honest limitations: Chrome store and AMO are still pending until it can get more eyeballs and live usage. Just loading unpacked from GitHub is the easiest way to go, and as a bonus makes it easy to audit thanks to no build. Linux on wasm depends on the Cheerpx engine, which is not open source and has restrictions for commercial use. That may be a good reason to reassess it compared to alternatives, but it’s also the most performant and looks closest to implementing 64bit support.
Poke around, use it, critique it, and have fun.
I started this project back in 2015, to translate the TeX original specification into an easily parsed format (s-doc), and to create an HTML rendering of that format as a proof of concept.
The project is homed here: https://codeberg.org/dlowe/metaspectre/
Differences from the Hyperspec (from the README):
- Most importantly, it is free to modify and distribute.
- The original TeX is very hard to parse and use for things other than
generating a printed copy. The Hyperspec is an HTML rendering which
can be parsed as HTML, but loses a lot of information. The Metaspec
has an easily parsed intermediate form that can be used for all kinds
of purposes, like converting into lookups.
- Math equations are rendered using MathML.
- Includes the acknowledgements and appendix sections.
- Uses progressively enhanced Javascript to provide search and
light/dark theme switching.
- Incorporates over 145 patches for content, using corrections
accumulated over the years, and documented in the errata page.
- Includes TeX comments, which can contain interesting historical data.
- Includes links and identifiers to bibliographical references.Forte is an opinionated cloud platform that gets developers to production faster. Developers bring their code and Forte containerizes it with autoscaling and no cold starts, securely configures auth, and provides logging insights and monitoring out of the box.
I used to help lead service development at AWS, and even before AI coding was widespread, our biggest bottleneck was rarely feature development. We would spend months on security prep, observability tooling, on-call optimization, and other overhead before launching new features. When I worked in startups, every team hit a surprisingly similar set of problems and spent weeks rebuilding auth, logging, monitoring, and payments.
Platforms like Heroku, Render, and Railway are helpful for getting a container running but don't provide the rest of the tooling the teams need to go to production -- auth, secure defaults, and request-level logging. We built Forte to solve that entire stack of problems.
You can check out Forte at https://forteplatforms.com (it's free to sign up and doesn't require a payment method). We'd love to hear your questions and feedback!
by keepamovin ·
So I applied to YC a few times...this time I thought I'd use assistance. And I went all out. The thing I'm applying with did my application. I didn't touch a knob or a dial...didn't type a key. I just prompted the agent and it used the tool. You can see the insane 3 min video - sped up 21x here (link in its description to the full slow video too): https://www.youtube.com/watch?v=udwuE1PrM_0&feature=youtu.be
To me this is the ultimate YC application - one i didn't have to stress over, had someone to help me with, and was a showcase of itself. This Show is for the receipts.
Also, the most Y Combinator thing a YC application could do was recursively submit itself.
If you want to know what this dank magic is that crafted this insanity it lives here: https://fuckui.com
Good luck out there
For a while I've wanted to try out the new AI voices for long-form narration, but everything I found required a subscription that didn't justify my limited usage. I came across the open Kokoro model [0] and the voices are very good -- good enough to listen to for hours without the fatigue I got from legacy, robotic TTS voices. The model is 82m parameters and designed to run fast, but I still struggled to get reasonable times from CPU inference on my 12-core laptop. I thought a cloud-based GPU service would let me generate audiobooks fast enough to feed my own self-hosted library, and that same pipeline could become a product other people could use.
I had two goals in building this: get some exposure to AI multi-agent coding workflows, and build a TTS product targeting ebook to audiobook conversion specifically. 99% of ebookaloud was written by DeepSeek v4 in OpenCode. I've used about 750 million tokens costing $12 in credits over the course of a month, and I'm very pleased with the results. Every change/feature went through a plan -> implement -> test -> review -> correct -> commit cycle with a mix of Pro and Flash agents. This was generally limited to one or two concurrent workers. I had a separate eval agent for quality control on various parts of the extraction and synthesis pipeline, which I could run 8-10 at a time. I may be approaching Yegge's Stage 6 [1] in terms of AI workflow automation.
I later set up Claude Code and ran Opus 4.8 side by side with DeepSeek. There are definitely quality differences, but I'm an experienced developer with a hands-on approach. I didn't write any of the code, but I have read critical sections of what it generated and had extensive conversations with DS Pro about each step of the approach. Opus didn't have much critical to say about DeepSeek's choices, and I'm not convinced a frontier model would have made an appreciable difference for my workflow. I suspect on a large codebase the differences would become more apparent, but the few changes I implemented with Opus had similar issues to all the models I've used: random changes without my direction, over-complicating simple solutions, taking unanticipated/destructive actions when it gets stuck, etc. I do see Opus being capable of handling more of the complex planning and orchestration that I was involved in. That's something I may want sometimes but not others.
As to the product itself, there are a lot more sophisticated solutions out there. I'm not trying to compete with ElevenLabs. I'm targeting m4b generation for a seamless audiobook experience with a pay-as-you-go pricing model and good-enough output quality. This is the first product I've ever tried to commercialize, and AI code generation put something polished within reach. Without AI, this would have taken me 6-8 months of manual research and development, and I would have gotten burned out long before completing it.
I have a free sample on the front page of the site if you just want to see what it generates in terms of voice/format. I made a few opinionated decisions regarding output quality. I aimed for 140 wpm for most of the voices to match industry standards, but some are much slower or faster and lose prosody at that rate. Rather than give users a wall of options, I'm deferring to the playback device for things like speed control. If the site sees real usage I'd like to expand to support Kokoro's other languages, and extraction and synthesis from PDF would round out the product quite a bit.
[0] https://github.com/hexgrad/kokoro
[1] https://steve-yegge.medium.com/welcome-to-gas-town-4f25ee16d...