HackerTrans
TopNewTrendsCommentsPastAskShowJobs

tison

no profile record

Submissions

Show HN: Bsize yet Another Byte Size Crate

github.com
2 points·by tison·16 dni temu·0 comments

Show HN: Macro-template, table-driven code generation for Rust

github.com
2 points·by tison·22 dni temu·0 comments

A cloud-native database should be as elastic as the cloud itself

scopedb.io
3 points·by tison·6 miesięcy temu·2 comments

Apache DataSketches Rust 0.2.0: A library of stochastic streaming algorithms

docs.rs
2 points·by tison·6 miesięcy temu·0 comments

Show HN: Logforth, A versatile and extensible Rust logging framework

github.com
1 points·by tison·7 miesięcy temu·0 comments

Foyer 0.21.0 is out: Hybrid in-memory and disk cache in Rust

github.com
2 points·by tison·7 miesięcy temu·0 comments

Show HN: Async version for Rust std::sync and more

github.com
1 points·by tison·7 miesięcy temu·0 comments

StackSafe: Taming Recursion in Rust Without Stack Overflow

fast.github.io
1 points·by tison·9 miesięcy temu·0 comments

A new database solution for trading off between rigid schemas and no schema mess

scopedb.io
1 points·by tison·9 miesięcy temu·0 comments

comments

tison
·6 miesięcy temu·discuss
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.
tison
·6 miesięcy temu·discuss
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
  }
.. to handle a nullable value while `Valid = false && String = something` is by defined invalid but .. quite hard to explain. (Go has no sum type in this aspect)
tison
·6 miesięcy temu·discuss
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
·6 miesięcy temu·discuss
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.
tison
·9 miesięcy temu·discuss
Rust's Future is somehow like move semantics in C++, where you may leave a Future in an invalid state after it finishes. Besides, Rust adopts a stackless coroutine design, so you need to maintain the state in your struct if you would like to implement a poll-based async structure manually.

These are all common traps. And now cancellations in async Rust are a new complement to state management in async Rust (Futures).

When I'm developing the mea (Make Easy Async) [1] library, I document the cancel safety attribute when it's non-trivial.

Additionally, I recall [2] an instance where a thoughtless async cancellation can disrupt the IO stack.

[1] https://github.com/fast/mea

[2] https://www.reddit.com/r/rust/comments/1gfi5r1/comment/luido...