6 ms·

OT: I recently learned that the newer ETH client Parity is written in Rust and much faster than the older Go-based Geth ETH client. Guess it is due to a differ

OT: I recently learned that the newer ETH client Parity is written in Rust and much faster than the older Go-based Geth ETH client. Guess it is due to a different architecture and design which makes the client faster (e.g. chaindata is smaller) but does anyone know why they chose Rust instead of Go for the Parity client?

dvirsky 9y ago
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
> does anyone know why they chose Rust instead of Go for the Parity client? Maybe ask them? According to their FAQ (https://github.com/paritytech/parity/wiki#our-priorities https://github.com/paritytech/parity/wiki#our-priorities): > Minimise Moving Parts: While Rust is multi-paradigm, we aim to write intra-function logic in as functional a manner as possible. Mutability is avoided except where necessary for the algorithm or efficiency. > Minimum Footprint, Maximum Performance: Maximise references, minimise copying and holding copies. Rust makes it safe. When there are dynamic data structures, provide means for keeping them under control. > Reliability: Through Rust's language-level memory and thread guarantees and a disciplined approach to exception-handling we can state with a high degree of certainty that our code cannot crash, hang or bomb-out unexpectedly. But I can't tell you that's all of the story. In the original announcement thread on /r/ethereum, the main point of comparison was C++ rather than Go so ymmv.
pimeys 9y ago
I would think having better safety guarantees is a big reason. Rustc can detect data races, which I'd say it's very useful with an Ethereum client.
- dvirsky 9y ago
  Go can detect data races as well, not sure it's the reason. Probably performance.
  - dmit 9y ago
    Go may detect data races if your test suite triggers them and you opt in to use the race detector. Rust rejects programs with data races unless you opt out by explicitly marking code in question as unsafe. Quite a bit of a difference there.
tscs37 9y ago
The Geth client is still widely used as it's kind off the standard implementation of the Ethereum EVM and Node Mechanics. The Go based client isn't that much "older" either, both are actively developed and received some code overhauls. I've also found the go client's web3 console to be much more reliable and complete than Parity's.

dvirsky 9y ago

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

> does anyone know why they chose Rust instead of Go for the Parity client? Maybe ask them? According to their FAQ (https://github.com/paritytech/parity/wiki#our-priorities https://github.com/paritytech/parity/wiki#our-priorities): > Minimise Moving Parts: While Rust is multi-paradigm, we aim to write intra-function logic in as functional a manner as possible. Mutability is avoided except where necessary for the algorithm or efficiency. > Minimum Footprint, Maximum Performance: Maximise references, minimise copying and holding copies. Rust makes it safe. When there are dynamic data structures, provide means for keeping them under control. > Reliability: Through Rust's language-level memory and thread guarantees and a disciplined approach to exception-handling we can state with a high degree of certainty that our code cannot crash, hang or bomb-out unexpectedly. But I can't tell you that's all of the story. In the original announcement thread on /r/ethereum, the main point of comparison was C++ rather than Go so ymmv.

pimeys 9y ago

I would think having better safety guarantees is a big reason. Rustc can detect data races, which I'd say it's very useful with an Ethereum client.

dvirsky 9y ago
Go can detect data races as well, not sure it's the reason. Probably performance.
- dmit 9y ago
  Go may detect data races if your test suite triggers them and you opt in to use the race detector. Rust rejects programs with data races unless you opt out by explicitly marking code in question as unsafe. Quite a bit of a difference there.

tscs37 9y ago

The Geth client is still widely used as it's kind off the standard implementation of the Ethereum EVM and Node Mechanics. The Go based client isn't that much "older" either, both are actively developed and received some code overhauls. I've also found the go client's web3 console to be much more reliable and complete than Parity's.