What are the other goals of the project?
Personally, I'd love to see an easier-to-manage system with replication considered as a first-class feature rather than bolted on at the end.
11–15 of 15 posts
What are the other goals of the project?
Personally, I'd love to see an easier-to-manage system with replication considered as a first-class feature rather than bolted on at the end.
I almost mixed this up with Apache Arrow DataFusion for a second: https://github.com/apache/arrow-datafusion
Curious what the motivation behind rebuilding it in rust is, versus contributing more to Clickhouse? Obviously memory safety is a big one, but is that the only reason? What are the other goals of the project? Personally, I'd love to see an easier-to-manage system with replication considered as a first-class feature rather than bolted on at the end.
2. Couldn't agree with you more with easier-to-manage as a first-class feature, but some times easier-to-manage is built on stability, that's what datafuse is trying to do.
Curious what the motivation behind rebuilding it in rust is, versus contributing more to Clickhouse? Obviously memory safety is a big one, but is that the only reason? What are the other goals of the project? Personally, I'd love to see an easier-to-manage system with replication considered as a first-class feature rather than bolted on at the end.
Well. 1. With the improvement of the rust ecosystem, using rust has made database development faster and easy, for example datafuse use the tokio to implement the pipeline https://github.com/datafuselabs/datafuse/tree/master/fuseque... . 2. Couldn't agree with you more with easier-to-manage as a first-class feature, but some times easier-to-manage is built on stability, that's what datafuse is trying to do.
p.s. Please don't add in-process DNS caching ;-)