Hacker News Reader

Comment by nhumrich | Hacker News Reader

Go is nowhere near the speed of C. But why not consider Rust?

The Rust team decided to promote Rust as a "systems programming" language. And even though it can obviously do much more, and the bindings for most popular libraries are available [1], this label somehow attracts programmers who are more systems oriented and I think the language will continue to develop in this way, whereas Go/D/Nim will tend to try to be more general. [1] Imagine how surprised I was the other day to find Rust bindings to Allegro, a venerable game programming library from the old days of DOS and DJGPP...

Rust is getting to be popular for graphics and games, precisely because it has the performance of, and easy interoperability with, C, without GC, and in a much more modern environment.

Low memory requirements means portability to memory-constrained platforms. Interoperability with C presumably also implies easier access to low-level resources such as GPUs, and being able to take advantage of existing libraries for C, such as SDL.

People are also experimenting with Go in the same space, but it seems much less promising. Go is notoriously slow at calling C (or being called from C) due to goroutine context save/restore. It also has GC and a runtime.

I don't see why it's surprising to see a game programming library binding for Rust. I was drawn to it because it was advertised as a "systems programming" language. From a graphics perspective, this means that it's trying to be fast and gives me good control over low level stuff.

I've tried to get into Rust but I've found the syntax alone to be impenetrable despite reading through several guides multiple times.

If Rust was less complicated I might consider it.

Reply on news.ycombinator.com