218 results for "":
Learning Nix from the bottom up
Remember the snapshot we made allll the way back in Part 1? Now’s the time to use it.
Well, make sure you’ve committed and pushed all your changes, but when you’re ready, let’s go back in time to before we installed anything catscii-specific in our VM.
This should emulate the experience of a colleague onboarding onto the project well enough!
(I didn’t actually use VirtualBox’s snapshot feature for this, I actually set up a Ubuntu 22.10 VM on another computer entirely, but the effect should be much the same).
A Rust match made in hell
I often write pieces that showcase how well Rust can work for you, and how it can let you build powerful abstractions, and prevents you from making a bunch of mistakes.
If you read something like Some mistakes Rust doesn’t catch in isolation, it could seem as if I had only nice things to say about Rust, and it’s a perfect little fantasy land where nothing ever goes wrong.
Making a dev shell with nix flakes
In the previous chapter, we’ve made a nix “dev shell” that contained the fly.io command-line utility, “flyctl”.
That said, that’s not how I want us to define a dev shell.
Our current solution has issues. I don’t like that it has import <nixpkgs>.
Which version of nixpkgs is that? The one you’re on? Who knows what that is.
Also, we haven’t really seen a mechanism to use .nix files from elsewhere.
Rust 2020: Funding
Blog posts that praise Rust are many but funding is generally in short supply.
If even a small percentage of the money Rust saves companies was put back into the ecosystem it would help secure the future of the platform tremendously.
Multiple sources of funding
It is unreasonable going forward to expect the same handful of companies to provide all the funding.
Day 1 (Advent of Code 2020)
I was not planning on doing anything specific this December, but a lot of folks around me (on Twitter, at work) have chosen this Advent of Code to pick up Rust, and I’ve got big FOMO energy, so, let’s see where this goes.
I’ll be doing all of these on Linux, so there may be some command-line tools involved, but don’t worry about them - the code itself should run on all platforms no problem.
Safer memory-mapped structures
Welcome back to the “Making our own executable packer” series, where digressions are our bread and butter.
Last time, we implemented indirect functions in a no-libc C program. Of course, we got lost on the way and accidentally implemented a couple of useful elk-powered GDB functions - with only the minimal required amount of Python code.
The article got pretty long, and we could use a nice distraction. And I have just the thing! A little while ago, a member of the Rust compiler team stumbled upon this series and gave me some feedback.
Some mistakes Rust doesn't catch
I still get excited about programming languages. But these days, it’s not so much because of what they let me do, but rather what they don’t let me do.
Ultimately, what you can with a programming language is seldom limited by the language itself: there’s nothing you can do in C++ that you can’t do in C, given infinite time.
As long as a language is turing-complete and compiles down to assembly, no matter the interface, it’s the same machine you’re talking to. You’re limited by… what your hardware can do, how much memory it has (and how fast it is), what kind of peripherals are plugged into it, and so on.
ELF relocations
The last article, Position-independent code, was a mess. But who could blame us? We looked at the world, and found it to be a chaotic and seemingly nonsensical place. So, in order to blend in, we had to let go of a little bit of sanity.
The time has come to reclaim it.
Short of faulty memory sticks, memory locations don’t magically turn from
0x0 into valid addresses. Someone is doing the turning, and we’re going to
find out who, if it takes the rest of the series.
Abstracting away correctness
I’ve been banging the same drum for years: APIs must be carefully designed.
This statement doesn’t resonate the same way with everyone. In order to really understand what I mean by “careful API design”, one has to have experienced both ends of the spectrum.
But there is a silver lining - once you have experienced “good design”, it’s really hard to go back to the other kind. Even after acknowledging that “good design” inevitably comes at a cost, whether it’s cognitive load, compile times, making hiring more challenging, etc.