3 ms·

I don't know specifically why that is for this specific project, but in general Go has GC and bounds checking that slow things down.

masklinn 9y ago
Rust bounds-checks indexes by default (there exist indexing methods which bypass that, they are unsafe).
- dvirsky 9y ago
  Another thing I can think of - Go's interface mechanism overhead is usually significant, and I've also found that the networking stack is slow compared to raw C. When I brought this up on the user group a few years ago I was told that this is a fair price to pay for Go's safety and concurrency abstractions. I pretty much agree actually. I won't be necessarily writing a database in Go, but for robust and fast application services it's very very good.
  - kasey_junk 9y ago
    The channel primitives are also slow and it is really painful to write fast alternatives as you have to resort to code gen.
    - dvirsky 9y ago
      yes, and they are heavily used under the hood in the standard library, for things like http connection pooling.
  - gtirloni 9y ago
    Re: databases in Go, I remember seeing a lot of these concerns a few years ago but it looks like many people found a way to make it work: https://github.com/avelino/awesome-go/blob/master/README.md#database https://github.com/avelino/awesome-go/blob/master/README.md#...
    - dvirsky 9y ago
      I actually experimented with a "database" of sorts, a redis compatible server with replication, persistence and an extendable API. It was okay as a toy project but never came close to redis performance, even when it only did ping/pong. Plus it had the issue of stop-the-world GC that was how Go worked back then. Not sure how well it would work today.
  - masklinn 9y ago
    > Another thing I can think of - Go's interface mechanism overhead is usually significant Yes that's a more likely culprit, interfaces mean dynamic dispatch, outside of hand-rolled codegen I don't think Go can statically dispatch abstractions.
- ue_ 9y ago
  If by "bounds-checks indexes" you mean "panics when given an out of bounds index, even if it's a compile time constant" then sure. I'm not sure why people talk about Rust being safe when this sort of thing happens and it can't catch it at compile time. At least C compilers have sanitizers that pick up things like that.
  - bjz_ 9y ago
    > I'm not sure why people talk about Rust being safe when this sort of thing happens and it can't catch it at compile time. "Safe" as in "memory safe". Panicking is better than allowing one to read into that memory. I would prefer panic-safe, but we might have to wait for a new dependently typed systems lang for that.
  - masklinn 9y ago
    > If by "bounds-checks indexes" you mean "panics when given an out of bounds index, even if it's a compile time constant" then sure. Er yes, it's safe as in memory-safe, as in an OOB will not own the entire application let alone machine. Error on OOB is a very common (if not quite universal) strategy — and incidentally also the one Go uses, the other primary one being returning null (which would be difficult in a language where most types are not nullable). If you want panic-safe, use .get.
    - ue_ 9y ago
      How is an error differentiated from a panic? Can a panic as is caused by the OOB situation I described be recovered from, or is it necessarily fatal?
      - masklinn 9y ago
        > How is an error differentiated from a panic? I'm using them for the same purpose, but panic is rust-specific whereas error is not. > Can a panic as is caused by the OOB situation I described be recovered from, or is it necessarily fatal? Technically it can be recovered from[0] but practically it usually should not be. Panics should not be used as an exceptions system. An OOB panic is basically a failed assertion. If OOB is a normal part of your operations, use a panic-safe access method (e.g. slice::get[1] which returns an Option<&T>) [0] https://doc.rust-lang.org/std/panic/fn.catch_unwind.html https://doc.rust-lang.org/std/panic/fn.catch_unwind.html [1] https://doc.rust-lang.org/std/primitive.slice.html#method.get https://doc.rust-lang.org/std/primitive.slice.html#method.ge...
- Ar-Curunir 9y ago
  Using standard practices like iterators elides the bounds check, because the iterator is guaranteed to never go out of bounds.

masklinn 9y ago

Rust bounds-checks indexes by default (there exist indexing methods which bypass that, they are unsafe).

dvirsky 9y ago
Another thing I can think of - Go's interface mechanism overhead is usually significant, and I've also found that the networking stack is slow compared to raw C. When I brought this up on the user group a few years ago I was told that this is a fair price to pay for Go's safety and concurrency abstractions. I pretty much agree actually. I won't be necessarily writing a database in Go, but for robust and fast application services it's very very good.
- kasey_junk 9y ago
  The channel primitives are also slow and it is really painful to write fast alternatives as you have to resort to code gen.
  - dvirsky 9y ago
    yes, and they are heavily used under the hood in the standard library, for things like http connection pooling.
- gtirloni 9y ago
  Re: databases in Go, I remember seeing a lot of these concerns a few years ago but it looks like many people found a way to make it work: https://github.com/avelino/awesome-go/blob/master/README.md#database https://github.com/avelino/awesome-go/blob/master/README.md#...
  - dvirsky 9y ago
    I actually experimented with a "database" of sorts, a redis compatible server with replication, persistence and an extendable API. It was okay as a toy project but never came close to redis performance, even when it only did ping/pong. Plus it had the issue of stop-the-world GC that was how Go worked back then. Not sure how well it would work today.
- masklinn 9y ago
  > Another thing I can think of - Go's interface mechanism overhead is usually significant Yes that's a more likely culprit, interfaces mean dynamic dispatch, outside of hand-rolled codegen I don't think Go can statically dispatch abstractions.
ue_ 9y ago
If by "bounds-checks indexes" you mean "panics when given an out of bounds index, even if it's a compile time constant" then sure. I'm not sure why people talk about Rust being safe when this sort of thing happens and it can't catch it at compile time. At least C compilers have sanitizers that pick up things like that.
- bjz_ 9y ago
  > I'm not sure why people talk about Rust being safe when this sort of thing happens and it can't catch it at compile time. "Safe" as in "memory safe". Panicking is better than allowing one to read into that memory. I would prefer panic-safe, but we might have to wait for a new dependently typed systems lang for that.
- masklinn 9y ago
  > If by "bounds-checks indexes" you mean "panics when given an out of bounds index, even if it's a compile time constant" then sure. Er yes, it's safe as in memory-safe, as in an OOB will not own the entire application let alone machine. Error on OOB is a very common (if not quite universal) strategy — and incidentally also the one Go uses, the other primary one being returning null (which would be difficult in a language where most types are not nullable). If you want panic-safe, use .get.
  - ue_ 9y ago
    How is an error differentiated from a panic? Can a panic as is caused by the OOB situation I described be recovered from, or is it necessarily fatal?
    - masklinn 9y ago
      > How is an error differentiated from a panic? I'm using them for the same purpose, but panic is rust-specific whereas error is not. > Can a panic as is caused by the OOB situation I described be recovered from, or is it necessarily fatal? Technically it can be recovered from[0] but practically it usually should not be. Panics should not be used as an exceptions system. An OOB panic is basically a failed assertion. If OOB is a normal part of your operations, use a panic-safe access method (e.g. slice::get[1] which returns an Option<&T>) [0] https://doc.rust-lang.org/std/panic/fn.catch_unwind.html https://doc.rust-lang.org/std/panic/fn.catch_unwind.html [1] https://doc.rust-lang.org/std/primitive.slice.html#method.get https://doc.rust-lang.org/std/primitive.slice.html#method.ge...
Ar-Curunir 9y ago
Using standard practices like iterators elides the bounds check, because the iterator is guaranteed to never go out of bounds.