Hacker News: func25

New comment by func25 in "How VictoriaLogs Stores Your Logs in a Columnar Layout"

func25 — Mon, 29 Jun 2026 00:23:32 +0000

Vertically on a single machine, the two are quite similar, both fan work out across all CPU cores.

The different is on scaling out.

ClickHouse scales by making you describe the cluster yourself. You decide how many shards to split the data into, how many copies (replicas) each shard keeps, which row goes to which shard. The copies are kept in sync by a consensus system ClickHouse Keeper. This is flexible but also more works on operators.

VictoriaLogs takes the opposite bet. When logs come in, the inserter just spreads them across all storage nodes on its own, so there is no sharding key for you to design. When a query runs, the selector asks every storage node in parallel and merges the results. There is no consensus system at all. If you want high availability, you run 2 independent clusters and send your logs to both, rather than having the database copy data internally. So this is simpler and less learning curve. See more here https://victoriametrics.com/blog/victorialogs-architecture-b...

Constructor Best Practices in Rust

func25 — Tue, 19 Aug 2025 15:23:54 +0000

Article URL: https://blog.cuongle.dev/p/constructor-best-practices-in-rust

Comments URL: https://news.ycombinator.com/item?id=44952648

Points: 1

# Comments: 0

VictoriaLogs Practical Ingestion Guide for Message, Time and Streams

func25 — Sun, 17 Aug 2025 10:49:14 +0000

Article URL: https://victoriametrics.com/blog/victorialogs-concepts-message-time-stream/index.html

Comments URL: https://news.ycombinator.com/item?id=44930625

Points: 60

# Comments: 17

Send/Sync Secret Separates Professional from Amateur Rust Developers

func25 — Mon, 11 Aug 2025 08:12:57 +0000

Article URL: https://blog.cuongle.dev/p/this-sendsync-secret-separates-professional-and-amateur

Comments URL: https://news.ycombinator.com/item?id=44861831

Points: 3

# Comments: 0

New comment by func25 in "Go Sync.Cond, the Most Overlooked Sync Mechanism"

func25 — Sun, 22 Sep 2024 02:40:44 +0000

The article could be a bit misleading, as it focuses on the act of one goroutine signaling another. That’s why it emphasizes 'for its signaling to work.'

> "In theory, a condition variable like sync.Cond doesn’t have to be tied to a lock for its signaling to work."

It basically separates signaling from lock management, but not about removing the entire need for a mutex. From a pure technical POV, developers can totally handle locking and unlocking the mutex themselves to protect the process of dealing with shared resources, so it's not about technical limitation.

Including a mutex in sync.Cond and having it automatically unlock the mutex in cond.Wait() is an engineering decision that enforces us, developers, to call Lock() on the mutex beforehand and follow the pattern to avoid panic.