ernestrc

Have you found that it does everything poorly?

TUIs now and forever.

I use ebiten which through CGO uses glfw, so there’s a few layers of abstraction between Go and OpenGL. It’s true that I had to implement unicode rendering and a bunch of other things for either completeness or performance, but Ebiten was a solid foundation to build from.

This is super cool! If you publish the weights I would love to bake it into Rune to run a screensaver hallucinating a terminal.

One word: focus.

If you're going to run a benchmark, at least post the results. I was planning on writing up a different blog post about the terminal optimization journey, but I actually used `kitten __benchmark__ --render` quite a lot to optimize it:

rune --version Rune v1.2.1 (HEAD is 40bf9cc1)

Results: Only ASCII chars : 1.13s @ 177.2 MB/s Unicode chars : 1.44s @ 123.2 MB/s CSI codes with few chars : 2.95s @ 33.9 MB/s Long escape codes : 6.25s @ 125.5 MB/s Images : 2.76s @ 193.1 MB/s

/Applications/Alacritty.app/Contents/MacOS/alacritty --version alacritty 0.13.1 (fe2a3c5)

Results: Only ASCII chars : 1.97s @ 101.4 MB/s Unicode chars : 1.26s @ 140.3 MB/s CSI codes with few chars : 1.26s @ 79.3 MB/s Long escape codes : 5.22s @ 150.1 MB/s Images : 1.34s @ 399.3 MB/s

ghostty --version Ghostty 1.3.2-main-+aa21caeaa

Results: Only ASCII chars : 354.9ms @ 563.5 MB/s Unicode chars : 815.42ms @ 217.0 MB/s CSI codes with few chars : 1.23s @ 81.6 MB/s Long escape codes : 6.39s @ 122.8 MB/s Images : 680.84ms @ 783.4 MB/s

Ran just now, on a Macbook Pro M4 Max 128Gb.

Rune doesn't support the kitty graphics protocol, so ignore the Images bench results.

You just compiled 9 extensions, a purpose built benchmark program, a toy ssh shop I built, a toy TUI browser and Rune, in serial. It's right there in the output. Try `go build ./cmd/rune` for a fair comparison.

Thanks, I'm gathering that people are very excited about this. We'll post something in the coming weeks.

We're looking for someone to spearhead this effort: https://github.com/unstablebuild/rune/issues/50. I personally don't know enough about TS/JS's ecosystem to design a good experience. I know that Typescript's language server is one of the reference implementations, so at least the LSP part should be easy. What I'm not sure is what else is needed from a day to day workflow perspective.

I've gotten this feedback from other folks as well. I just can't seem to strike a balance between "what do I do now" and "this is too much training".

> You mentioned “it’s like driving a new car” in another thread; I tried Rune in an earlier incarnation, and it was more drastic than a new car. I’m a vim user, and so enabled the Vim option in onboarding - that was a big mistake, because I literally could not do anything without using vim motions. I felt like a helpless noob on my first unix, how-do-I-exit-this-dam-text-editor.

I'm almost tempted to take this as a compliment. I personally hated every other editor's "vim mode". I wanted Rune to be more than a regular editor with vim mode. fwiw you can turn-off vim mode in the terminal (and iirc, console and agent as well) and keep it in the editor.

Yes, you can disable it but if you don't login with your Rune account, it won't ever connect. You can also disable auto-joining, even if logged in, with the following config: https://github.com/unstablebuild/rune/blob/main/cmd/rune/run...

:) https://forge.fedoraproject.org/go/sig/issues/1#issuecomment...

That’s exactly why Rune is also a terminal multiplexer. Rune acts as a bridge between automated and manual programming. You can fuzzy-search for symbols and files and reference them right from the chat UI, without having to copy and paste. When the agent is working, it uses Rune’s symbol index and IDE-grade toolset instead of greping the codebase. It also gets compilation errors right after applying patches.

And this is just the beginning. I think there’s so much more to explore in this space.

Thanks! We're still working on the legal details, but should have something finalized in the coming weeks.

I've been using Arch Linux and macOS for the longest time, so I never saw the appeal with flatpak. It could be a good option until Rune is popular enough. fwiw I'm also working on a cask for homebrew.

Yes, SSH is always an option, but it could totally work with a Tailscale network. In fact, we embed tsnet in Rune and use headscale as the coordination server, so there's nothing special about Rune's network. In the future, we're planning on adding more clients (iOS, Android), so hopefully it'll be more compelling then.

> One thing I would like to see on the home page is a video showing it being used. Fair point. I've been meaning to record a video for a while, but I hate being in front of a camera.

> Also would like to see how it looks in a light theme. Not great. I prefer dark themes so I haven't spent enough time making it look good on a light theme.

> The repository says it's keyboard driven does that mean it's modal or can I still use it like a normal modeless editor? There's three modes, vim, emacs and standard, which determine the key bindings not just when opening a file, but also everywhere else. https://docs.rune.build/learn/standard-editor

Thanks! We spend so many hours staring at these UIs.. I totally get it. It’s like driving a new car.

It’s a long process to get into Fedora, but we’re gonna give it a shot for sure.

Author here! The post explains some of the details behind using Go as the primary language for building an IDE. It also introduces our novel contributor program, which will distribute some of Unstable Build's proceeds amongst participating developers, as opposed to making them sign a CLA to surrender their rights to a company. Happy to answer questions!

Thanks! :) https://docs.rune.build/learn/key-mapping

I didn't know about rune, the programming language tbh. I guess we'll have to support it next

are you on apple silicon or intel?

edit: nvm I found the issue. cmd+q or forcequit! doesn't work while the onboarding tutorial is running.

Fair. It’s mostly to transfer muscle memory over anyway. I’m a vim user so having all input surfaces in the IDE be modal and obey HJKL is priceless.

I’d love to hear more about your opinion. Can you shoot us an email hi@unstable.build?

You’re right about this. I’ll add it to those pages as well.

edit: done

I’ll look into these. We do some special handling of cmd+q so resources are released gracefully. I’m guessing you didn’t select a preset yet. Is that accurate?

No. It's written in Go.

No plans yet but if there’s enough demand we’ll port it to Windows.

Fair. I’ll change the wording so it’s obvious. To answer your question, there’s no difference other than the licensing terms allowing you to use it for commercial work.