Matt Sh writes about C programming style, Redis internals, job searching, and his experiences as a software engineer.
HN commenters link his C style guide as being covered by CS:APP, and discuss his "$220k/year intern" story and Redis data structure posts.
but struggle when a lot of inserts and updates need to happen.
I ran across this with Redis recently. Redis has an internal data structure called ziplist that's a doubly linked list with no pointers. It just uses byte offsets to the next element, so all elements are in one contiguous block of memory. It's great because you can store a lot of values compactly without needing 1 to 5 pointers (8 to 40 bytes) overhead per element in your data structure.
But, a problem shows up when you want to insert or delete items. Every insert or delete requires expanding or shrinking the entire solid-chunk-of-memory allocation, which isn't the fastest thing in the world when your allocation is large. Also, inserting into the HEAD requires copying the _entire_ ziplist up exactly one element position because the block of your memory layout just changed.
So, obviously these things are useful, but their usefulness degrades as your solid blocks of memory hit cache limits. Everything is super fast when your entire ziplist fits in L1, still about the same in L2, worse in L3, and horrible if your ziplist grows any larger.
But, what can we do? We can fix the entire problem by creating a traditional linked lists of solid memory block ziplists. Now, each ziplist can remain small (8 KB to 16 KB), and when we grow bigger, we just cut a new ziplist, pointer-attach it to the previous ziplist, and now we have a minimal-pointer, high-locality data structure with unlimited growth potential without…
https://www.learn-c.org/
If you have lots of time: https://hal.inria.fr/hal-02383654
If you can't be bothered reading a whole book: https://matt.sh/howto-c
Exercises: https://www.codestepbystep.com/problem/list/c and https://exercism.org/tracks/c
Once you have syntax and basic algorithms down well, watch this, the only 2 hour YouTube video I'll ever recommend: https://m.youtube.com/watch?v=443UNeGrFoM
Both r/cprogramming and r/C_programming are active, also full of lazy students trying to get people to do their homework. If you come by, describe your problem well with code. Say you're learning for yourself, not for school.
Together C & C++ is a good Discord if you prefer live chat: https://discord.gg/tccpp
To the OP: I'm certain you're an experienced and seasoned programmer, but your CV (on your website: https://matt.sh/files/a-resume/resume.html) is an example of how not to write one. It's a wall of text and fluff, with too much focus on fanciness and design. I hire and interview people all the time, and your CV leaves me with zero sense of the impact of your work - only with the fact that you've done a bunch of stuff over the years...
"Designed & Built a Redis Replacement", "nobody really wants to buy it when free worse performing choices exist". Give me a break...
C, to me, requires a lot of discipline about good coding style and conventions. I personally like that a lot, even though, of course, it sometimes causes one to shoot oneself in the foot. But, and I can't point to exactly why, I don't think I want to change anything.
Maybe Rust or something new will come along sometime soon to fix all the issues that exist with C.
Oh, and for those who haven't seen it, there was a cool guide to writing neat, modern C on here a few months ago.
https://matt.sh/howto-c
Worth a read in my opinion.
Cassandra is optimized for write heavy workloads, inverse to MySQL. It also effortlessly scales horizontally and is designed to do so. The use case is clear and definitely different than that of MySQL.
As for the second point, you can store the JSON data in a Redis "hash" datatype: https://matt.sh/introduction-to-redis-data-types
Although MySQL also supports in-memory KV storage with (nearly?) constant time lookups (http://dev.mysql.com/doc/refman/5.7/en/innodb-adaptive-hash.html), I think Redis is a bit easier to partition.
It's absurd. He has no concept of market rates (and frankly I'm unsurprised that he's not getting hired if his expectations are this out of whack).
His resume even confirms this[0], because he seemingly thinks the appropriate level at FAANG would be L10 which is extremely rare. There is a 0% chance that his experience would level him that high.
The entire article can be chocked up to a massively inflated sense of entitlement.
[0] https://matt.sh/files/a-resume/resume.html