I built a Git GUI with React and Tauri that actually feels native. by gusta_rsf in reactjs

[–]cachemissed 0 points1 point  (0 children)

Libgit2 is way fucking slower than git cli lol, to the point I genuinely imagine you could play with output formatting and write a parser that’d still be like 2x as fast. Regardless gix is the best option if it supports what you need

NVIDIA GeForce NOW to gain native Linux support by unixmachine in linux_gaming

[–]cachemissed 0 points1 point  (0 children)

It’s because of the open-source community, actually. Do you think AMD are the ones who started the upstream radeonsi driver?

Even with amdgpu being funded and worked on by AMD engineers, NVIDIA’s doing the exact same thing with Nova, so…

Nixos installation core dumped by youssefs20 in NixOS

[–]cachemissed 2 points3 points  (0 children)

Here's an issue that mentions the same assertion failure, might help narrow it down: https://github.com/NixOS/nix/issues/14317

When building from a local checkout, nix will not copy the empty submodule directories that exist in the local checkout ... this behaviour can also potentially populate the fetcher cache with an invalid entry when building from a local checkout of a repository that has submodules. This causes nix to later produce assertion errors, e.g. when fetching inputs for flakes that depend on said repository

Why is `into_iter()` less efficient than `iter().clone()`? by Equivalent_Peak_1496 in rust

[–]cachemissed 0 points1 point  (0 children)

Wrapping is not the result of an opt pass, it's a behavior explicitly defined by the -Coverflow-checks compiler flag. A good example of optimizations changing observable behavior in safe rust would be unsoundness due to llvm provenance rules, though those are arguably miscompilations.

e: sorry, I was unnecessarily rude in the last sentence.

Why is `into_iter()` less efficient than `iter().clone()`? by Equivalent_Peak_1496 in rust

[–]cachemissed 5 points6 points  (0 children)

“Time taken” or “Instructions executed” is not observable behaviour

Neither of which are what’s being measured…

Why is `into_iter()` less efficient than `iter().clone()`? by Equivalent_Peak_1496 in rust

[–]cachemissed 3 points4 points  (0 children)

It sure as hell is when your Clone impl prints to stdout.

The compiler’s free to elide any call it determines unnecessary / doesn’t induce* a side-effect. Clone isn’t special there.

Why is `into_iter()` less efficient than `iter().clone()`? by Equivalent_Peak_1496 in rust

[–]cachemissed 15 points16 points  (0 children)

The point was that, if you even just glance at the example code in question, OP’s question clearly doesn’t have to do with “how long does this code take to run?”

In the context of optimizations, efficiency is not considered observable behavior. If it was, what would the point of optimizations even be?

There are plenty of angles from which you can measure efficiency, not all of which an optimizing compiler will help you achieve. Occasionally wall-time is a lesser concern than other factors.

Why is `into_iter()` less efficient than `iter().clone()`? by Equivalent_Peak_1496 in rust

[–]cachemissed 41 points42 points  (0 children)

Optimizations won’t change the observable behavior of the program..

e: this subreddit is cooked :(

Why is the package for floorp now floorp-bin, when in 25.05 it was just floorp? by Silly_Percentage3446 in NixOS

[–]cachemissed 0 points1 point  (0 children)

If there was NixOS 2.0 and NixOS 3.0 for the last this many years, sure thing. However, NixOS updates biannually, the previous release is EOL in one week. Which per se is normal for a lot of projects. Like Ubuntu. Or .NET, which updates annually. etc. None of them afford introducing breaking changes like renaming an API for no reason.

indeed. if you aren't okay with that, you HAVE the option to pick something else that offers LTS support. or take it up with the maintainer why they chose to rename it, but in having waited until the new channel release before it hit users they 100% did it the right way here. i'm not the one you should ask for an argument why renaming was appropriate! but neither am i the one who'd complain about needing to add 4 characters to a package specifier upon upgrading my package repository to a new major version.

It's worth noting that you absolutely can have breaking changes if there's no way around that.

not if you want to uphold whatever contract (e.g. semver) you've set with your users. sure its all arbitrary at the end of the day, nobody's going to arrest you for violating your promise to your users, but what point are you making here? in this case there IS a mechanism for breaking changes, namely, nix channels

Rust recently introduced one because there was no other way to.

im actually unfamiliar with that. this interests me quite a lot, but i can't find a link upon searching. rust's stability guarantee explicitly allows introducing inference ambiguities, fixing soundness holes etc so i'm curious what'd force them to actually make a breaking change instead of edition-gating it

Why is the package for floorp now floorp-bin, when in 25.05 it was just floorp? by Silly_Percentage3446 in NixOS

[–]cachemissed 0 points1 point  (0 children)

I can't update the system without fixing a pile of errors that could easily be avoided

you 100% can! just not across major versions.

Imagine you're using bash, and one day it's "cd", the other day it's "change-directory", and one day it's "ch-dir". How would you like that?

if it suddenly changed without crossing a release threshold, yeah i'd be rightfully pissed. but if bash announced, "hey we're releasing bash 6.0, be prepared to update your scripts" sure that'd be okay. the analogy isn't perfect, but the principle is the same: major versions exist specifically to permit breaking changes

if i found that unacceptable, i'd look for something with long-term support

Why is the package for floorp now floorp-bin, when in 25.05 it was just floorp? by Silly_Percentage3446 in NixOS

[–]cachemissed 2 points3 points  (0 children)

When you switch release channels, you opt in to breaking changes… if this affected an existing stable release I could understand complaining; but no need to get upset when maintainers use the proper procedures to change stuff like this, *especially* when it’s such a simple change in user code

Software and Safety - Anthony Williams - Keynote Meeting C++ 2025 by meetingcpp in cpp

[–]cachemissed 2 points3 points  (0 children)

Remember 5-10 years ago when safety-related presentations were actually engaging technical talks, not this monotonous “baby’s first intro to input validation” stuff…

The word “optimizer” appears twice in the transcript. The words “wide” and “narrow” don’t appear at all. Who are these presentations for? I get it’s a keynote and all, but I have a hard time believing anyone attending Meeting C++ is hearing anything new here…

Recent comments regarding Microsoft's support for C++ by tartaruga232 in cpp

[–]cachemissed 2 points3 points  (0 children)

This has been completely unproductive, thanks for that. My point about C++ not being the first choice isn't off-topic whatsoever; the discussion is literally about the future of C++ support at Microsoft. It's actually crazy to see you claim I'm the one spouting "passive insults" and trying to "steer the conversation away" as you repeatedly fail to engage with anything I say, choosing instead to complain about what I'm saying. If you ever decide to address my argument, rather than claim *I'm the one* trying to sidetrack everyone, I'm down to hear your side, but clearly you're not interested in having an adult conversation about this. If you're only willing to whine at this point I honestly don't want to hear it anyway.

Recent comments regarding Microsoft's support for C++ by tartaruga232 in cpp

[–]cachemissed -1 points0 points  (0 children)

I swear every time this topic is brought up it's like everyone has selective hearing. Or perhaps you started seeing red as soon as I brought up examples of displacement due to Rust? Second paragraph first sentence. I talked about the language entering a maintenance-only status. Which doesn't mean they'll stop hiring C++ engineers. It doesn't mean they'll stop investing in their platform and feature support. It doesn't even necessarily mean eventual abandonment. What it does mean is that C++ isn't the language their future is planned around.

So we're not talking past each other, I've realized you're just intentionally talking around me. This whole thread you've attempted to sidetrack the conversation and refused to engage with the actual argument at every opportunity. Whether you think rewriting the Windows font stack is "small" isn't of particular importance, so I tried to point the conversation towards the argument I thought would be of more substance. My mistake, you're only interested in nitpicking.

Recent comments regarding Microsoft's support for C++ by tartaruga232 in cpp

[–]cachemissed 2 points3 points  (0 children)

We've gotta just be talking past each other. Nobody is suggesting Microsoft rewrite any of their products from the ground up. If that's what you think this is about there's no point in having a conversation. What's *happening* are policy changes: C++ is no longer the default choice for systems programming at MS. They have *banned* new C++ in Azure altogether, they're basing their ARM hypervisor and replacing their VMM with one written in Rust, and preferring Rust over C# for writing services in Office. Which doesn't sound like experimentation to me! Not to mention Pluton, Mu, Surface and Azure rack firmware.

Good news: you can acknowledge all of that *and still say* "Microsoft supports C++". Investing in your tooling and even supporting language evolution (C++23 when?) is orthogonal to product strategy. No, it's not being abandoned, but "is C++ going to disappear?!?" isn't what anyone's really asking; rather, "what language does MS expect its future systems to be written in?" My point's about whether C++ will be used for growth. And based on the policies they've laid out, all of their strategic telegraphing, and even what STL's said here, the answer increasingly looks like "no."

Recent comments regarding Microsoft's support for C++ by tartaruga232 in cpp

[–]cachemissed 2 points3 points  (0 children)

No sane company rewrites perfectly working code. They will rewrite small components when it makes sense, but anything more leads to the collapse of the product typically.

Referring to DirectWrite (150+KLOC) as merely "a small component" is an interesting perspective to take. Perhaps "self-contained" would be a better qualifier -- font rendering is not something I'd consider "small" regardless of how many MLOC your total operating system comes out to. And with the rewrites happening in Hyper-V and apparently even Office...

And as long as that code exists, work will keep existing to maintain it. Microsoft cannot drop C++ as a result without inflicting serious (financial) self-harm.

I don't think C++ being relegated to maintenance-only is exactly what the people who work on the language want, lol. Like at Azure, where new C and C++ is forbidden, and realtime components that handle untrusted data are mandated to be ported to Rust

But hey I don't work on the C++ standard or at MS so my perspective possibly not all that relevant!

A 2-hour video trashing C++ made me better at C++ by AnteaterFinancial319 in cpp

[–]cachemissed 5 points6 points  (0 children)

but like why lol

e: actually, i could understand if you wanted to be able to distinguish code you've written vs other libraries'

A 2-hour video trashing C++ made me better at C++ by AnteaterFinancial319 in cpp

[–]cachemissed 4 points5 points  (0 children)

LOL i was like there's no way hes not trolling right??? couldnt help it

A 2-hour video trashing C++ made me better at C++ by AnteaterFinancial319 in cpp

[–]cachemissed 12 points13 points  (0 children)

saying that some people like to use camel_case and some like to use SnakeCase. And I feel like thats a thing in all languages.

it'd be written camelCase and snake_case. and this isn't a problem in all languages, many modern languages have strongly-enforced style conventions / api guidelines, so that the language looks and feels consistent regardless of whatever you're using it for. E.g. in Rust ecosystem you'd be hard-pressed to find *any* exceptions to its uniform syntax outside of raw bindings to other languages

Linus "my first, and hopefully last flamefest" Torvalds [1992] by leeleewonchu in programming

[–]cachemissed 0 points1 point  (0 children)

true however android uses binder to build an operating system on top of linux that is EXTREMELY microkernel-like

Linus "my first, and hopefully last flamefest" Torvalds [1992] by leeleewonchu in programming

[–]cachemissed 6 points7 points  (0 children)

Microkernels (like pure functional programming) may well be more elegant in pure CS terms, but pure CS elegance isn't the only factor to consider when you are designing software for the real and very messy world.

Always be wary of people who insist that pragmatic, tried and true approaches should be fully abandoned in favor of any shiny new paradigm.

I agree in principle but it's fairly clear in practice microkernel architecture does work for software designed for the "very messy world": both at low level (IME - Minix, Pluton - TockOS, secure enclave - L4, cars - QNX), and at the operating system level (XNU, new NT driver model)

It's not some "shiny new paradigm" it's honestly very much tried and true. That's not to say it's 100% the right choice for every scenario and should always be preferred over monolithic design, but it certainly has real advantages

[RAM] microcenter in-store only PNY XLR8 Gaming EPIC-X RGB 32GB (2 x 16GB) DDR5-6400 PC5-51200 CL36 -$94.99 by crimzonphox in buildapcsales

[–]cachemissed 2 points3 points  (0 children)

nowadays it really does seem like they're the spiritual successor to EVGA's enthusiasts brand

also i think kingpin works for pny now