5 ms·

You're describing qualities that are meaningless to a database user. A Rust implementation of PostgreSQL, with its runtime checks, would almost certainly be slo

You're describing qualities that are meaningless to a database user. A Rust implementation of PostgreSQL, with its runtime checks, would almost certainly be slower than the existing implementation. So a Rust port is a non-starter. Database users don't care about your syntactic sugar, that you find manual memory management a "scary land" due to background in managed languages, or how many contributors you have. Speaking of which, the PostgreSQL project is healthy and has many, many contributors. And while we're discussing developer productivity, I can't even imagine the build time of a Rust port. What's annoying about OP's email is that they clearly did no research on the matter. You can find many discussions on the list about "upgrading" to C++, and there has been much wringing of hands. The last I heard, it sounded like a faction was considering having the project build with a C++ compiler rather than a C compiler for better type checks and as a step on that path.

stymaar 10y ago
> A Rust implementation of PostgreSQL, with its runtime checks, would almost certainly be slower than the existing implementation. So a Rust port is a non-starter. Wait, which runtime checks are you talking about ? This is a recurring FUD we often see on HN about Rust and I'd like to clarify this point. IIRC, there is no mandatory runtime check in idiomatic Rust except UTF8 validation for strings[0]. There is no overflow checks on numbers, and no bounds checking when using iterators[1]. Another known overhead is the default use of siphash in hashmaps for DoS prevention[2], but this is not really a «runtime check». Do you have anything else in mind ? > Speaking of which, the PostgreSQL project is healthy and has many, many contributors. Indeed, and as I said, I'm not advocating for a port of PostgreSQL in Rust. But for other projects that suffer from a lack of attention[3], it could be a good move. > And while we're discussing developer productivity, I can't even imagine the build time of a Rust port. touché, but compile time is one of the biggest focus of the Rust core team atm, so I'm confident things will improve in 2017 :) [0]: which can be worked around if need be by using &[u8] instead of &str (see: https://news.ycombinator.com/item?id=13268051 https://news.ycombinator.com/item?id=13268051 from /u/burntsushi) [1]: there are bounds checking when you access array elements through indexes, but most of the time you don't do that since iterators are great. If you really need to, and this have a performance impact, you can opt-out the bound checking in unsafe block. [2]: But this is opt-out by using a different hash function, if you use your hashmap in a non adversarial environment. [3]: like librsvg which was chronically under-maintained.
- thesmallestcat 10y ago
  [1] is great. Rephrased, "there isn't runtime bounds checking, unless you use the language. But you can opt out in an `unsafe` block." OK? So we're back to the usual Rust argument: At least your unsafe code is greppable. And I don't think any competent C or C++ developer considers that a worthy tradeoff when it comes with a more complex, constantly evolving language, far less mindshare, slow builds without solutions (unlike C++), and so on. Regarding [2], I think it's safe to consider any software that takes input as operating in a hostile environment.
  - tupshin 10y ago
    That is an extreme mis-characterization of stymaar's excellent summary. in short, there are no runtime checks for iterating through an array, and since the general case of random access to an array can't be safe (without dependent typing), that is the one place the runtime checks are automatically added, and even there you can opt out of them. It is easy to get C equivalent speed with far more safety. You are spreading FUD, indeed.
  - solidsnack9000 10y ago
    Which runtime checks are you concerned about, exactly? Just array indexing? It would be interesting to see your criticism fleshed out. I am not sure your criticism will amount to anything if array access is it, though. Posrgres is full of custom data structures and macros as it is. StringInfo and stuff like that -- they are not just "using the language", writing nice simple C code. Probably because databases really push you to use advanced techniques in places.
- ue_ 10y ago
  >there are bounds checking when you access array elements through indexes I wish we didn't need bounds checking; the problem could be solved with dependently typed languages. Unfortunately Rust just panics when you access out of bounds, and doesn't warn you at compile time. Rust isn't really all that impressive.
  - tupshin 10y ago
solidsnack9000 10y ago
> You're describing qualities that are meaningless to a database user. This is an old strawman. No one is asking the users to write Rust and a change in developer tooling doesn't by itself change things for users. The question is whether tools help developers help users.

stymaar 10y ago

> A Rust implementation of PostgreSQL, with its runtime checks, would almost certainly be slower than the existing implementation. So a Rust port is a non-starter. Wait, which runtime checks are you talking about ? This is a recurring FUD we often see on HN about Rust and I'd like to clarify this point. IIRC, there is no mandatory runtime check in idiomatic Rust except UTF8 validation for strings[0]. There is no overflow checks on numbers, and no bounds checking when using iterators[1]. Another known overhead is the default use of siphash in hashmaps for DoS prevention[2], but this is not really a «runtime check». Do you have anything else in mind ? > Speaking of which, the PostgreSQL project is healthy and has many, many contributors. Indeed, and as I said, I'm not advocating for a port of PostgreSQL in Rust. But for other projects that suffer from a lack of attention[3], it could be a good move. > And while we're discussing developer productivity, I can't even imagine the build time of a Rust port. touché, but compile time is one of the biggest focus of the Rust core team atm, so I'm confident things will improve in 2017 :) [0]: which can be worked around if need be by using &[u8] instead of &str (see: https://news.ycombinator.com/item?id=13268051 https://news.ycombinator.com/item?id=13268051 from /u/burntsushi) [1]: there are bounds checking when you access array elements through indexes, but most of the time you don't do that since iterators are great. If you really need to, and this have a performance impact, you can opt-out the bound checking in unsafe block. [2]: But this is opt-out by using a different hash function, if you use your hashmap in a non adversarial environment. [3]: like librsvg which was chronically under-maintained.

thesmallestcat 10y ago
[1] is great. Rephrased, "there isn't runtime bounds checking, unless you use the language. But you can opt out in an `unsafe` block." OK? So we're back to the usual Rust argument: At least your unsafe code is greppable. And I don't think any competent C or C++ developer considers that a worthy tradeoff when it comes with a more complex, constantly evolving language, far less mindshare, slow builds without solutions (unlike C++), and so on. Regarding [2], I think it's safe to consider any software that takes input as operating in a hostile environment.
- tupshin 10y ago
  That is an extreme mis-characterization of stymaar's excellent summary. in short, there are no runtime checks for iterating through an array, and since the general case of random access to an array can't be safe (without dependent typing), that is the one place the runtime checks are automatically added, and even there you can opt out of them. It is easy to get C equivalent speed with far more safety. You are spreading FUD, indeed.
- solidsnack9000 10y ago
  Which runtime checks are you concerned about, exactly? Just array indexing? It would be interesting to see your criticism fleshed out. I am not sure your criticism will amount to anything if array access is it, though. Posrgres is full of custom data structures and macros as it is. StringInfo and stuff like that -- they are not just "using the language", writing nice simple C code. Probably because databases really push you to use advanced techniques in places.
ue_ 10y ago
>there are bounds checking when you access array elements through indexes I wish we didn't need bounds checking; the problem could be solved with dependently typed languages. Unfortunately Rust just panics when you access out of bounds, and doesn't warn you at compile time. Rust isn't really all that impressive.
- tupshin 10y ago

solidsnack9000 10y ago

> You're describing qualities that are meaningless to a database user. This is an old strawman. No one is asking the users to write Rust and a change in developer tooling doesn't by itself change things for users. The question is whether tools help developers help users.