Downsides of C language culture?

Posted Aug 26, 2024 12:33 UTC (Mon) by ringerc (subscriber, #3071)
In reply to: Downsides of C language culture? by pizza
Parent article: A review of file descriptor memory safety in the kernel

> No, the complaint is not that "<X> won't work"; it's being sanctimoniously told "you don't need to accomplish <X> at all".

This. Or you're wrong for wanting to.

It gets even better when the capabilities of the language/toolchain improve so you can now accomplish<X> ... and now it's ok, you're allowed to want to now.

The Rust community is far from unique in this, to be clear, but it's still very frustrating.

Downsides of C language culture?

Posted Aug 27, 2024 18:41 UTC (Tue) by Wol (subscriber, #4433) [Link] (5 responses)

But is this an "X & Y" problem (or whatever it's called)?

Where X is *your* *perceived* solution, and the actual problem is Y?

Are you fixated on your perceived solution (X), or do you actually want to solve the real problem (Y)? Because X may just be a very bad fit to the language, which has a *different*, totally acceptable, solution to Y.

Certainly I get the impression that the Rust designers may be aggressive in asking "Why do you want X?" But that's because they want to understand what Y is, and provide a solution, just not necessarily the X solution.

Cheers,
Wol

Downsides of C language culture?

Posted Aug 27, 2024 19:42 UTC (Tue) by pizza (subscriber, #46) [Link] (3 responses)

> But is this an "X & Y" problem (or whatever it's called)?
> Where X is *your* *perceived* solution, and the actual problem is Y?

No.

> Are you fixated on your perceived solution (X), or do you actually want to solve the real problem (Y)? Because X may just be a very bad fit to the language, which has a *different*, totally acceptable, solution to Y.

The determination of Y being "totally acceptable" (or even _equivalent_) is not up to the Rust evangelists.

Downsides of C language culture?

Posted Aug 28, 2024 7:33 UTC (Wed) by taladar (subscriber, #68407) [Link] (2 responses)

On the other hand the determination that X is not an acceptable solution is usually based on 50+ years of evidence of C programs having giant security holes or recurring types of bugs because C programmers insist on solving Y by doing X.

Downsides of C language culture?

Posted Aug 28, 2024 10:50 UTC (Wed) by ringerc (subscriber, #3071) [Link]

There are absolutely legitimate reasons to say "we intentionally don't support [X] and think it's a terrible idea; these features provide other ways to solve the same underlying problems without the same hazards."

And sometimes those other ways come with compromises that don't suit everyone. Which is also ok so long as fans of the tool (like Rust) are willing to say "ok, it doesn't look like Rust is a good fit for your specific use case right now."

It becomes a problem when the story is then "this is the only way, if this way conflicts with other constraints you have you need to remove the other constraints and do it our way because that's the one right true way".

Even if it's 10x the time and development effort or mountains of boilerplate, or has a huge runtime performance penalty unacceptable in the use case etc.

For example, as a big postgres fan and sometimes postgres contributor, when someone asks me how to embed Postgres in their application I'll say "you probably shouldn't, there are other DBs that are much more suitable for embedding in apps. You can kind of do it with postgres but it'll be more fragile and harder for the user to back up, run, update and migrate your app. You can probably just use SQLite."

I won't tell them "embedding a DB in an app is fundamentally wrong, educate your users about properly installing and managing a RDBMS and it's backups, rhen have them configure your app to connect to a postgres they install themselves."

Just because postgres is a bad choice for in-app embedding doesn't mean it's wrong to want to embed a DB in your app.

But I've seen this sort of thing a lot, and definitely not just from rust, go, Python, postgres, or any other community. It's especially funny when the tool in question gains a new feature that makes the use case not suck with that tool and now it's ok, when cool, to want to do it when before it was consider a terrible idea irrespective of what tool you used.

Downsides of C language culture?

Posted Aug 28, 2024 12:42 UTC (Wed) by pizza (subscriber, #46) [Link]

> On the other hand the determination that X is not an acceptable solution is usually based on 50+ years of evidence of C programs having giant security holes or recurring types of bugs because C programmers insist on solving Y by doing X.

Since you're making sweeping generalizations, here's one more.

Folks advocating for Y are quick to hype theoretical _benefits_, but completely (and conveniently) ignore its _cost_, be it up front (ie initial implementation), ongoing (maintenance), and at runtime (eg performance, UX, etc)

Downsides of C language culture?

Posted Aug 28, 2024 10:36 UTC (Wed) by ringerc (subscriber, #3071) [Link]

Yes this can absolutely be the case.

I've been on the other side at times telling people "no, this isn't how to approach this problem," "this tool works best using a set-based rather than iterative formulation", "this isn't the right tool to solve your problem". I've also done a lot of walking people back from "I want to do X" until we get to "I want to solve problem Y" then forward again to find effective solutions without their assumptions and preconceptions.

So I get it.

And yes sometimes I too have said "dear God no you don't want to do that and here's why". By which I mean "if you attempt this you are in for a world of pain and slow failure."

But I do my best not to tell people that they're wrong for wanting to solve a problem at all. Or that the tool I'm help them with is unsuitable for their particular problem right now.

The real trouble arises when all problems are reframed around the tool's capabilities.

You don't want dynamic loading of functionality (because golang doesn't/didn't do that), decouple it via gRPC services and immutable containers because it's Just Better(TM). You don't ever want to use dynamic key/value data in relational DB because it's fundamentally wrong, stop wanting to do that (unless your RDBMS has dymaic set types or something in which case you're allowed to want it for appropriate use cases). The list goes on.