| ▲ | raggi 5 hours ago | |||||||
The build time claim in the blog post is dubious, part of the problem is CGO isn't fast, but also if build time was really a motivator the null build path is entirely unoptimized for objects with long build times: cached null (no changes) build:
vs. cached non-null (changed) build:
Build times are a valid thing to care about and talk about, but the claims implied don't stand up to scrutiny. | ||||||||
| ▲ | marcopolo an hour ago | parent | next [-] | |||||||
As a sibling comment pointed out this isn't comparing the same things. I'll try to provide a better comparison. On a warm build on my machine, after editing a string in Zed's `crates/zed/src/zed.rs` and editing a string in Rune's `./cmd/rune/main.go` Zed: `cargo build --release`: 284s (debug 30s) Rune: `go build ./cmd/rune`: 15s note I'm using a release build in Cargo to make it a bit fairer as all builds are "release" builds in Go. | ||||||||
| ▲ | raggi 4 hours ago | parent | prev | next [-] | |||||||
Similar reflection, I ran `kitten __benchmark__ --render` in rune, the CPU time spent was 1:55. I ran the same in a libghostty based terminal emulator and spent 0:44 on CPU. I say this only because yes you can do engineering to meet the benchmark without dropping to deeper systems layers, but closing the gap on efficiency is hard. I'm not saying this to be a downer on your project - an IDE and VTE in Go are a fun project to have around, but the blog post makes implied claims of equivalence with moderate investment - but I think that's limited to single benchmark chasing. I say this as a polyglot who's day job is a Go based program that would be far easier to optimize in a systems language. | ||||||||
| ||||||||
| ▲ | ernestrc 3 hours ago | parent | prev [-] | |||||||
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. | ||||||||