Are they? To me it seems obvious that if one is seeking those emotions actively, then one will be disappointed or worse if they prove unattainable.
For whatever reason, be it psychological or physiological, it is clear that humans cannot maintain a perpetual high. The serotonin is expended, the stimulant wears off, unhealthy dependencies on emotional states are created. An even keel is worth any number of highs in my opinion. The goal should not be an emotion or a high-water mark, but rather to make progress. Progress is tangible, you can hang your hat on it and be proud of it, and most importantly it's available to you no matter how poor your circumstances or station in life are.
I was responding to somebody who made the claim that installing software leaves things "scattered all over the system". I simply pointed out that that is not true if you plan carefully. Additionally you can ensure that all users on a system have a basic set of paths enabeled in their profile (is the default PATH any more invasive than a default path + "/opt/bin"? These things are not insurmountable if you actually know what you are talking about and know the scope of your problem. These complaints are coming from people who are not actually interested in managing a system, but would rather be able to click a button in a gui and not have to understand anything of what is actually going on.
That being said compiling your own stuff in and of itself is not guaranteed to be a simple or "fun" task. It takes work and can lead to unexpected results: you immediately own anything that is custom on your system and become your own testing, debugging, and troubleshooting team. It isn't ideal.
I wonder if you could do most of this cryptographically. If you did, you could make a client that could do all of this peer-to-peer. I think you would just need the following to make a wide range of games (many popular ones, perhaps most?):
1. Client can produce a signature that it drew the k'th card from the deck for any k.
2. Client can produce a signature that the k'th card is X if it drew the k'th card.
3. Client can produce a signature that card X came from any arbitrary set of card indices containing k if it drew the k'th card. (This is the hardest one.) If it's easier, you could get most of this even restricting it to sets of cards that the client has drawn.
With just that, I bet you could make a protocol for most card games where no one can cheat, where the central server's role is only to give out information about k'th card one and only one time. Certainly it's enough for blackjack, most forms of poker, hearts, and go fish. Anyone have a game that would be difficult? Maybe one where hidden cards get passed from player to player.
You can get this in other languages too. For example, Flask (a Python web framework) has a fantastic debug-mode error page that totally changed the way that I think about web development. Any time an exception is thrown in a view function (and this includes the exceptions that you idiomatically throw for HTTP 4xx and 5xx errors) the debug-mode error page would have a stack trace (obviously), but also an interactive REPL that could be opened at any stack frame in that trace. It wasn't necessary all that often, but when it was, boy was it a fantastic way to work.
Not quite as automatic, but XDebug with the Codebug client gives you this exact functionality for PHP. Saved me many a headache over the past few years, and makes tracing data flow in a program I don't know as simple as it can be.
Calling log.debug() with and argument of `false` is a no-op? That sounds like someone bending the language to fit an idiom, because it doesn't sound like a sane API except that it enables this use case.
It is insane in an eager-evaluated calling context. You're not wrong. But in Lisp it's not insane at all to let a macro consume a parameter and yield a no-op. Think of how this plays with a JIT and having code that can dynamically switch between dev/QA/production behavior and performance profiles, just for one example.
Sequences in Postgres are updated even if a transaction is rolled back. It's pretty easy to see why that's important, especially when dealing with concurrent transactions.
You can't give out the same number to multiple transactions without causing a bunch of unique constraint violations. And you can't retroactively decrease a sequence number without affecting all the other transactions currently executing. You could in theory go back and plug in the gaps in a sequence, but it's more important to guarantee that a single thread of execution will always see increasing numbers than it is to guarantee that all numbers will eventually be handed out to a successful transaction.
I think you need to split the unsoundness bug, which happens because thread::scoped uses unsafe code, from the "you can write mem::forget in safe code" bug, which is arguably not a bug but is at least an enormous footgun waiting to happen.
When the footgun goes off in unsafe code in the standard library, you get use-after-free and memory unsoundness. When the footgun goes off in safe code written by mere humans, you leak arbitrary resources.