site banner
PaperclipPerfector  3d ago (text post)   2087 thread views

Friday Fun Thread for January 31, 2025

Be advised: this thread is not for serious in-depth discussion of weighty topics (we have a link for that), this thread is not for anything Culture War related. This thread is for Fun. You got jokes? Share 'em. You got silly questions? Ask 'em.

2
Top Bottom Old Controversial Comments
Jump in the discussion.

No email address required.

It disagrees with all my sensibilities about "talking computer", and thus far I find it's constructs around "borrowing" references silly and contrived, especially in light of being able to assign unsafe sections of code that ignore it's memory safety rules. I guess it assumes you'll be responsible with that, but it feels like a half measure to me, and no replacement for actual skill.

lol, I'll put this in hardcore WoW terms: many imagine skill as being able to stylishly finesse your way out of thorny situations; anyone who's ever succeeded at this game mode knows the real skill is not getting yourself into bad situations in the first place. For example, Xaryu -- professional WoW streamer and many-time rank-1 PVP gladiator -- died in the harpy cave in an extremely stylish way. In his next run, did he learn how to super-skill the harpy cave even betterer? Well, yes, in the truly high-IQ way: he decided going in there was a terrible decision in the first place and he wouldn't do so this time. He hit 60 on that character.

This is the difference between a C++ developer mindset and a Rust developer mindset. It is the humility to accept that you are, in fact, not skilled enough to get it right all the time, so you should stop playing with fire in the first place.

This is the difference between a C++ developer mindset and a Rust developer mindset. It is the humility to accept that you are, in fact, not skilled enough to get it right all the time, so you should stop playing with fire in the first place.

I think that argument just isn't supported by the evidence of 40 years of computers more or less working just fine. People are skilled enough to just get it right enough of the time. I think arguments otherwise are just Rust fanatics pretending the history of computer can be broken up into Pre-Rust and Post-Rust eras.

The problem is that suddenly, thanks to the internet, literally every single line of code needs to become a hardened attack surface. "Exploits" didn't matter in a pre-internet age, and I also question how much Rust will really address them. I doubt at the end of the day a Windows written increasingly in Rust will prove more secure than a Windows written in C. I think Rust is necessitated more by the falling skill level of corporate programmers than anything else, and I also doubt it will remediate that problem. If anything treating Rust as a panacea for a lack of skill will only make the problems worse. Less buffer overflow exploits perhaps, still plenty of attack surface for malicious actors to abuse.

All that is an aside though to my dislike of Rust, which I'm only learning for professional reasons. I said it disagrees with my sensibilities about "talking computer", and let me elaborate on that.

I want to bit-fuck the hardware I paid for however I wish. I want to bend over my mechanical slave and force it to do my bidding without a single complaint. I have friends who gravitate towards LISP or Go, I gravitate towards assembly. I want to be at the metal with a big spiked club, with the CPU to afraid to talk back. Because I don't tolerate backtalk from my machines.

I think that argument just isn't supported by the evidence of 40 years of computers more or less working just fine.

Just looking at the last 40 days of computers is enough to support "less" rather than "more". My favorite from quickly skimming reports from the last month or two would probably be Rsync contains six vulnerabilities: "When combined, the first two vulnerabilities (heap buffer overflow and information leak) allow a client to execute arbitrary code on a device that has an Rsync server running. The client requires only anonymous read-access to the server, such as public mirrors. Additionally, attackers can take control of a malicious server and read/write arbitrary files of any connected client. Sensitive data, such as SSH keys, can be extracted, and malicious code can be executed by overwriting files such as /.bashrc or /.popt."

The vulnerabilities are "present within versions 3.3.0 and below" of software that has been heavily used for nearly 30 years now. I'll agree with you that this is "thanks to the internet", but can we really call it "suddenly" now that the internet is four decades old, especially for cases like this where the software was specifically written to make use of the internet? I'm sympathetic with (and a perpetrator of) mistakes of the form "Joe writes a program that reads a file, and expects it to be used by very clever people reading only files that they and their personally-known friends/coworkers created, but then it becomes more popular and now every nescient email user who double-clicks strange attachments is one JoesInstaller away from putting a backdoor on their computer." But for web browsers, mass-market software, servers listening for arbitrary TCP connections, etc., surely there's a better solution to e.g. heap buffer overflows than expecting every software author to finally Git Gud.

I mean, the person reverse-engineering the Mac M1 GPU and building a Linux driver for it is doing so in Rust. I don’t know how much more bare-metal you can get than that.

Rust isn’t about gaining safety by being far from the hardware, the way memory managed languages with runtimes are; it’s about giving the systems programmer a mental model that actually has some degree of engineering sense behind it. You seem to have the impression that C++’s danger is what makes it an appealing tool, but the danger is to the user not accomplishing their intended goal, not to an enemy: it’s a kitchen knife which is all blade and no handle. Moar blaDe doesn’t make the knife better at cutting food into sizes and shapes you want for your sandwich.

And disdain for C++ long predates Rust. If you need to copy your opinions from someone high-status, I’ll defer to Linus Torvalds on the matter.

While I do find the fanaticism around Rust offputting, especially considering how gay it is, the language itself is actually grounded in a better theoretical foundation than its legacy competitors.

While I do find the fanaticism around Rust offputting, especially considering how gay it is, the language itself is actually grounded in a better theoretical foundation than its legacy competitors.

You know, this reminds me of another thing I immediately hated about Rust. They took unions and renamed them enums.

Now in fairness, I've worked in probably over a dozen codebases across 20 years and never once organically encountered anyone using a union. I've never encountered an API that uses unions as their preferred input or output types. It's a language feature I'm aware of, but in my professional and hobbyist work in C, C++, C#, Java, Python (ugh), Javescript (hurk) or anything I've forgotten, I've never seen them actually used. So if Rust wants to pull a fast one on people who slept through that day of class and never learned about a union, and pretend it's a fancy new enum they came up with. whatever. I even think it's kind of clever how they use them and really made them a core part of the language.

But it's also just so fucking presumptuous, to take two pretty well established language features, and mix them up. I tried to google a little, like, have other more modern languages been doing this for a while? All those dorky functional languages nobody does any actual professional work in? I didn't turn up shit. Seems Rust might be the first language to take unions and pretend they are enums. I mean, whatever, it's not hard, it doesn't stop me. I just hate it.

Rust does have normal C++-style unions, though they're a late and fairly controversial addition for the reasons you mention. I'll admit that I've used them occasionally in internal code (especially networking or protocol development, where hardware developers love throwing in 'this next four bytes could be an int or a float' in rev 1.0.1a after you've built your entire reader around structs), but I'd probably ask anyone who used them as an input in an API what they were smoking.

In higher-abstraction languages than C++, that sorta behavior either isn't available and/or forgo the performance and memory-specific benefits for dumb-programmer-safety. TypeScript unions or Java sealed interfaces are doing the same thing at the level of a definition -- it's a field you can put any of a limited number of options in! -- and you'd absolutely never use them for overlapping purposes. On the other hand, C#'s even more limited than Java on that use case, and I come across places it'd make sense to use pretty regularly, so maybe I'm just bitching.

That may be why a lot of their more type-theory focused stuff fell under a different name than the TypeScript-style union types.

I think the Rust enum overload is downstream of a lot of the behaviors you'll see in Java or Kotlin; I've encouraged FIRST students to use similar designs to hold different configuration values for easy toggling of modes or states. Not sure who first made enums that broke from the C(++) limit of one-value-per, but given the amount of C++ code I've seen where enums were used to map various flags intended for bitwise addition, probably a pretty early one.

have other more modern languages been doing this for a while?

Mixing up enums and unions? Not that I know of. Repurposing perfectly well-defined words in misleadingly confusing ways? Since before I was born, including with the most basic building blocks of code, by calling subroutines "functions". Maybe they'd never thought hard enough about side effects or imagined things like memoization, but at the very least they should have gotten the "a function is a rule that assigns to each input exactly one output" lecture by grade 8.

I'm annoyed at Rust for the same reason in the opposite direction. They added sum types, knew they added sum types, but called them "enums" - why?

the language itself is actually grounded in a better theoretical foundation than its legacy competitors

Something every single functional language has, technically correctly, claimed.

There is a reason why functional languages are created- usually an obsession with safety and mathematical purity over all else; that reason is also inextricably linked to why every other language just takes the parts of those languages that enhance one's ability to reason imperatively about the code and leaves the rest.

You seem to have the impression that C++’s danger is what makes it an appealing tool

Inbuilt disdain of "computer says no because reasons" not enough? But then, that depends on thinking that "shipping product that works well enough" is more important than "mathematically correct, but your competition beat you to market by a month", and because Rust is developed by those who emphasize the latter, and not the former, it's going to make compromises in development speed for that safety (which is why everyone tends to bitch about the borrow checker).

Rust is not a replacement for C++. Rust is a replacement for Ada.

Inbuilt disdain of "computer says no because reasons" not enough?

What exactly are you arguing against here? Error messages at compile time? There’s plenty of interpreted languages that crash at runtime if that floats your boat.

Presumably, such people enjoy removing the annoying "check engine" light and just waiting for their engine to start smoking.

that "shipping product that works well enough" is more important than "mathematically correct, but your competition beat you to market by a month"

I don’t believe this is even a real dichotomy, at least in the Rust vs mainstream language sense. (Obviously if you’re formalising something in Lean4, that’s going to be comically inefficient compared to just building it, but that’s so far from the Rust vs C++ land it’s not even relevant.) The reason companies are fond of mainstream languages has nothing to do with engineering, it has to do with the availability of replacement labor. It doesn’t matter what technical properties the mainstream language has; what matters is that it’s mainstream.

which is why everyone tends to bitch about the borrow checker

I’m going to out myself as much crazier than anyone may have expected, but: the borrow checker is the least-inspired part of Rust and the language would be better without it entirely. The reasons Rust is good are because it actually has sane primitive types, non-ambiguous syntax, algebraic data types, parametric polymorphism, a non-busted standard library, and perhaps most importantly: cargo.

The borrow checker paradigm is basically a half-baked bastardization of linear types, and the way it’s done has some serious theoretical deficiencies that basically mandate leaky abstractions. But I’m not going to babble about that here.

While I do find the fanaticism around Rust offputting, especially considering how gay it is...

Yeah the Rust community is... not a great place. It tends to be very politicized and hostile to anyone who doesn't like that. And as you said, there's a weirdly high occurrence of trans people and furries who make that front and center of their programming blogs. No idea what that's about, but as someone who just wants to program I kinda hate the community. But the language is good even if the community is off-putting.

but as someone who just wants to program I kinda hate the community

This is also why I haven't gone into LLMs, except instead of the community it's the models themselves that are gay (or you need to spend hours figuring out which ones have had the gayness removed).

No idea what that's about

It's because they're not programmers, they're math people who just happen to express that through programming (which is why they don't fully understand the "no backtalk from my machines" programmer mindset). These are the academic, math -> programming as end types rather than the programming-as-means/[software] engineer types (who tend to be natively compatible with imperative languages).

You can usually tell if a language was made by these sorts of people if it's a.) a functional-first language (where it's both mathematically pure and hence completely fucking useless), or b.) uses the penis operator ":=" to declare variables. These guys also tend to really love Vim for the same reason.

This is also why I haven't gone into LLMs, except instead of the community it's the models themselves that are gay (or you need to spend hours figuring out which ones have had the gayness removed).

R1 is not gay and will readily roleplay as literally Hitler if you jailbreak it. admittedly it's a bit harder now since they removed the web search but should be still doable.

I think that argument just isn't supported by the evidence of 40 years of computers more or less working just fine. People are skilled enough to just get it right enough of the time.

"Enough" is entirely not enough, we're not programming PDP-11s that are only accessed by your esteemed colleagues anymore. Any Slav with a clapped out netbook can and will try to pwn you on a daily basis. It takes only a single buffer overflow vulnerability that he can leverage into RCE for it to be over. Much like missile defense, it only takes one getting through for you to have big problems.

If your security strategy is to return to 1975, you'd better get working on that time machine. In the meantime, perhaps we should put some effort into rectifying, for example, "features" that are acknowledged by even their inventor as a big mistake.

I can tell everyone read to the same point, got triggered, and didn't continue reading. So I'll repeat myself.

The problem is that suddenly, thanks to the internet, literally every single line of code needs to become a hardened attack surface. "Exploits" didn't matter in a pre-internet age, and I also question how much Rust will really address them. I doubt at the end of the day a Windows written increasingly in Rust will prove more secure than a Windows written in C. I think Rust is necessitated more by the falling skill level of corporate programmers than anything else, and I also doubt it will remediate that problem. If anything treating Rust as a panacea for a lack of skill will only make the problems worse. Less buffer overflow exploits perhaps, still plenty of attack surface for malicious actors to abuse.

I did continue reading (that's why I mentioned your security strategy), my point is that your argument doesn't make sense. You admit that even skilled programmers get it right only "most of the time". That's not enough in the internet age. Falling skill levels of corporate programmers are not the trigger.

Let me put it like this.

You have a group that is just plain retarded. Literally can't do a single thing correctly. They will literally find every failure mode possible, and there will always be failure modes possible, in record time of whatever "idiot proof" product you put before them. But perhaps, they always hit one failure mode first.

You wouldn't fix that first failure mode, declare victory, and act like a new era of idiot proofing is upon us. There are literally an infinite number of other failure modes out there. Including several they will hit in rapid succession now that you've rendered the first physically impossible.

That's what Rust looks like to me. Good job. You made memory incrementally safer from a specific type of exploit. I'm pretty sure exploit technology has come a long way since then. We're all still fucked as long as we keep our systems permanently interconnected.

This makes more sense as far as your earlier "half measure" comment goes. But I still don't think this is a good way of looking at it. Nobody serious is saying "this fixes all things forever", they are saying "this fixes some of the problems". Which is fine - incremental progress is still progress. I think it's better to appreciate that a tool fixes one problem than it is to say "well it doesn't fix all problems so what's the point?".

Given that interconnection isn't going anywhere, I don't see any good reason not to eliminate failure modes where possible. Nobody is claiming that rust fixes everything.

I think that argument just isn't supported by the evidence of 40 years of computers more or less working just fine. People are skilled enough to just get it right enough of the time.

What? We very much have the opposite evidence. People trying real hard to write correct C(++) has led to a whole slew of security exploits due to bugs in the code. It's too soon to say if Rust will meaningfully reduce that, perhaps it won't be any better. But the paradigm you are in favor of empirically does not work.

I want to bit-fuck the hardware I paid for however I wish. I want to bend over my mechanical slave and force it to do my bidding without a single complaint. I have friends who gravitate towards LISP or Go, I gravitate towards assembly. I want to be at the metal with a big spiked club, with the CPU to afraid to talk back. Because I don't tolerate backtalk from my machines.

I don't understand how any of that is at odds with Rust. I've spent some time off and on the last several years working on a Rust kernel for fun, and trust me you can bend the hardware to your will just fine.

What is this place?

This website is a place for people who want to move past shady thinking and test their ideas in a court of people who don't all share the same biases. Our goal is to optimize for light, not heat; this is a group effort, and all commentators are asked to do their part.

The weekly Culture War threads host the most controversial topics and are the most visible aspect of The Motte. However, many other topics are appropriate here. We encourage people to post anything related to science, politics, or philosophy; if in doubt, post!

Check out The Vault for an archive of old quality posts. You are encouraged to crosspost these elsewhere.


Why are you called The Motte?

A motte is a stone keep on a raised earthwork common in early medieval fortifications. More pertinently, it's an element in a rhetorical move called a "Motte-and-Bailey", originally identified by philosopher Nicholas Shackel. It describes the tendency in discourse for people to move from a controversial but high value claim to a defensible but less exciting one upon any resistance to the former. He likens this to the medieval fortification, where a desirable land (the bailey) is abandoned when in danger for the more easily defended motte. In Shackel's words, "The Motte represents the defensible but undesired propositions to which one retreats when hard pressed."

On The Motte, always attempt to remain inside your defensible territory, even if you are not being pressed.


New post guidelines

If you're posting something that isn't related to the culture war, we encourage you to post a thread for it. A submission statement is highly appreciated, but isn't necessary for text posts or links to largely-text posts such as blogs or news articles; if we're unsure of the value of your post, we might remove it until you add a submission statement. A submission statement is required for non-text sources (videos, podcasts, images).

Culture war posts go in the culture war thread; all links must either include a submission statement or significant commentary. Bare links without those will be removed.

If in doubt, please post it!


Rules


Recommended Posts And Communities

Recommended Realtime Chats