It may be due to the async/io changes which may have caused a wave of renewed interest in the language
779 karma · joined May 14, 2021
"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.
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.
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.
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.
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
> 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.
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.
The issue isn't cost in this case, it's the storage and effort of having to lug it out and put it back afterwards. Even if someone gave me an old screen and keyboard for free, I'm still not going to build that server PC. I've been looking into PiKVM as advised by another comment and they're pretty pricey at ~£200 but that's genuinely orders of magnitude more preferable. In another conversation on another platform, I was told about nexdock, which is more for docking phones but can be used as a dumb terminal, which is pretty enticing... though their website is pretty dubious, eg: the shop doesn't even tell me what version of the nexdock I'd be buying.
The most obvious solution would be make a small PC: more powerful and bigger fans means less noise. I've been considering something like this (https://www.youtube.com/watch?v=Jr5MjhgPz_c)... but then how am I supposed to use it? Yes, I can ssh into it, but what if it fails to start? Just last month my Thinkpad server failed to restart properly. This was a trivial fix but it being a laptop whose lid I can just open and use immediately made it an extremely easy fix, which would not be true for a PC.
Thing is, I know that dumb terminals exist, ie, a screen, keyboard, and trackpad that takes the form-factor of a laptop but has no actual internals, it's just a convenient interface when plugged into a server. I've seen them. I've tried searching for them but there doesn't seem to be an agreed-upon search category, and the ones I manage to find are more expensive than the PC itself and are usually designed as a server-rack drawer.
Genuinely, what do people do here? Do they just have their server setup somewhere like a desktop? Or are people keeping spare monitors, keyboards, and mice around that they then need to unpack, plug in, and use awkwardly before putting it all away again?
Kind of bonkers this even needs to be said, and even then it's missed/ignored.
Yup, the fact that every new service now is AI-first is troubling... it's literally the first thing said about Amber when going on their website. My tab says "Amber — AI-enabled all-in-on...". It's like the only thing they want you to know about their service.
switch (result) {
case Ok(var value) -> println(value);
case Err(var ex) -> switch (ex) {
case HttpException httpEx -> {
// do something like a retry
}
default -> {
// if not, do something else
}
}
}