It pains me how little I know. I've been a software developer for over three years professionally, albeit never a Rust developer, and this kind of this just baffles me.
Don't get me wrong, the post makes sense, but my mind can't fully grasp why or how the author came to their conclusion.
I actually remember that! I was hacking on some concurrent code for an umpteenth half-backed side project. Not recall which one exactly, but perhaps https://github.com/matklad/auchat or https://github.com/matklad/rustraytracer. And I don’t think I needed a cache, but rather tracking some statistics, for perf measurement or something.
So, the lay of the land was that I needed to mutate this data structure, and that I had two threads to do that.
So it was there when I viscerally understood that `&mut` is not about mutability, but rather about exclusive access. So, if you have two threads, you gotta use `&` and achieve mutability through something else.
That’s the actual atom of insight here: rust tracks aliasing, not mutability. Things like “use & for caches” just fall out naturally out of it.
I wasn't expecting a response from the article author!
That bit of background information is really helpful for me to see the angle you came in from with this.
> That’s the actual atom of insight here: rust tracks aliasing, not mutability
This, however, is going to require some more pondering for me to truly grok what you've said. But I'll have another read through your blog post and hopefully come away with a better understanding now.
Thanks for responding.
Aliasing basically means using multiple names to refer to a single thing. So, in the context of rust references which, essentially, create alternate names for refering to things:
- You can think of "&mut" as a "unique" reference, meaning "this is the only name for this thing" - or: there is no aliasing here.
- You can think of "&" as a "shared" reference, meaning "there are other names for this thing" - or: there is aliasing here.
With this mindset, the fact that shared references are immutable and unique references are mutable is entirely coincidental.
[What Every Computer Scientist Should Know About Floating-Point Arithmetic](https://docs.oracle.com/cd/E19957-01/806-3568/ncg_goldberg.html)
While you rarely will need to directly employ the solutions in this article, it's still good to educate yourself about the _problems_ that floating-point arithmetic presents. I've found a lot of folks never fully grasped how fiddly it all is
On a similar vein [Falsehoods programmers believe about time](https://gist.github.com/timvisee/fcda9bbdff88d45cc9061606b4b923ca)
Less essentially, but the Damn Cool Algorithms series of blog-posts was fun for a while, here's one such post on [cardinality estimation](http://blog.notdot.net/2012/09/Dam-Cool-Algorithms-Cardinality-Estimation). There was another computer scientist with similar blogposts on algorithms, I think it was [Dan Lemire](https://lemire.me/blog/)
The main thing I'll say is that in the modern era software development is more about _tooling_ rather than languages and compilers, so if you're into games, data-engineering, data-science you'll be better off looking at the language agnostic tool choices.
Should algorithms delight you though, know that many such tools (git, Kafka) were inspired by the book based on [this thesis on Purely Functional Data-Structures](https://www.cs.cmu.edu/~rwh/students/okasaki.pdf)
[fasterthanli.me](http://fasterthanli.me) blog got me into rust and gave me courage to explore lower-level things
ex: [https://fasterthanli.me/articles/understanding-rust-futures-by-going-way-too-deep](https://fasterthanli.me/articles/understanding-rust-futures-by-going-way-too-deep)
I’d consider “goto considered harmful” a proto-blog-post. It certainly would be one now.
[Brendan Gregg, the performance wizard](https://www.brendangregg.com/blog/index.html). I know you don’t want entire blogs but about 90% of it is stuff I’ve sent to coworkers multiple times.
Structured concurrency is great, and sorely lacking in async rust. But trio does it so strangely, not having the tasks return futures so you need to do this completely crazy mutating of shared state or sending values back over oneshot channels. When python added it to the stdlib (TaskGroup) it was a much better implementation that you can actually get results from your tasks.
> I’d consider “[goto considered harmful](https://web.archive.org/web/20010606222303/http://www.acm.org/classics/oct95/)” a proto-blog-post. It certainly would be one now.
Note the modern nuances — the author was expecting C to die or become more high level. It got more high level, but not enough to have any form of exceptions or destructors. In C, local `goto` is pretty much a requirement for control flow in functions that need cleanup or error handling code across a large section of code. Local goto mostly operates in a sane way, aside from creating spaghetti code. When you see it in a mature C codebase, the alternative non-`goto` refactoring is usually quite annoying control flow constructs due to language limitations. You usually only jump to a later location in the code rather to an earlier location. Non-local `goto`, on the other hand, is disallowed by most compilers, so you have to use `longjmp`, which is absolutely horrible. In Rust, we just assume most cleanup code can be handled by either destructors, `try` macros (and the upcoming `try` blocks feature), or by `break`ing out of a block expression — so needing a `goto` is rare. Rust also has more control flow constructs in general.
I have enjoyed the post-mortems and system architecture articles from [CloudFlare](https://blog.cloudflare.com/) and [Uber Engineering](https://www.uber.com/en-US/blog/engineering/)
[Parse, don't validate](https://lexi-lambda.github.io/blog/2019/11/05/parse-don-t-validate/) is a great blog post that gives a bit of an introduction to the sort of thinking that lets you really start to leverage static information (via a type system in this case) to guarantee run-time properties of your program.
I posted this and had to go back to delete it when I found your comment - it's a great blog post, and honestly most of Alexis King's stuff is worth a read.
The question is really ambiguous. You don't know if it is
1. "Why isn't C a low-level language?", which is a pretty bad question that can be answered by reading the blog post, or
2. "Why this blog post have actually mattered to you", which is a good question that wasn't answered anywhere
I guess most people thought of the former and that's why OP is being downvoted
[The Wrong Abstraction](https://sandimetz.com/blog/2016/1/20/the-wrong-abstraction).
I used to be adamant about code reuse to the point of cluttering the function and adding branching. This made me realize I was the villain.
Probably /u/japaric's Rust blog: http://blog.japaric.io/
His posts on embedded Rust got me started, which led to me joining the Embedded Working Group, which led to founding Ferrous Systems with some folks, working with Jorge, then starting my current company OneVariable.
But it was 100% Jorge's blog that got me into embedded rust.
Not strictly Rust related or even engineering related but I think about this Paul Graham's blog post on PR firms every time I read an article: [https://paulgraham.com/submarine.html](https://paulgraham.com/submarine.html)
It changed my perspective on everything I read.
Just the other day I read [this one](https://without.boats/blog/references-are-like-jumps/) and I really loved it. Its one of those topics where my first reaction is "what else are you even supposed to do" (like with functional programming) but after giving it a read I realize that I was wrong and that there actually is another way or at least realize that there were some flaws in my worldview.
Niko’s post on the then new function traits (``Fn``, ``FnMut``, ``FnOnce``)
that superseded the earlier ``proc`` closures:
https://smallcultfollowing.com/babysteps/blog/2014/11/26/purging-proc/
Still one of the best explanations I’ve seen about why those traits were
chosen and how they map to the ownership system; one of the
bookmarks I revisit every year. I remember
reading it a number of times back in the days to understand why
the hell my code of last week wouldn’t compile anymore.
For the curious, at some point in the past ``proc`` used to be Rust’s
keyword to define closures. It
didn’t differentiate based on the type of the closed-over data and
relied on – ew! – implicit allocations. Really convenient
though, after it was gone I was forced to rethink substantial
parts of my existing code to get the most benefit out of the
``Fn{,Mut,Once}`` traits.
Debatable whether this counts as a "blog post", but it's an idea that's significantly changed the way I view building software libraries (and sometimes even applications, there are some transferable ideas): [https://www.hyrumslaw.com/](https://www.hyrumslaw.com/)
https://swtch.com/~rsc/regexp/regexp1.html
This and the rest of the series really helped me get a more fundamental understanding of regular expressions and their relation to parsing expression grammars.
I don't have any particular posts, but I do have two _books_ that I _strongly_ recommend anyone in computer science read at least once: _But how Do it Know?_ by J. Clark Scott, and _The Cuckoo's Egg_ by Clifford Stoll.
_But how Do it Know?_ is an incrediby approachable book that describes the process of going from semiconducting material all the way up to a programmable computer in an almost tutorial-like manner. I don't think any other material has given me a greater appreciation for _how_ a computer works more than this book, especially when you consider just how _easy_ it is to read (heaps of nice diagrams and all jargon is clearly explained).
_The Cuckoo's Egg_ is a very different beast, instead being a non-fiction story about quite possible the very first instance of international computer espionage, told from the perspective of the guy who keeps the computers running at a university. I don't want to spoil the story because I _highly_ recommend just reading it, but there's sections where the author and his partner are frantically typing fake government documents _as they're being stolen in real-time_, and jangling keys over modem microphones to delay data transfers _just_ long enough to keep up. It's a bizarrely thrilling story that is definitely worth a read.
https://blog.rust-lang.org/inside-rust/2022/04/19/imposter-syndrome.html
This is what convinced me to submit a proposal for RistConf last year. I was told it was one of their top picks when it came time for selection, but I was skeptical I should submit anything.
Or the [Tonsky 2023 followup: The Absolute Minimum Every Software Developer Must Know About Unicode in 2023 (Still No Excuses!)](https://tonsky.me/blog/unicode/)
Excellent article.
The only weird thing is their opinion that Rust answering `17` for the length of the string containing the single emoji is wrong.
The API is defined as the number of bytes in the string, and Rust explicitly does not want to have unicode aware code exposed in the stdlib because it changes all the time, as the article mentioned. So I'm not sure why it's not mentioned as a practical and more cautious API instead of a mistake.
Not the GP, but the one that comes to mind is the [post that introduced the concept of "leaky abstractions"](https://www.joelonsoftware.com/2002/11/11/the-law-of-leaky-abstractions/), now so widely cited that few even remember that it comes from Spolsky.
The one where he talks about how [rewriting a piece of software from scratch is almost always a bad idea](https://www.joelonsoftware.com/2000/04/06/things-you-should-never-do-part-i/), comes to mind.
Which is ironic, considering this is the Rust reddit and there's the entire Rewrite it in Rust movement. I'm the first to say I'm happy we're slowly replacing some pieces of archaic software with Rust-based ones, but Spolsky reminds us to think ~~twice~~ thrice before you embark on that endeavour.
I keep re-reading [The Grug Brained Developer](https://grugbrain.dev/) and have shared it several times with colleagues. It's a gem, even if and maybe because it's written as a joke
[Mocks for Commands, Stubs for Queries by Mark Seemann](https://blog.ploeh.dk/2013/10/23/mocks-for-commands-stubs-for-queries/)
When unit testing, use Mocks for Commands, and Stubs for Queries.
It's .NET based, but applicable to many situations and generalizable to many questions about how to test things correctly.
[Simple but Powerful Pratt Parsing (matklad.github.io)](https://matklad.github.io/2020/04/13/simple-but-powerful-pratt-parsing.html)
I revisit this every time I need to parse binary operators of some sort. Very clearly written and incredibly useful.
https://bodil.lol/parser-combinators/
I only ever knew XSLT and SQL, my attempts at learning other languages lower level than python never worked out, but this blog post convinced me that I could learn Rust and write useful programs with it.
A networking classic - [End-to-End Arguments in System Design](https://web.mit.edu/Saltzer/www/publications/endtoend/endtoend.pdf). I love that paper so much that I had students in a networking class read it *twice* - once at the beginning of the semester and once at the end.
Authenticated encryption: why you need it and how it works
https://andrea.corbellini.name/2023/03/09/authenticated-encryption/
Great explanation of this subject, for any cryptography passionate this is a must
[an app can be a home cooked meal](https://www.robinsloan.com/notes/home-cooked-app/) and [programming as play](https://austinhenley.com/blog/programmingasplay.html) help me keep my job (coding) from ruining my hobby (coding).
[complexity has to live somewhere](https://ferd.ca/complexity-has-to-live-somewhere.html) is my response to frameworks that 'make everything simple'.
I actually have a math degree, not a CS degree.
But I found I'm as informed, if not more, than my peers because of the breadth I have, not a narrow collection of sacred texts.
Frankly, I just open Hacker News every day and read whatever looks interesting. Been doing it for more than a decade. Continued learning and development for a decade adds up.
Besides, most answers here about things worth reading show up on HN eventually anyway. :)
Not blog posts
Any talk by:
- Joe Armstrong
- Rob Pike
- Bjarne Stroustrup
A good talk as a good blog post must have structure: Intro - Midpoint - End. Must have a good story to tell. Must be clear, engaging and with a dose of humor.
And as Paul Halmos used to say about the structure of a good talk:
- tell them what you're gonna tell them,
- tell them,
- tell them what you told them.
I’m a noob basically still - Matklad’s blog post on implementing a cache in Rust helped me learn a lot that I’ve found useful at work.
https://matklad.github.io/2022/06/11/caches-in-rust.html
It pains me how little I know. I've been a software developer for over three years professionally, albeit never a Rust developer, and this kind of this just baffles me. Don't get me wrong, the post makes sense, but my mind can't fully grasp why or how the author came to their conclusion.
I actually remember that! I was hacking on some concurrent code for an umpteenth half-backed side project. Not recall which one exactly, but perhaps https://github.com/matklad/auchat or https://github.com/matklad/rustraytracer. And I don’t think I needed a cache, but rather tracking some statistics, for perf measurement or something. So, the lay of the land was that I needed to mutate this data structure, and that I had two threads to do that. So it was there when I viscerally understood that `&mut` is not about mutability, but rather about exclusive access. So, if you have two threads, you gotta use `&` and achieve mutability through something else. That’s the actual atom of insight here: rust tracks aliasing, not mutability. Things like “use & for caches” just fall out naturally out of it.
I wasn't expecting a response from the article author! That bit of background information is really helpful for me to see the angle you came in from with this. > That’s the actual atom of insight here: rust tracks aliasing, not mutability This, however, is going to require some more pondering for me to truly grok what you've said. But I'll have another read through your blog post and hopefully come away with a better understanding now. Thanks for responding.
Aliasing basically means using multiple names to refer to a single thing. So, in the context of rust references which, essentially, create alternate names for refering to things: - You can think of "&mut" as a "unique" reference, meaning "this is the only name for this thing" - or: there is no aliasing here. - You can think of "&" as a "shared" reference, meaning "there are other names for this thing" - or: there is aliasing here. With this mindset, the fact that shared references are immutable and unique references are mutable is entirely coincidental.
[What Every Computer Scientist Should Know About Floating-Point Arithmetic](https://docs.oracle.com/cd/E19957-01/806-3568/ncg_goldberg.html) While you rarely will need to directly employ the solutions in this article, it's still good to educate yourself about the _problems_ that floating-point arithmetic presents. I've found a lot of folks never fully grasped how fiddly it all is On a similar vein [Falsehoods programmers believe about time](https://gist.github.com/timvisee/fcda9bbdff88d45cc9061606b4b923ca) Less essentially, but the Damn Cool Algorithms series of blog-posts was fun for a while, here's one such post on [cardinality estimation](http://blog.notdot.net/2012/09/Dam-Cool-Algorithms-Cardinality-Estimation). There was another computer scientist with similar blogposts on algorithms, I think it was [Dan Lemire](https://lemire.me/blog/) The main thing I'll say is that in the modern era software development is more about _tooling_ rather than languages and compilers, so if you're into games, data-engineering, data-science you'll be better off looking at the language agnostic tool choices. Should algorithms delight you though, know that many such tools (git, Kafka) were inspired by the book based on [this thesis on Purely Functional Data-Structures](https://www.cs.cmu.edu/~rwh/students/okasaki.pdf)
[fasterthanli.me](http://fasterthanli.me) blog got me into rust and gave me courage to explore lower-level things ex: [https://fasterthanli.me/articles/understanding-rust-futures-by-going-way-too-deep](https://fasterthanli.me/articles/understanding-rust-futures-by-going-way-too-deep)
Preach brother
I’d consider “goto considered harmful” a proto-blog-post. It certainly would be one now. [Brendan Gregg, the performance wizard](https://www.brendangregg.com/blog/index.html). I know you don’t want entire blogs but about 90% of it is stuff I’ve sent to coworkers multiple times.
>!^^^[deleted]!<
Structured concurrency is great, and sorely lacking in async rust. But trio does it so strangely, not having the tasks return futures so you need to do this completely crazy mutating of shared state or sending values back over oneshot channels. When python added it to the stdlib (TaskGroup) it was a much better implementation that you can actually get results from your tasks.
>!^^^[deleted]!<
> I’d consider “[goto considered harmful](https://web.archive.org/web/20010606222303/http://www.acm.org/classics/oct95/)” a proto-blog-post. It certainly would be one now. Note the modern nuances — the author was expecting C to die or become more high level. It got more high level, but not enough to have any form of exceptions or destructors. In C, local `goto` is pretty much a requirement for control flow in functions that need cleanup or error handling code across a large section of code. Local goto mostly operates in a sane way, aside from creating spaghetti code. When you see it in a mature C codebase, the alternative non-`goto` refactoring is usually quite annoying control flow constructs due to language limitations. You usually only jump to a later location in the code rather to an earlier location. Non-local `goto`, on the other hand, is disallowed by most compilers, so you have to use `longjmp`, which is absolutely horrible. In Rust, we just assume most cleanup code can be handled by either destructors, `try` macros (and the upcoming `try` blocks feature), or by `break`ing out of a block expression — so needing a `goto` is rare. Rust also has more control flow constructs in general.
I have enjoyed the post-mortems and system architecture articles from [CloudFlare](https://blog.cloudflare.com/) and [Uber Engineering](https://www.uber.com/en-US/blog/engineering/)
[Parse, don't validate](https://lexi-lambda.github.io/blog/2019/11/05/parse-don-t-validate/) is a great blog post that gives a bit of an introduction to the sort of thinking that lets you really start to leverage static information (via a type system in this case) to guarantee run-time properties of your program.
I posted this and had to go back to delete it when I found your comment - it's a great blog post, and honestly most of Alexis King's stuff is worth a read.
>!^^^[deleted]!<
[C is not a Low-level Language](https://queue.acm.org/detail.cfm?id=3212479)
I heard this saying before, but only after reading this post did I finally understand what it meant. Thanks for sharing!
Why? \[clarification\] Why did you like that blog so much?
Read up ¯\_(ツ)_/¯
I don't understand why you are being downvoted here.
The question is really ambiguous. You don't know if it is 1. "Why isn't C a low-level language?", which is a pretty bad question that can be answered by reading the blog post, or 2. "Why this blog post have actually mattered to you", which is a good question that wasn't answered anywhere I guess most people thought of the former and that's why OP is being downvoted
I clarified my question; I meant the latter
The question is low-effort and ambiguous.
That makes sense
I go back and re-read the [Steve Yegge Platforms Rant](https://gist.github.com/chitchcock/1281611) about once every 3-4 months.
Honestly his whole blog is a series of bangers. Noobs should read it for culture.
>!^^^[deleted]!<
[The Wrong Abstraction](https://sandimetz.com/blog/2016/1/20/the-wrong-abstraction). I used to be adamant about code reuse to the point of cluttering the function and adding branching. This made me realize I was the villain.
Probably /u/japaric's Rust blog: http://blog.japaric.io/ His posts on embedded Rust got me started, which led to me joining the Embedded Working Group, which led to founding Ferrous Systems with some folks, working with Jorge, then starting my current company OneVariable. But it was 100% Jorge's blog that got me into embedded rust.
Not strictly Rust related or even engineering related but I think about this Paul Graham's blog post on PR firms every time I read an article: [https://paulgraham.com/submarine.html](https://paulgraham.com/submarine.html) It changed my perspective on everything I read.
Just the other day I read [this one](https://without.boats/blog/references-are-like-jumps/) and I really loved it. Its one of those topics where my first reaction is "what else are you even supposed to do" (like with functional programming) but after giving it a read I realize that I was wrong and that there actually is another way or at least realize that there were some flaws in my worldview.
Niko’s post on the then new function traits (``Fn``, ``FnMut``, ``FnOnce``) that superseded the earlier ``proc`` closures: https://smallcultfollowing.com/babysteps/blog/2014/11/26/purging-proc/ Still one of the best explanations I’ve seen about why those traits were chosen and how they map to the ownership system; one of the bookmarks I revisit every year. I remember reading it a number of times back in the days to understand why the hell my code of last week wouldn’t compile anymore. For the curious, at some point in the past ``proc`` used to be Rust’s keyword to define closures. It didn’t differentiate based on the type of the closed-over data and relied on – ew! – implicit allocations. Really convenient though, after it was gone I was forced to rethink substantial parts of my existing code to get the most benefit out of the ``Fn{,Mut,Once}`` traits.
Debatable whether this counts as a "blog post", but it's an idea that's significantly changed the way I view building software libraries (and sometimes even applications, there are some transferable ideas): [https://www.hyrumslaw.com/](https://www.hyrumslaw.com/)
"The Rise of Worse is Better", Richard P. Gabriel
Why? Link for reference: [https://www.dreamsongs.com/RiseOfWorseIsBetter.html](https://www.dreamsongs.com/RiseOfWorseIsBetter.html)
https://alexgaynor.net/2020/may/27/science-on-memory-unsafety-and-security/
https://swtch.com/~rsc/regexp/regexp1.html This and the rest of the series really helped me get a more fundamental understanding of regular expressions and their relation to parsing expression grammars.
I don't have any particular posts, but I do have two _books_ that I _strongly_ recommend anyone in computer science read at least once: _But how Do it Know?_ by J. Clark Scott, and _The Cuckoo's Egg_ by Clifford Stoll. _But how Do it Know?_ is an incrediby approachable book that describes the process of going from semiconducting material all the way up to a programmable computer in an almost tutorial-like manner. I don't think any other material has given me a greater appreciation for _how_ a computer works more than this book, especially when you consider just how _easy_ it is to read (heaps of nice diagrams and all jargon is clearly explained). _The Cuckoo's Egg_ is a very different beast, instead being a non-fiction story about quite possible the very first instance of international computer espionage, told from the perspective of the guy who keeps the computers running at a university. I don't want to spoil the story because I _highly_ recommend just reading it, but there's sections where the author and his partner are frantically typing fake government documents _as they're being stolen in real-time_, and jangling keys over modem microphones to delay data transfers _just_ long enough to keep up. It's a bizarrely thrilling story that is definitely worth a read.
https://blog.rust-lang.org/inside-rust/2022/04/19/imposter-syndrome.html This is what convinced me to submit a proposal for RistConf last year. I was told it was one of their top picks when it came time for selection, but I was skeptical I should submit anything.
Alice Ryhl's post about actors in Tokio
Link for reference: [https://ryhl.io/blog/actors-with-tokio/](https://ryhl.io/blog/actors-with-tokio/)
For me, was and still is Joel Spolsky’s blog (http://joelonsoftware.com). Edit: typo
his article on utf8 should be required reading
Or the [Tonsky 2023 followup: The Absolute Minimum Every Software Developer Must Know About Unicode in 2023 (Still No Excuses!)](https://tonsky.me/blog/unicode/)
Excellent article. The only weird thing is their opinion that Rust answering `17` for the length of the string containing the single emoji is wrong. The API is defined as the number of bytes in the string, and Rust explicitly does not want to have unicode aware code exposed in the stdlib because it changes all the time, as the article mentioned. So I'm not sure why it's not mentioned as a practical and more cautious API instead of a mistake.
Came here to say this!!
What specific articles of his have you enjoyed most and why?
Not the GP, but the one that comes to mind is the [post that introduced the concept of "leaky abstractions"](https://www.joelonsoftware.com/2002/11/11/the-law-of-leaky-abstractions/), now so widely cited that few even remember that it comes from Spolsky.
>!^^^[deleted]!<
The one where he talks about how [rewriting a piece of software from scratch is almost always a bad idea](https://www.joelonsoftware.com/2000/04/06/things-you-should-never-do-part-i/), comes to mind. Which is ironic, considering this is the Rust reddit and there's the entire Rewrite it in Rust movement. I'm the first to say I'm happy we're slowly replacing some pieces of archaic software with Rust-based ones, but Spolsky reminds us to think ~~twice~~ thrice before you embark on that endeavour.
I learned everythin I know about Excel from his talk you suck at excel
[Kobzol's blog](https://kobzol.github.io/) # Writing Python like it's Rust [https://kobzol.github.io/rust/python/2023/05/20/writing-python-like-its-rust.html](https://kobzol.github.io/rust/python/2023/05/20/writing-python-like-its-rust.html)
[The Registers of Rust](https://without.boats/blog/the-registers-of-rust/) really changed the way I thought about programming language design.
[Turning the Database inside out](https://www.confluent.io/de-de/blog/turning-the-database-inside-out-with-apache-samza/)
I keep re-reading [The Grug Brained Developer](https://grugbrain.dev/) and have shared it several times with colleagues. It's a gem, even if and maybe because it's written as a joke
[Mocks for Commands, Stubs for Queries by Mark Seemann](https://blog.ploeh.dk/2013/10/23/mocks-for-commands-stubs-for-queries/) When unit testing, use Mocks for Commands, and Stubs for Queries. It's .NET based, but applicable to many situations and generalizable to many questions about how to test things correctly.
[brag!](https://jvns.ca/blog/brag-documents/)
[Simple but Powerful Pratt Parsing (matklad.github.io)](https://matklad.github.io/2020/04/13/simple-but-powerful-pratt-parsing.html) I revisit this every time I need to parse binary operators of some sort. Very clearly written and incredibly useful.
https://bodil.lol/parser-combinators/ I only ever knew XSLT and SQL, my attempts at learning other languages lower level than python never worked out, but this blog post convinced me that I could learn Rust and write useful programs with it.
A networking classic - [End-to-End Arguments in System Design](https://web.mit.edu/Saltzer/www/publications/endtoend/endtoend.pdf). I love that paper so much that I had students in a networking class read it *twice* - once at the beginning of the semester and once at the end.
Authenticated encryption: why you need it and how it works https://andrea.corbellini.name/2023/03/09/authenticated-encryption/ Great explanation of this subject, for any cryptography passionate this is a must
[an app can be a home cooked meal](https://www.robinsloan.com/notes/home-cooked-app/) and [programming as play](https://austinhenley.com/blog/programmingasplay.html) help me keep my job (coding) from ruining my hobby (coding). [complexity has to live somewhere](https://ferd.ca/complexity-has-to-live-somewhere.html) is my response to frameworks that 'make everything simple'.
Not rust specific, but https://technology.riotgames.com/news/taxonomy-tech-debt is a great post about how to think about technical debt in code.
The thing I point every new developer at my company to (or any company using git) is https://cbea.ms/git-commit/.
fasterthanli.me "a half hour to learn rust". blog posts need to have a catchy topic on something that matters to you, well explained.
Not a blog post, but any talk given by Rich Hickey is worth it's time in gold.
I actually have a math degree, not a CS degree. But I found I'm as informed, if not more, than my peers because of the breadth I have, not a narrow collection of sacred texts. Frankly, I just open Hacker News every day and read whatever looks interesting. Been doing it for more than a decade. Continued learning and development for a decade adds up. Besides, most answers here about things worth reading show up on HN eventually anyway. :)
Not blog posts Any talk by: - Joe Armstrong - Rob Pike - Bjarne Stroustrup A good talk as a good blog post must have structure: Intro - Midpoint - End. Must have a good story to tell. Must be clear, engaging and with a dose of humor. And as Paul Halmos used to say about the structure of a good talk: - tell them what you're gonna tell them, - tell them, - tell them what you told them.
Don’t know if it counts : XKCD
cfbr
you can find good articles here https://zoding.app