Is there anything of this sort but for golang and python?
Readit NewsBeazley's Concurrency From the Ground Up is one of my favorite tech talks ever: In about 45 minutes he builds an async framework using generators, while live coding in an emacs screen that shows only about 20 lines and without syntax highlighting, and not breaking stride with his commentary and engaging with the audience.
It's 8 years old, but definitely worth a watch: https://www.youtube.com/watch?v=MCs5OvhV9S4
the love of programming and engineering .. this is what motivated me at first place to do CS
_ank_it commented on Ask HN: Resources for CS and software eng for a sharp middle school dropout? · Posted by u/vector_spaces
Try this website: https://teachyourselfcs.com
_ank_it commented on Ask HN: How are you feeling about software engineering in 2023? · Posted by u/mbm
Given all the advancements in the field of AI, I want to program more. Go more for low level programming. Talk to the hardware
_ank_it commented on Ask HN: What are the most eye-opening textbooks you have ever read? · Posted by u/debanjan16
I'm not a C engineer, but I think I have an interesting recommendation to consider.
Since you are already familiar with other languages, you obviously don't need to know the basics of C. The basics are the same everywhere. Instead, you'd likely want to build that mindset on how to build good software with C.
I suggest you read other people's code and try to deep dive into the whys.
I heard Redis is a well-written software.
git clone https://github.com/redis/redis.git
git log –reverse
git checkout ed9b544e...
When you read a book, the most interesting parts are usually after all the theory is explained at the beginning. Somewhere in the middle of the book they start showing you code samples and that's when things become really interesting.
What I like about the reverse git-log approach is that it immediately throws you into the middle section of the book. This approach is both fun and eye opening.
Good luck!
This. But for C++ and Python.
No dark mode?
The advantage of this approach is that it gives more control to the distro maintainers and the admins of the computer, taking that control away from the "upstream" maintainers of the software being packaged. For example the software being packaged cannot just call the library bar because bar is not at /usr/lib/bar.so like it is in most Linux distros -- it is at /nix/store/17813e8b97b84e0317813e8b97b84e03-bar/usr/lib/bar.so, but of course the software does not know that unless the person creating the Nix package (the packager) arranges for the software to know it (again sometimes by doing a search-and-replace on binaries).
If the upstream maintainer of foo thinks foo should link to version 6 of library bar, but you think it should link to version 5, NixOS makes it easier for you to arrange for foo to link to version 5 than most distros do (even if version 6 of bar is needed by other packages you have installed which you need to use at the same times as your using foo).
Note that if this separation of packages imposed by NixOS has any beneficial security properties, it is merely security through obscurity because there is nothing preventing a binary from covertly searching through the directory listing of /nix/store/ for the name of the library it wants to call. Nevertheless it turns out the be useful to seize some control away from upstream in this way even if technically upstream could seize the control back if it were willing to complicate the software to do so.
People, including the creator of Nix and NixOS (Dolstra), will tell you that NixOS's main advantage is "declarativeness" (which in the past Dolstra called "purity") or the fact that the compilation / building process is deterministic. I believe both positions (NixOS's advantage is declarativeness and the advantage is deterministic builds) are wrong. Specifically, I believe that although deterministic builds are useful, the separation of packages I described is much more useful to most users and prospective users of NixOS.
Another way to summarize it is that NixOS package maintainers routinely modify the software they are packaging to use less "ambient authority".