Raven is a Golang IDE, built with speed and simplicity in mind.

It contains everything you need to write Go programs, bundled into a fast, batteries-included application:

  • Syntax highlighting
  • Vim keybindings
  • Autocomplete
  • Code generation
  • Jump to definition
  • Find all usages
  • Automatic lint/format
  • Integrated debugger

Raven runs at 144 FPS. The response time is far superior to any other IDE. Press a key, get an instant response.

Download coming soon




Raven's biggest features are its speed and its tightly integrated user experience. To accomplish them we do a few things differently:

1. Limited Subset of C++.

Raven's all C. We use C++ to overcome the inconvenient low-level nature of C — we use member functions, auto, lambda, and a gross defer macro — but we don’t structure our app in C++: no private fields, constructors, new, inheritance, polymorphism, RTTI, or STL. Instead of RAII we just zero our memory.

As a delightful consequence, when we want to know what our code does, we just read it. No more jumping back and forth between ten classes trying to mentally piece together a history of events. Slow code can no longer hide inside ten layers of nested classes.

2. Treat Errors As Another Code Path.

We don’t use exceptions for error handling, because errors aren't exceptional. They should just be another code path with well-defined behavior. Our program doesn't suddenly do something mysterious (and potentialy slow) when an error happens.

3. Custom Memory Management.

Calling malloc is a great way to drop a frame. We allocate a huge chunk of memory at the beginning, then manage it ourselves using fixed-size buffers, stacks, arenas, and pools (see Game Engine Architecture). This (a) is much faster, and (b) forces us to actually think hard about our memory usage, instead of pretending we have infinite memory and being shocked when it turns out we don't.

This model of memory is actually more consistent with reality. We only get a fixed chunk of memory that we have to manage ourselves, you say? Kind of like an actual computer?

4. No External Libraries.

When you’re building something hard, external libraries cost more than they're worth. Anything written by someone else is code you don't own. You end up having to (a) beat your program into the right shape to integrate with the library and (b) reason about your program in terms of the constructs the library gives you. God help you if the library has a bug, or does something stupidly slow.

Far better to own all of your code, so your program lies entirely within your field of vision and control. We only use two libraries in our whole app, ImGui and stb.

5. One Process, One Thread.

Our whole app is one big update-render loop. No IPC, synchronizing multiple threads, or client-server architecture with JSON over HTTP. Poof goes a whole source of bottlenecks, complexity, and bugs.

We make exceptions; our parser uses threads to parse multiple files at a time. But we don’t use processes or threads to partition our application into modules.

6. No Plugins.

Plugins are a mistake for several reasons.

If a feature is important, you should think of it, and build it directly into the IDE with native support. Since it's important, it should be tightly integrated with and as optimized as the rest of the application. Depending on plugins to offer important features means depending on other people to decide what features your app should have, which indicates a lack of vision.

Plugins are separated from the rest of the app, and from each other, fragmenting the app into siloed modules. An integrated development environment should be integrated. Splitting your functionality into discrete modules defeats the purpose of building an IDE in the first place: integrating all the different tools of software development into a streamlined experience for the user.

Plugins tend to suffer in quality. Plugin developers aren't as invested as the core developers to develop unreasonably high-quality software. They don't have enough information about the app's inner workings to make critical decisions about performance: the plugin API is usually a complete black box, and there's no way for them to interact directly with the app's internals, so they can't test what effect their plugin has on performance and optimize it accordingly. Stock VSCode and stock Sublime Text both start out fast, but quickly become slow after you install a handful of basic plugins.

Apple does this right: they (1) think hard themselves about what the right set of features are, then (2) build them into a single, integrated application, (3) using their native understanding of the app to make every feature as fast as possible. Lesser designers use plugins as a way to outsource innovation, yielding mediocre performance and a mediocre product. Raven regards any IDE that offers Vim keybindings through a plugin as a non-competitor.