mkornaukhov
mkornaukhov on Hacker News
Posted by
mkornaukhov on Monday October 05, 2026 @10:16AM
from the serenedb.com dept.
Posted by
mkornaukhov on Monday October 05, 2026 @10:09AM
from the blog.lizzie.io dept.
Posted by
mkornaukhov on Monday October 05, 2026 @10:08AM
from the duckdb.org dept.
We've been working on remote search indexing in our project and it works pretty good. since we are building a Postgres-compatible database, everything is pure SQL. I'd say we could join forces if you're up for it.
Good job! Interesting reading
Posted by
mkornaukhov on Thursday February 12, 2026 @08:45AM
from the blog.serenedb.com dept.
Posted by
mkornaukhov on Thursday February 12, 2026 @07:32AM
from the blog.serenedb.com dept.
Posted by
mkornaukhov on Thursday December 18, 2025 @06:09AM
from the serenedb.com dept.
I do write mostly async code, too.
There are several ~~problems~~ subtleties that make usage of Rust async hindered IMHO.
- BoxFuture. It's used almost everywhere. It means there are no chances for heap elision optimization.
- Verbosity. Look at this BoxFuture definition: `BoxFuture<'a, T> = Pin<Box<dyn Future<Output = T> + Send + 'a>>;`. It's awful. I do understand what's Pin trait, what is Future trait, what's Send, lifetimes and dynamic dispatching. I *have to* know all these not obvious things just to operate with coroutines in my (possibly single threaded!) program =(
- No async drop and async trait in stdlib (fixed not so long ago)
I am *not* a hater of Rust async system. It's a little simpler and less tunable than in C++, but more complex than in Golang. Just I cannot say Rust's async approach is a good enough trade-off while a plethora of the decisions made in the design of the language are closest to the silver bullet.
> I’m happy with how Rust turned out.
I agree, with the possible exception of perplexing async stuff.
Better tell me how to make the compiler not fool me!
I would say that your comment is an addition to mine, and I think so too. This is another reason for the popularity of github.
As for me, this does not negate the convenient things that I originally wrote about.
IMHO, the main advantage of github is that it is an ecosystem. This is a well-thought-out Swiss knife: a pioneering (but no longer new) PR system, convenient issues, as well as a well-formed CI system with many developed actions and free runners. In addition, it is best to use code navigation simply in a web browser. You write code, and almost everything works effortlessly. Having a sponsorship system is also great, you don't have to search for external donation platforms and post weird links in your profile/repository.
All in one, that's why developers like it so much. The obsession with AI makes me nervous, but the advantages still outweigh, as for me, the average developer. For now.
It is strange that road deaths have been compared in the past, but protection from air pollution has been discussed since 2026. It is noteworthy that, according to IQAir, the air in the United States is less polluted than in most EU countries.
I've recently understood how RSA works and thought it was a cool achievement.
But this article with "basic" math...
Not so enjoyable for just a dev =)
That's good news. I hope this will encourage the industry to use the Zig language (and its creators to release version 1.0).
Billie is lucky to have such a dexterous owner!
Similarly, the CEO couldn't resist the outstanding optimization of memory and execution speed!
> Allocate all necessary memory during startup and avoid dynamic memory allocation after initialization.
Absolutely not an ultimatum advice, even harmful in most cases. Just measure you memory usage and don't rely on and avoid external OOM handler.
> handlig c++ types with gdb can be a nightmare and you either develop your own gdb glue code or write c-like c++.
That's why better to use lldb and it's scripts.
> I think the idea of using only a small subset of C++ is interesting but it ignores the problem that many people have, you don't have the time to implement your own STL so you just use the STL.
Yeah, agree. It's just much easier to take a "framework" (or frameworks) where all the main problems solved: convenient parallelism mechanisms, scheduler, reactor, memory handling, etc. So it's turning out you kinda writing in your own ecosystem that's not really different from another language, just in C++ syntax.
Yeah, agree. But even in case of 8 hour downtime (it's almost 99% SLA) it isn't beneficial for really small firms.