tison
Joined 4 years ago
Karma
431
Submissions
122
Member since
Dec 17
Recent submissions
Comment · 9 months ago
We have discussed these in previous blogs:
1. Insight In No Time: https://www.scopedb.io/blog/insight-in-no-time
2. Manage Data in Petabytes for an Observability Platform: https://www.scopedb.io/blog/manage-observability-data-in-pet...
That is, Snowflake follows a traditional data warehouse workflow that requires extenral ETL process to load data into the warehouse. Some of our customers did researching of Snowflake and noticed that their event streaming ingestion can not fit in Snowflake's stage-based loading model - they need real-time insights end-to-end.
Apart from this major downside, about leveraging S3 as a primary storage, Snowflake doesn't have adaptive indexes, and its performance would be significantly degraded as data grows and queries involve a large range of data + multi-condition filters when the simple minmax index can't help.
Comment · 10 months ago
FWIW, here is a general discussion about error handling in Rust and my comment to compare it with Go's/Java's flavor: https://github.com/apache/datasketches-rust/issues/27#issuec...
That said, I can live with "if err != nil", but every type has a zero value is quite a headache to handle: you would fight with nil, typed nil, and zero value.
For example, you need something like:
type NullString struct {
String string
Valid bool // Valid is true if String is not NULL
}
Comment · 10 months ago
I think they are almost compatible.
`thiserror` helps you define the error type. That error type can then be used with `anyhow` or `exn`. Actually, we have been using thiserror + exn for a long time, and it works well. While later we realize that `struct ModuleError(String)` can easily implement Error without thiserror, we remove thiserror dependency for conciseness.
`exn` can use `anyhow::Error` as its inner Error. However, one may use `Exn::as_error` to retrieve the outermost error layer to populate anyhow.
I ever consider `impl std::error::Error` for `exn::Exn,` but it would lose some information, especially if the error has multiple children.
`error-stack` did that at the cost of no more source:
* https://docs.rs/error-stack/0.6.0/src/error_stack/report.rs....
* https://docs.rs/error-stack/0.6.0/src/error_stack/error.rs.h...
Comment · 10 months ago
This is the pull request of this post: https://github.com/fast/fast.github.io/pull/12
See comments like https://github.com/fast/fast.github.io/pull/12#discussion_r2...
Quote my comment in the other thread:
> That said, exn benefits something from anyhow: https://github.com/fast/exn/pull/18, and we feed back our practices to error-stack where we come from: https://github.com/hashintel/hash/issues/667#issuecomment-33...
> While I have my opinions on existing crates, I believe we can share experiences and finally converge on a common good solution, no matter who made it.
Board Member & Incubator Mentor @ The Apache Software Foundation
I develop and maintain open-source software: https://github.com/tisonkun