541 karma · joined June 21, 2021
> well, the majority who had political power anyway
You're making a massive assumption that this somehow equates to voters/the people.
A lot of it comes down to avoiding auto-piloting into a 50/50 distribution. Subconsciously, "random" means approaches 50/50 since that's how it works, right? I'm sure given enough time, it'll be able to predict me with >50% accuracy, but that's entirely okay. Random doesn't have to be fairly distributed. As long as it doesn't get to 100% then I still have personhood :^)
> No more undefined behavior.
"fixed"
This is just untrue.
It's certainly not ergonomic, but from what I can tell so far, `builtins.trace` and `builtins.traceVerbose` are about as good as it's gonna get. It quite literally lets you inspect any arbitrary Nix expression, but it's just such a friggin' hassle to wrap things with it & reevaluate just to do what literally any real debugger can do in two keystrokes.
> All around after ~16 months i think i'm finally done with Nix. It's Nickel or the highway for me. Not that i even love Nickel that much, but it's the bare bones of what Nix should have been in my view.
I'm curious. Have you messed around with Dhall? It's suspiciously similar to Nickel (even mentioned on their site), but it's been around longer so it's probably a bit more viable to actually make your config in Dhall. Dhall or Nickel, it'll still insanely janky and more trouble than it's worth. Personally, I've found that what's worked surprisingly well for me is just really focusing on building a good understanding of the Nix language in an effort to avoid needing to debug as much as possible. "Just don't write bugs" as the saying goes. I've been using Nix for a while, and I'm still loath to debug it.
In theory, this makes perfect sense and is a great way to amplify a more senior developer's impact compared to just coding "the hard stuff." In practice, unfortunately, this leads to a "doc culture" where there's often too much focus on the writing & documents and not enough on the coding & getting shit done.
For example, look at Amazon. Writing is considered a core SDE skill, yet atrocious code (especially from more senior "lifers") and shitty half-solutions are seemingly desirable. Promotion at Amazon is about telling a story of your impact in your promo doc, not about explaining to the powers that be that you're a kick-ass engineer who needs harder problems.
Something that I've tried a few times was basically pretending that I'm a live-streamer/YouTuber/whatever and verbally explain my thought process & actions as I program. I found that it was actually better practice for coding interviews than anything else, but I wouldn't be surprised if you found trying something similar also helpful.
I do think there is specific value in practicing summaries, though, as it's a really important skill to be able to distill down a 45-minute technical rant into something grokkable by others in a reasonable amount of time. Something that I do most mornings is plan out my exact phrasings for standup updates, sometimes verbally if I'm having troubles putting my update into words and I'm WFH that day. Then again, I'm probably a bit autistic too and often mentally plan out most non-casual conversations.
The idea is to make the language less context-sensitive and more consistent. It's better if the meaning of `<p>` and `<p/>` don't change based on the parent tag. Now, obviously they failed at making the semantic changes necessary to achieve the goal, but a true XML-based language would've been far simpler both for humans and computers than what we've got now. Most of the author's points are entirely valid, but the conclusion really should've been "HTML is bad."
No. It's an unaccepted proposal.
The problem is that it's filling an array in freshly allocated memory. While you might expect `malloc(NUMBER)` to give your process a crap ton of space in your RAM, that's far from the truth. First of all, glibc will just translate that into an `mmap`, and even if it didn't, the Linux kernel still wouldn't allocate the whole buffer due to "optimistic memory allocation." Instead, you'll receive ownership of this chunk of virtual memory, but you won't actually allocate anything at first. Only when you dirty each page will it actually allocate the backing physical memory. And even then, the Kernel has various heuristics to preemptively page in memory that it thinks you're going to use soon.
I'm sure the author was aware that the example was more nuanced than just "muh CPU cache", but reducing spatial locality to just "muh CPU cache" for the article's sake does a disservice to the reader.
Very much the opposite
Proof that DistroWatch ranking is the most meaningless metric.
> To my recollection, most of the unsafe-rust-specific pointer aliasing bugs which have been found in std or other popular rust libraries happened because the code was written first and then the rules got stricter!
This is exactly why I have mentality. Rust is a language that grows fast and is exceedingly ambitious. Moving fast tends to break things. And while this is certainly a far less frequent occurrence than C/C++ compilers implementing new optimizations that break on UB that has historically compiled correctly, at least C/C++ compilers usually recognize that these optimizations can be dangerous to bad code and provide -O2 to keep bad codebases afloat.
In general, I think the C/C++ spec was wise in being very explicit about what it does not guarantee (though its choice of what might've been questionable). If you never allow something in the first place, it's only the programmer's fault for doing it. What everyone can agree on, though, is that C/C++ compilers not providing tooling & sane defaults that help guide programmers towards good code and better practices was and is an absolute travesty. Things like UBSan have come too little, too late to restore C/C++'s reputation. UBSan and Rust's Miri are some awesome stuff, though.
> What was really meant (or should have been meant) by the original claim is that unsafe rust introduces new rules which must be followed w/r/t pointer aliasing. But it is far from clear that the marginal new rules introduce more unsoundness than the kinds of bugs which rust prevents, in fact it seems rather unlikely. Most memory bugs seem to be the ones that are bugs in all languages, like use-after-free, etc.
I definitely worded things poorly, but exactly. C/C++'s UB is absolute insanity, but it's well defined insanity. The workarounds are all well known, even if they're monstrous abominations. But playing language lawyer with Rust is not only a lot harder since it's underdefined, but there are plenty of things that simply don't have (known) workarounds for. "If it compiles, passes tests, runs correctly, and even passes Miri, then it can't be UB... right?"
But thankfully Rust is optimistic and strives for improvement, so we have things like the Rustonomicon[0] to guide programmers towards sounder `unsafe` code. Unfortunately...
> Warning: This book is incomplete. Documenting everything and rewriting outdated parts take a while. See the issue tracker to check what's missing/outdated, and if there are any mistakes or ideas that haven't been reported, feel free to open a new issue there.