Hacker Newsnew | past | comments | ask | show | jobs | submitlogin

Go was designed from the ground up for that sort of thing, so that makes sense. And anecdotally asymc/await is a pain in rust. I've only used rust async through other libraries, and not that very often. I usually use plain threads.


Yeah Rust supports the same concurrency primitives as Go, but man are they a pain to use by comparison. With Go it is as trivial as using built-in keywords to spawn and merge lightweight threads, and the lightweight thread is the default mode of execution when main is invoked. Structs automatically serialize to JSON. The standard library’s HTTP server is fast, concurrent, and safe for use in production. Summed together that makes use case like mine a breeze to implement in Go.

But yeah, if I was writing an embedded firmware or something I would absolutely prefer Rust.


I use it for numeric heavy stuff and I'm going through tonic for any service connections. That abstracts me from any async wierdness and for the dsp code I don't care about lightweight threads. I don't want many/any more threads than I will have cores.




Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: