5 ms·

I posted this because I'm interested to hear from anyone using it - how has it worked out for you? I note it's written in C++ which is a bit of a surprise - I'

I posted this because I'm interested to hear from anyone using it - how has it worked out for you? I note it's written in C++ which is a bit of a surprise - I'd expected Rust or Golang. Interesting as well is is AGPL - licensing is always contentious: https://github.com/scylladb/scylla/blob/master/LICENSE.AGPL https://github.com/scylladb/scylla/blob/master/LICENSE.AGPL

deleted 5y ago
[deleted]
zinclozenge 5y ago
I think the main reason it's in C++ is because of its async executor, Seastar. There's a similar Rust project called Glommio but seems still very early.
- throwaway81523 5y ago
  Seastar is sort of a C++-ification of node.js. Now that C++20 has coroutines, I wonder if those could have been used instead of all that chained method stuff.
  - enedil 5y ago
    Seastar already uses coroutines, however coroutines without Seastar reactor (and all the utilities for IO) are useless by themselves. You still need a way to schedule what's being done when.
    - throwaway81523 5y ago
      Hmm ok I haven't looked at Seastar in a while, but it used to depend on Node-like control inversion where you'd pass an explicit lambda to each action, telling the action what to do next. That meant unwinding the handler for a given event into a bunch of nested lambdas. Coroutine would let you write them in a more traditional sequential style, where you'd have a return to the scheduler whenever something could block. Yes you have to write a layer of async io under everything, but that's how any OS works, more or less.
- biggestdummy 5y ago
  Glommio was created by Glauber Costa, one of the early contributors to Seastar (and Scylla). The resemblance between the two is not coincidence. https://glaubercosta-11125.medium.com/c-vs-rust-an-async-thread-per-core-story-28c4b43c410c https://glaubercosta-11125.medium.com/c-vs-rust-an-async-thr...
krapht 5y ago
Only on Hackernews would somebody be surprised that high-performance system software would be written in C++...
- masterof0 5y ago
  You read my mind. LOL. "Mr. Developer, can you please write your project in Rust, or __insert_your_meme_language_here__, or Javascript?"
  - ethelward 5y ago
    Fromthe mouth of CockraochDB's CTO: ‶So if we were starting at this point in time, I would take a hard look at Rust, and I imagine that we would pick it instead of C++.″
    - masterof0 5y ago
      It was a joke, to capture the sentiment here in HN. Rust is awesome, and most people know it. My point was that people will focus more often on which language is used, rather than the technical design, performance, etc...
    - fbernier 5y ago
      Wasn't that from the ScyllaDB CTO ?
      - ethelward 5y ago
        Indeed, you're right.
    - void_mint 5y ago
      Right, meaning, no, the CTO would not be "surprised" that C++ was a candidate for a high performance system. C++ is the defacto, and Rust would be a "new" option.
milesward 5y ago
We're using it with several customers: fast, reliable, straightforward.
enedil 5y ago
Quoting the interview with ScyllaDB CTO, Avi Kivity ( https://www.scylladb.com/2020/06/30/ask-me-anything-with-avi-kivity/ https://www.scylladb.com/2020/06/30/ask-me-anything-with-avi... ) > Q: Would you implement Scylla in Go, Rust or Javascript if you could? > Avi: Good question. I wouldn’t implement Scylla in Javascript. It’s not really a high-performance language, but I will note that Node.js and Seastar share many characteristics. Both are using a reactor pattern and designed for high concurrency. Of course the performance is going to be very different between the two, but writing code for Node.js and writing code for Seastar is quite similar. > Go also has an interesting take on concurrency. I still wouldn’t use it for something like Scylla. It is a garbage-collected language so you lose a lot of predictability, and you lose some performance. The concurrency model is great. The language lacks generics. I like generics a lot and I think they are required for complex software. I also hear that Go is getting generics in the next iteration. Go is actually quite close to being useful for writing a high-performance database. It still has the downside of having a garbage collector, so from that point-of-view I wouldn’t pick it. > If you are familiar with how Scylla uses the direct I/O and asynchronous I/O, this is not something that Go is great at right now. I imagine that it will evolve. So I wouldn’t pick Javascript or Go. > However, the other language you mentioned, Rust, does have all of the correct characteristics that Scylla requires. Precise control over what happens. It doesn’t have a garbage collector so it means that you have predictability over how much time your things take, like allocation. You don’t have pause times. And it is a well-designed language. I think it is better than C++ which we are currently using. So if we were starting at this point in time, I would take a hard look at Rust, and I imagine that we would pick it instead of C++. Of course, when we started Rust didn’t have the maturity that it has now, but it has progressed a long time since then and I’m following it with great interest. I think it’s a well-done language.
- robmccoll 5y ago
  I'd be careful with the idea of predictability and allocation. The best way to get predictabile performance is to avoid dynamic allocation altogether. The next best is to do your own allocation (slab-base per request, memory pools, etc.). General purpose dynamic memory management is a bin-packing problem (NP-hard).
jandrewrogers 5y ago
If you are building a database engine that strongly prioritizes performance, and Scylla does position itself that way, then C++ is the only practical choice today for many people, depending on the details. It isn't that C++ is great, though modern versions are pretty nice, but that it wins by default. Garbage collected languages like Golang and high-performance database kernels are incompatible because the GC interferes with core design elements of high-performance database kernels. In addition to a significant loss of performance, it introduces operational edge cases you don't have to deal with in non-GC languages. Rust has an issue unique to Rust in the specific case of high-performance database kernels. The internals of high-performance databases are full of structures, behaviors, and safety semantics that Rust's safety checking infrastructure is not designed to reason about. Consequently, to use Rust in a way that produces equivalent performance requires marking most of the address space as "unsafe". And while you could do this, Rust is currently less expressive than modern C++ for this type of code anyway, so it isn't ergonomic either. C++ is just exceptionally ergonomic for writing high-performance database kernels compared to the alternatives at the moment.
- staticassertion 5y ago
  > Rust has an issue unique to Rust in the specific case of high-performance database kernels. The internals of high-performance databases are full of structures, behaviors, and safety semantics that Rust's safety checking infrastructure is not designed to reason about. Consequently, to use Rust in a way that produces equivalent performance requires marking most of the address space as "unsafe". And while you could do this, Rust is currently less expressive than modern C++ for this type of code anyway, so it isn't ergonomic either. None of that sounds right to me. More likely the developers already know C++, there's already a lot of KV stores built in C++, and Rust is a relatively new player. Scylla was released in 2015, Rust hit 1.0 in 2015, seems obvious why Scylla didn't go with Rust. edit: Yep, from further down > So if we were starting at this point in time, I would take a hard look at Rust, and I imagine that we would pick it instead of C++. Of course, when we started Rust didn’t have the maturity that it has now, but it has progressed a long time since then and I’m following it with great interest. I think it’s a well-done language.
- robmccoll 5y ago

deleted 5y ago

[deleted]

zinclozenge 5y ago

I think the main reason it's in C++ is because of its async executor, Seastar. There's a similar Rust project called Glommio but seems still very early.

throwaway81523 5y ago
Seastar is sort of a C++-ification of node.js. Now that C++20 has coroutines, I wonder if those could have been used instead of all that chained method stuff.
- enedil 5y ago
  Seastar already uses coroutines, however coroutines without Seastar reactor (and all the utilities for IO) are useless by themselves. You still need a way to schedule what's being done when.
  - throwaway81523 5y ago
    Hmm ok I haven't looked at Seastar in a while, but it used to depend on Node-like control inversion where you'd pass an explicit lambda to each action, telling the action what to do next. That meant unwinding the handler for a given event into a bunch of nested lambdas. Coroutine would let you write them in a more traditional sequential style, where you'd have a return to the scheduler whenever something could block. Yes you have to write a layer of async io under everything, but that's how any OS works, more or less.
biggestdummy 5y ago
Glommio was created by Glauber Costa, one of the early contributors to Seastar (and Scylla). The resemblance between the two is not coincidence. https://glaubercosta-11125.medium.com/c-vs-rust-an-async-thread-per-core-story-28c4b43c410c https://glaubercosta-11125.medium.com/c-vs-rust-an-async-thr...

krapht 5y ago

Only on Hackernews would somebody be surprised that high-performance system software would be written in C++...

masterof0 5y ago
You read my mind. LOL. "Mr. Developer, can you please write your project in Rust, or __insert_your_meme_language_here__, or Javascript?"
- ethelward 5y ago
  Fromthe mouth of CockraochDB's CTO: ‶So if we were starting at this point in time, I would take a hard look at Rust, and I imagine that we would pick it instead of C++.″
  - masterof0 5y ago
    It was a joke, to capture the sentiment here in HN. Rust is awesome, and most people know it. My point was that people will focus more often on which language is used, rather than the technical design, performance, etc...
  - fbernier 5y ago
    Wasn't that from the ScyllaDB CTO ?
    - ethelward 5y ago
      Indeed, you're right.
  - void_mint 5y ago
    Right, meaning, no, the CTO would not be "surprised" that C++ was a candidate for a high performance system. C++ is the defacto, and Rust would be a "new" option.

milesward 5y ago

We're using it with several customers: fast, reliable, straightforward.

enedil 5y ago

Quoting the interview with ScyllaDB CTO, Avi Kivity ( https://www.scylladb.com/2020/06/30/ask-me-anything-with-avi-kivity/ https://www.scylladb.com/2020/06/30/ask-me-anything-with-avi... ) > Q: Would you implement Scylla in Go, Rust or Javascript if you could? > Avi: Good question. I wouldn’t implement Scylla in Javascript. It’s not really a high-performance language, but I will note that Node.js and Seastar share many characteristics. Both are using a reactor pattern and designed for high concurrency. Of course the performance is going to be very different between the two, but writing code for Node.js and writing code for Seastar is quite similar. > Go also has an interesting take on concurrency. I still wouldn’t use it for something like Scylla. It is a garbage-collected language so you lose a lot of predictability, and you lose some performance. The concurrency model is great. The language lacks generics. I like generics a lot and I think they are required for complex software. I also hear that Go is getting generics in the next iteration. Go is actually quite close to being useful for writing a high-performance database. It still has the downside of having a garbage collector, so from that point-of-view I wouldn’t pick it. > If you are familiar with how Scylla uses the direct I/O and asynchronous I/O, this is not something that Go is great at right now. I imagine that it will evolve. So I wouldn’t pick Javascript or Go. > However, the other language you mentioned, Rust, does have all of the correct characteristics that Scylla requires. Precise control over what happens. It doesn’t have a garbage collector so it means that you have predictability over how much time your things take, like allocation. You don’t have pause times. And it is a well-designed language. I think it is better than C++ which we are currently using. So if we were starting at this point in time, I would take a hard look at Rust, and I imagine that we would pick it instead of C++. Of course, when we started Rust didn’t have the maturity that it has now, but it has progressed a long time since then and I’m following it with great interest. I think it’s a well-done language.

robmccoll 5y ago
I'd be careful with the idea of predictability and allocation. The best way to get predictabile performance is to avoid dynamic allocation altogether. The next best is to do your own allocation (slab-base per request, memory pools, etc.). General purpose dynamic memory management is a bin-packing problem (NP-hard).

jandrewrogers 5y ago

If you are building a database engine that strongly prioritizes performance, and Scylla does position itself that way, then C++ is the only practical choice today for many people, depending on the details. It isn't that C++ is great, though modern versions are pretty nice, but that it wins by default. Garbage collected languages like Golang and high-performance database kernels are incompatible because the GC interferes with core design elements of high-performance database kernels. In addition to a significant loss of performance, it introduces operational edge cases you don't have to deal with in non-GC languages. Rust has an issue unique to Rust in the specific case of high-performance database kernels. The internals of high-performance databases are full of structures, behaviors, and safety semantics that Rust's safety checking infrastructure is not designed to reason about. Consequently, to use Rust in a way that produces equivalent performance requires marking most of the address space as "unsafe". And while you could do this, Rust is currently less expressive than modern C++ for this type of code anyway, so it isn't ergonomic either. C++ is just exceptionally ergonomic for writing high-performance database kernels compared to the alternatives at the moment.

staticassertion 5y ago
> Rust has an issue unique to Rust in the specific case of high-performance database kernels. The internals of high-performance databases are full of structures, behaviors, and safety semantics that Rust's safety checking infrastructure is not designed to reason about. Consequently, to use Rust in a way that produces equivalent performance requires marking most of the address space as "unsafe". And while you could do this, Rust is currently less expressive than modern C++ for this type of code anyway, so it isn't ergonomic either. None of that sounds right to me. More likely the developers already know C++, there's already a lot of KV stores built in C++, and Rust is a relatively new player. Scylla was released in 2015, Rust hit 1.0 in 2015, seems obvious why Scylla didn't go with Rust. edit: Yep, from further down > So if we were starting at this point in time, I would take a hard look at Rust, and I imagine that we would pick it instead of C++. Of course, when we started Rust didn’t have the maturity that it has now, but it has progressed a long time since then and I’m following it with great interest. I think it’s a well-done language.
robmccoll 5y ago