Show HN: Void - open source Cursor AI code editor | Hacker News Reader

Show HN: Void - open source Cursor AI code editor

voideditor.com

13 pointsandrewpareles8 comments

Hey HN, we're Andrew and Mat and we're building Void, an open source Cursor alternative.

Our editor is an open-source VSCode fork. Our primary goal is to create a fully-featured AI editor where you can keep your data completely private. Going open source is really important because it let us take the logic that would normally live on a server, like prompt building or message handling, and run it on your local machine instead. This way you can do things like self-host Llama 3.1 or Gemma and never have your data leave your computer. You can also just send your prompts directly to foundational models (GPT4o, Claude) without going through a middleman API.

Another exciting part of the project is that we have full control over the IDE, and can build our own native features. Normally if you want to build an AI tool you have to make the same chat UI, history management, filesystem indexing, LSP, VSCode integrations, etc. We think we can standardize all these into a nice native API you can just plug into instead. It would be awesome to create a centralized place that lets people build advanced open source tools like AI edits across many files, and even agents, in an IDE we're all used to.

Let us know what you think of the idea. We've really enjoyed working on it and are super excited to see where it goes :)

Open articleView on HN

Awesome, I only recently started using Cursor after having used ChatGPT web interface for coding assistance for a while. It's great to see deep integration of AI assistance deep into the IDE. I stumbled upon this news while browsing for open source Cursor because I feel that it could be better in terms of DX. I like being in control of whatever tool I'm using. Some feature I will definitely find useful are: 1. Searching across the body of previous chats 2. Timestamps on chats 3. Easy copy of chat text wherever whenever cos I find it hard to copy certain texts at certain locations in Cursor 4. Currently I'm not able to navigate to panels from the editor using shortcuts keys bound to navigate up,down,right,left commands. I'm used to this in VSCode. 5. I mostly OpenAI models so it would be good to see some sync with whatever work I do in ChatGPT outside the IDE.

Are you available on github right now?

I'm excited about this idea. I don't like using non-open source thing because I like to know that I'm investing in something which I can tweak and contribute to. Open source is all around a better idea.

I also like the idea of using on-prem models. As open source LLMs get better and hardware gets cheaper, I can see being able to use local models being the winning advantage.

Please give me early access!

We really like about on-prem models as well - it definitely seems they will get comparable and win over paying for API credits.

Will make the first batch of releases ASAP!

how do you guys compare to https://trypear.ai ? They're really good

Pear consists largely of a VS Code extension built on top of Continue.dev's VS Code extension. We're building a more native integration into the VS Code editor, similar to Cursor. Is there anything you like about Pear that Cursor doesn't offer?

I'm also working on an AI code editor, but why VS code clone tho?

Zero to ones in this space seems more challenging but might be worth it

Great question - we're doing a VS Code clone to have access to features like language servers, debugging, extensions, etc - these are really annoying to build from scratch. We also think it's nice for users to just be able to do a one-click switch from VS Code to Void, and hard to win over Cursor users without it. I'm curious about how you're building your editor - are you building everything from scratch?

I've also made an editor/IDE from scratch and it is painful, for example implementing text rendering and Unicode support (emojis) is a PITA and takes a lot of optimization if you want below 1ms screen of text rendering. I however took the approach "every feature is a plugin", so when adding features I first made the core API able to handle the feature then implemented the feature as a plugin. So a few years into development I rarely need to touch the core API and can implement new features with a high level easy to use API in just days.

About adaption, it's very hard to make people switch over to a new editor, so by forking an popular editor you shaved off years of development, and it will be easier for users to switch over. But probably at the cost of implementing new features takes longer and large refactors more difficult.

Reply on news.ycombinator.com