Defletter

Because of the clear regressive biases evident in your comments: not once in your little diatribe nor the tedious back and forths since then have you mentioned general paid time off, bereavement leave, or even paternity leave. I don't want fathers to be chained to their desk and away from their children either, hence my use of "parental leave", but you seem only concerned about mothers being around their children. Isn't that interesting? That coupled with your "the glorification of every other sexual special interest except the productive one", spreading the bigoted lie that non-straight people are unproductive to society and there's little ambiguity on what you think women's role in society is.

Why would you assume that someone who specifically mentioned "self-determination, social equity, liberty, and nonaggression" was advocating for "keeping women chained to their desks and away from children" through a lack of parental leave?

Ohhh, you thought our objection to your regressive nonsense was an objection to parental leave? That's... no.

This would do rounds on TruthSocial or X, The Everything App. Might I suggest moving this conversation over there?

Once either of you present an argument worthy of respect within a civil and democratic society, I will respond in kind. Until then, statements like "the glorification of every other sexual special interest except the productive one" will continue to get the responses they deserve.

> keeping women chained to their desks and away from children

> glorification of every other sexual special interest except the productive one

Yikes, someone should check your harddrives

> Your real middle class refuses to show any but the most bland books and magazines on its coffee tables: otherwise, expressions of opinion, awkward questions, or even ideas might result. -Paul Fussell, Class

The greyification of our lives, the loss of whimsy and kitsch and being too afraid to be a little cringe, I get the sense that a lot of people associate "growing up" as the loss of any and all expression: we wake up in our grey beds in our millennial grey house, drive to work in our grey car to work in our grey cubical, etc, etc. If you want a gauche laptop covered in stickers, do it, embrace the gauche. Everyone sneering at you is more miserable than you.

> My personal take is that if I need more abstraction than Zig, I need something with managed memory--not Rust or C++

You may potentially like D. Its tooling leaves much to be desired but the language itself is pretty interesting.

It may be due to the async/io changes which may have caused a wave of renewed interest in the language

tbf, it does require a technique otherwise you risk just pushing plaque underneath your gums

The level of knee-jerk reaction to anything Rust into traditionally C projects borders on the pathological. That email is about as polite as it gets without being coddling.

Hmmm, it still has a pretty extensive default list of permitted npm packages, which wouldn't necessarily be a problem if there were a way to disable it, but I can't seem to find it.

How does Bun avoid this? Or is it more that Bun provides things that you'd otherwise need a dependency for (eg: websockets)?

> Just set the properties you want the element you are using to what you want it to be.

"Just". What I remember from that time was putting a button at relative 0,0 and it being at the top-left of the page in one browser, but was offset in another because that browser was adding padding/margin to <body>. I cannot say which was "correct" but it nonetheless pushed me to use normalisers, which prevented this kind of problem from ever coming up again.

Presumably, a reset is resetting to a browser's defaults, whereas a normaliser is about establishing a cross-browser default. I haven't done much web-dev in recent years, but I vividly remember the same page looking different in different browsers, particularly prior to HTML5.

Really wish people would just bite the bullet and do configuration as code instead of trying to make all these config petlangs.

Can't speak for everyone, but I think a substantial part of the shift from Maven to Gradle was the ability to write build scripts: you didn't need to write a plugin. I'm hoping that Maven (and Gradle) can take advantage of JEPs 458 and 512 to allow people to write build scripts for that Java projects in Java.

- https://openjdk.org/jeps/458

- https://openjdk.org/jeps/512

While I'm unsure about the efficacy of LLMs, I do yearn for language tooling that lets you 'Bring Your Own Syntax'. I'm someone who prefers TypeScript, Java, and Zig's syntax and genuinely, genuinely struggles with Go, Crystal, Kotlin's syntax. Whoever came up with := versus = needs to stub their toe at least once a day for the rest of time. But if I could write code for Go using a different syntax, I'd write way more Go code. I feel like that's what petlangs like Borgo (https://github.com/borgo-lang/borgo) and AGL (https://github.com/alaingilbert/agl) are doing: making Go less goey.

> I'm saying that one should learn the basics on day one.

Except that C/C++ have entirely incongruous sets of basics compared to modern languages, which people coming to C/C++ for the first time are likely to have a passing familiarity with (unless it's their first language, of course). Yes, cmake configs can be pretty concise when only dealing with system packages, but this assumes that developers will want to do that, or whether they'll want to replicate the project-localness ideal, which complicates cmake configs. We're approaching this from entirely different places and is reminding me of the diametrically-opposed comments on this post (https://news.ycombinator.com/item?id=45328247) about READMEs.

> I think it shouldn't be a skill issue because a true professional should learn how to do it :-)

Therein lies the issue, in my opinion: I do not believe that someone should have to be a "true professional" to be able to use a language or its tooling. This is just "git gud" mentality, which as we all [should] know [by now] cannot be relied upon. It's like that "So you're telling me I have to get experience before I get experience?" meme about entry-level jobs: if you need to "git gud" before you can use C/C++ and its tooling properly, all that means is that they'll be writing appalling code and build configs in the mean time. That's bad. Take something like AzerothCore: I'd wager that most of its mods were made by enthusiasts and amateurs. I think that's fine, or at least should be, but I'm keenly aware that C/C++ and its tooling do not cater to, nor even really accommodate amateurs (jokey eg: https://www.youtube.com/watch?v=oTEiQx88B2U). That's bad. Obviously, this is heading into the realm of "what software are you trusting unwisely", but with languages like Rust, the trust issue doesn't often include incompetence, more-so just malice: I do not tend to fear that some Rust program has RCE-causing memory issues because someone strlen'd something they shouldn't.

Even though I understand why you prefer that, I feel like you're painting too rosy of an image. To quote Tom Delalande: "There are some projects where if it was 10% harder to write the code, the project would fail." I believe this deeply and that this is also true for the build system: your build config should not be rivalling your source code in terms of length. That's hyperbole in most cases, sure, and may well indicate badly written build configs, but writing build configs should not be a skill issue. I am willing to bet that Rust has risen so much in popularity not just because of its memory safety, but also because of its build system. I don't like CMake, but I also don't envy its position.

While I do appreciate you taking the time to write that, I am somewhat at a loss. How does this justify the antipathy towards notions of a first-party build system and package manager? That's how we got into this argument with each other: I was calling out C/C++ cultists who cling to the ugly patchwork of hacky tooling that is C/C++'s so-called build systems and decry any notion of a first-party build system (or even a package manager to boot) as being destined to become just like npm.

C/C++ developers clearly want a build system and package manager, hence all this fragmentation, but I can't for the life of me understand why that fragmentation is preferable. For all the concern about supply-chain attacks on npm, why is it preferable that people trust random third-party package managers and their random third-party repackages of libraries (eg: SQLite on conan and vcpkg)? And why is global installation preferable? Have we learnt nothing? There's a reason why Python has venv now; why Maven and Gradle have wrappers; etc. Projects being able to build themselves to a specification without requiring the host machine to reconfigure itself to suit the needs of this one project, is a bonus, not a drawback. Devcontainers should not need to be a thing.

If anything, this just reads like Sunk Cost Fallacy: that "it just works" therefore we needn't be too critical, and anyone who is or who calls for change just needs to git gud. It reminds me of the never-ending war over memory safety: use third-party tools if you must but otherwise just git gud. It's this kind of mindset that has people believing that C/C++'s so-called build systems are just adhering to "there should be some artificial friction when using dependencies to discourage over-use of dependencies", instead of being a Jenga tower of random tools with nothing but gravity holding it all together.

If it were up to me, C/C++ would get a more fleshed-out version of Zig's build system and package manager, ie, something unified, simple, with no central repository, project-local, exact, and explicit. You want SQLite? Just refer to SQLite git repository at a specific commit and the build system will sort it out for you. Granted, it doesn't have an official build.zig so you'll need to write your own, or trust a premade one... but that would also be true if you installed SQLite through conan of vcpkg.

Okay, I'll bite: your proposed alternative to being able to specify exact versions of dependencies regardless of operating system or distro that I can statically include into a single binary, everything is project-local, guaranteed, is... what? Is it just "Don't"?

You misunderstand, I am already well aware. My comment about your lack of elaboration was not due to any ignorance on my part, but rather to point out how you assumed that and refused to elaborate anyway. The idea that I may have my reasons for preferring dependencies-as-git-submodules or their equivalents (like Zig's package system) never crossed your mind. Can't say I'm surprised. Oh well.

> Start by not calling everybody disagreeing with you a cultist, next time.

You'd do very well as a culture war pundit. Clearly I wasn't describing a particular kind of person, no, I'm clearly I'm just talking about everyone I disagree with /s

Your defensiveness is completely hindering you and I cannot be bothered with that so here are some much needed clarifications:

> I am not a C/C++ cultist at all, and I actually don't like C++ (the language) so much (I've worked with it for years). I, for one, do not love it when there is an exploit in a language package manager.

If you do neither of those things then did it ever occur to you that this might not be about YOU?

> I find it ironic that when I explain that my problem is that I want to be able to audit (and maintain, if necessary) my dependencies, the answer that comes suggests that I am incompetent and "inexpertly" doing my job.

Yeah, hi, no you didn't explain that. You're probably mistaking me for someone else in some other conversation you had. The only comment of yours prior to mine in the thread is you saying "I can use pkg-config just fine." And again, you're thinking that I'm calling YOU incompetent, or even that I'm calling you incompetent. But okay, I'm sure your code never has bugs, never has memory issues, is never poorly designed or untested, that you can whip out an OpenGL alternative whatever in no time and it be just as stable and battle-tested, and to say otherwise must be calling you incompetent. That makes total sense.

> AUR stands for "Arch User Repository". It's not the official system repository.

> So it's not a good example if you want to talk about official repositories.

I said system package, not official repository. I don't know why you keep insisting on countering an argument I did not make. Yes, system packages can be installed from unofficial repositories. I don't know how I could've made this clearer.

--

Overall, getting bored of this, though the part where you harp on about doing dependencies properly compared to me and not elaborating one bit is very funny. Have a nice day.

> AUR stands for "Arch User Repository". It's not the official system repository.

Okay... and? The point being made was that the issue of package managers remains: do you really think users are auditing all those "lib<slam-head-on-keyboard>" dependencies that they're forced to install? Whether they install those dependencies from the official repository or from homebrew, or nix, or AUR, or whatever, is immaterial, the developer washed their hands of this, instead leaving it to the user who in all likelihood knows significantly less than the developers to be able to make an informed decision, so they YOLO it. Third-party repositories would not exist if they had no utility. But this is why Debian is so revered: they understand this dynamic and so maintain repositories that can be trusted. Whereas the solution C/C++ cultists seem to implicitly prefer is having no repositories because dependencies are, at best, a slippery slope.

> "It's too hard to add a dependency in C++"

It's not hard to add a dependency. I actually prefer the dependencies-as-git-submodules approach to package managers: it's explicit and you know what you're getting and from where. But using those dependencies is a different story altogether. Don't you just love it when one or more of your dependencies has a completely different build system to the others? So now you have to start building dependencies independently, whose artefacts are in different places, etc, etc, this shouldn't be a problem.

> I, for one, do not love it when there is an exploit in a language package manager.

Oh please, I believe that about as much as ambulance chasers saying they don't love medical emergencies. Otherwise, why are any and all comments begging for a first-party package manager immediately swamped with strawmans about npm as if anyone is actually asking for that, instead of, say, what Zig or Go has? It's because of the cultism, and every npm exploit further entrenches it.

Question, does that work with other types? Say you have two u16 values, can you concatenate them together with ~ into a u32 without any shifting?

I'm getting the impression that C/C++ cultists love it whenever there's an npm exploit because then they can gleefully point at it and pretend that any first-party package manager for C/C++ would inevitably result in the same, nevermind the other languages that do not have this issue, or have it to a far, far lesser extent. Do these cultists just not use dependencies? Are they just [probably inexpertly] reinventing every wheel? Or do they use system packages like that's any better *cough* AUR exploits *cought*. While dependency hell on nodejs (and even Rust if we're honest) is certainly a concern, it's npm's permissiveness and lack of auditing that's the real problem. That's why Debian is so praised.