Sylvain Kerkour writes about Rust, security, and server-side development, including SQLite tuning, SIMD, and embedded work.
HN commenters point to his SQLite-for-servers post as a useful explanation of settings, and praise his writing on async Rust in embedded work.
Firm disagree.
Sylvain Kerkour described the problems Rust faces by having a limited standard library:
"The time has come for Rust to graduate from a shadow employment program in Big Tech companies to a programming language empowering the masses of engineers (and not just "programmers") wanting to build efficient and robust sfotware.
What crypto library should we use? ring, RustCrypto, rust-crypto (don't use it!), boring, aws-lc-s or openssl?
Which HTTP framework? actix-web, axum, dropshot or hyper?
What about a time library? time, chrono or jiff (how I'm even supposed to find this one)?
You get it, if you are not constantly following the latest news, your code is already technical debt before it's even written. Fragmentation is exhausting.
I just looked at the dependencies of a medium-sized project I'm working on, and we have 5+ (!) different crpyto libraries: 2 different versions of ring, aws-lc-rs, boring, and various libraries from RustCrypto. All of this because our various dependencies have picked a different one for their own cryptographic usage. This is insane, first because it introduces a lot of supply chain attack entry points, but also because there is no way that we will audit all of them"
Source: https://kerkour.com/rust-stdx
My moderate-sized Rust web service project requires 587 third-party crates which seems ridiculous.
Fortunately, cargo makes it easy to manage the dependencies, but unfortunately I don't know how well supported or maintained the…
This is kind of missing the point. I can only speak for the company that sponsors LiteFS (I don't think any edge computing companies put 'otoolep up to doing rqlite, for instance). We love Postgres. Most of our users use Postgres. And Postgres works fine in edge/backhaul configurations; companies were doing geographically distributed Postgres read replicas long, long before we came around. That's where we got the idea.
The idea of LiteFS is:
* Most apps are read-heavy, and some of them are overwhelmingly read-heavy.
* If you're read-heavy and can thus get away with it, there's a pretty significant performance win in replacing the networked n-tier architecture with SQLite, because Postgres round trips add up over the lifecycle of any given request.
* In fact, that's so much the case that --- as Richard Hipp has been pointing out for over a decade --- you can blow off the N+1 problem and just write natural queries.
I think Ben Johnson would be the first to tell you that LiteFS isn't a perfect fit for every application. We have systems that use both Postgres and LiteFS.
Meanwhile, you have to dig to find it on our web page! It's an open source project that works everywhere Linux does. Dial back the cynicism a bit! :)
A plug here for:
https://kerkour.com/sqlite-for-servers
Same author, and one of the best SQLite articles ever.
https://www.jendrikillner.com/tags/weekly - Graphics Programming weekly
https://halisavakis.com/category/technically-art - Technically Art weekly
https://us17.campaign-archive.com/home/?u=ac8ab0580c321574fe178a646&id=466256ba5a - Blender Guru Newsletter
https://twitter.com/search?q=Creative%20Code%20News%20(from%3AsableRaph)%20filter%3Alinks%20-filter%3Areplies&src=typed_query&f=live - Creative Code News
rarely:
https://tympanus.net/codrops/collective - Codrops - web design news, resources
https://speckyboy.com/?s=Weekly+News - Speckyboy - designers news
https://kerkour.com/tags/newsletter - Kerkour - favorite links
https://habr-com.translate.goog/ru/search/?q=%D0%B4%D0%B0%D0%B9%D0%B4%D0%B6%D0%B5%D1%81%D1%82&target_type=posts&order=date&_x_tr_sl=ru&_x_tr_tl=en - habr ru - various technical weekly news
bookmarked:
https://www.datascienceweekly.org/newsletters - Data Science Weekly
https://this-week-in-rust.org - This Week in Rust
https://www.fightaging.org/archives - Fight Aging
> Serve Stale Content While Revalidating (Not Working as Expected)
> This is the only thing that I was not able to figure out.
For good reason, because (at the last time I tried this earlier this year) Cloudflare documents stale-while-revalidate as if it's supported [1], but it isn't [2], [3].
Cloudflare instead has a different behaviour [4], [5] which helps in some circumstances but not all.
I use Fastly's free CDN plan to get round this.
1. https://developers.cloudflare.com/cache/concepts/revalidation/
2. https://community.cloudflare.com/t/support-for-stale-while-revalidate/496788
3. https://community.cloudflare.com/t/when-will-cloudflare-fully-support-stale-while-revalidate-with-asynchronous-background-revalidation/287764/8
4. https://kerkour.com/cloudflare-stale-while-revalidate
5. https://stackoverflow.com/questions/48124415/does-cloudflare-support-stale-while-revalidate
Location: Europe (GMT timezone)
Remote: Yes (exclusively)
Technologies: Go, Rust, VueJS, Typescript, VueJS
GitHub: https://github.com/skerkour
Blog: https://kerkour.com
Résumé/CV: Upon request
Email: sylvain.kerkour at gmail.com
----------------------------
After an attempt to launch my startup, I'm now looking for new technical challenges and to help make other people's lives better at the same time.
In the past years I have designed and implemented a Machine Learning service (automatic product recognition), an end-to-end encrypted app, a security automation platform and APIs / Single page apps.
I love open source and manage a moderately successful newsletter about it: https://kerkour.com
----------------------------
How can I help you?
Technically SQLite can only have 1 writer at any given moment, but it can appear like it works across multiple writers and let it serialize the calls for you.
By default SQLite will not do what you want out of the box. You have to turn on some feature flags(PRAGMA) to get it to behave for you. You need WAL mode, etc read:
* https://kerkour.com/sqlite-for-servers * https://zeroclarkthirty.com/2024-10-19-sqlite-database-is-locked
My larger question is why multiprocessing? this looks like an IO heavy workload, not CPU bound, so python asyncio or python threads would probably do you better.
multiprocessing is when your resource hog is CPU(probably 1 python process per CPU), not IO bound.