Readit Newstison commented on Stop Forwarding Errors, Start Designing Them fast.github.io/blog/stop-... · Posted by u/andylokandy
Many Rust programmers despise Go's "if err != nil" pattern, but that pattern actually forces you to think about errors and "design" them to give meaningful messages, either by wrapping them (if the underlying error is expected to provide userful information), or by creating a one from scratch.
It may be easier to just add the "?" operator everywhere (and we are lazy and will mostly do what is easier), but it often leads to problem explained in the article.
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
}
tison commented on Stop Forwarding Errors, Start Designing Them fast.github.io/blog/stop-... · Posted by u/andylokandy
Exn looks very interesting, but to be actionable we need a compatibility layer with thiserror and anyhow since most are using it right now. Moving the goalpost a little we mostly need a core rust solution otherwise your error handling stops at the first library you use that doesn't use exn.
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...
tison commented on Stop Forwarding Errors, Start Designing Them fast.github.io/blog/stop-... · Posted by u/andylokandy
Be warned: LLM writing. Lots of negative parallelisms.
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.
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.