3 ms·

Isn't Go pretty close to optimal here, though? C/Rust may use somewhat fewer resources, but when you look at Go's efficiency over, say, scripted languages like

Isn't Go pretty close to optimal here, though? C/Rust may use somewhat fewer resources, but when you look at Go's efficiency over, say, scripted languages like Python, Ruby, or JavaScript, further optimization seems like it's gilding the lily.

Cyph0n 4y ago
For most use cases, I agree. But Rust is a better option when you also need one or more of the following: a) tight control over allocations b) deterministic performance c) strong data race protection d) zero overhead C interop (e.g., processing audio using ffmpeg)
steveklabnik 4y ago
It depends on what you mean by “optimal.” For many cases, sure, it’s not an issue, but Go has a big runtime that needs to exist. And its expectations mean that C FFI is not zero overhead, which is why you see so many pure Go packages, but isn’t appropriate in many of Rust’s use cases, which require zero overhead.
- deleted 4y ago
  [deleted]
- otterley 4y ago
  I agree - however, once you cross the border into C linkage/FFI, you’re losing both Go’s and Rust’s safety features. That seems like a wash to me. Besides, people are doing a splendid job writing pure Go libraries. It helps that Go has some fantastic observability tooling to help performance-minded engineers minimize unnecessary heap allocations. Finally, the Go runtime just isn’t that big. A few megabytes, I think. That’s well below the noise floor for most server environments, and it’s far smaller than, say, a Python or Java runtime.
  - steveklabnik 4y ago
    Yes, you're not wrong. I have gotten some threads crossed; I forgot this one is about the server side context. Yes, these sorts of things are often less of an issue than in other contexts. Sometimes it still matters though. Just really depends on what you're doing.
the__alchemist 4y ago
FYSA I upvoted this for teaching me that cool and useful expression!

Cyph0n 4y ago

For most use cases, I agree. But Rust is a better option when you also need one or more of the following: a) tight control over allocations b) deterministic performance c) strong data race protection d) zero overhead C interop (e.g., processing audio using ffmpeg)

steveklabnik 4y ago

It depends on what you mean by “optimal.” For many cases, sure, it’s not an issue, but Go has a big runtime that needs to exist. And its expectations mean that C FFI is not zero overhead, which is why you see so many pure Go packages, but isn’t appropriate in many of Rust’s use cases, which require zero overhead.

deleted 4y ago
[deleted]
otterley 4y ago
I agree - however, once you cross the border into C linkage/FFI, you’re losing both Go’s and Rust’s safety features. That seems like a wash to me. Besides, people are doing a splendid job writing pure Go libraries. It helps that Go has some fantastic observability tooling to help performance-minded engineers minimize unnecessary heap allocations. Finally, the Go runtime just isn’t that big. A few megabytes, I think. That’s well below the noise floor for most server environments, and it’s far smaller than, say, a Python or Java runtime.
- steveklabnik 4y ago
  Yes, you're not wrong. I have gotten some threads crossed; I forgot this one is about the server side context. Yes, these sorts of things are often less of an issue than in other contexts. Sometimes it still matters though. Just really depends on what you're doing.

the__alchemist 4y ago

FYSA I upvoted this for teaching me that cool and useful expression!