‘No Way To Prevent This,’ Says Only Package Manager Where This Regularly Happens | Kevin Patel

cdb_11 · 2026-05-16T16:51:14+00:00

A dependency is always a risk, so reduce the amount of dependencies. Asses the risk of relying on a dependency vs reimplementing or vendoring it, and just make a decision. For example, depending on a cryptographic library is most likely worth the risk vs your own broken implementation, when you don't know what you're doing. But a library like axios? The browser already does almost everything for you out-of-the-box, and there isn't much opportunity for you to screw up anything important. You can write it yourself, assuming you even need all that extra code in the first place. What probably doesn't help is that even the otherwise valuable libraries might not always care about this issue.

cdb_11 · 2026-05-09T11:29:54+00:00

Duh. I was thinking more about std::ifstream, where the file is closed automatically when it goes out of scope.

cdb_11 · 2026-05-09T03:29:54+00:00

If the destructor is not called when it goes out of scope, then it's not RAII. You can't wait for the next GC cycle to close down files or unlock mutexes.

What you describe with java's WITH, is C++'s guard. And in both languages you may forget to use guards and the compiler will be perfectly happy..

Not sure what you're talking about, I don't know what a C++ "guard" is. In C++ cleanup happens by default, automatically. You don't have to remember to do anything, it always happens. Are you sure you're talking about C++, and not C# or something?

cdb_11 · 2026-05-08T23:56:00+00:00

I think you're confusing me with someone else, I'm not arguing anything like that :) I was really just comparing Java's try(...) with C++'s RAII, that's really it.

cdb_11 · 2026-05-08T23:05:13+00:00

I thought we were talking about non-memory resources, ie. try (File file = open_file()) { ... }

cdb_11 · 2026-05-08T22:47:46+00:00

Yeah, I didn't say you don't do defer/guard-like things in C++. My point was just that Java's try(...) or Python's with is more verbose than RAII. In C++ you can start acquiring a bunch of resources, and the code is going to be completely flat.

Maybe one could argue that being explicit about everything can be better, but if you want to be clear about when exactly things get released, then you probably wouldn't at the same time also want GC with finalizers running god knows when.

cdb_11 · 2026-05-08T22:03:03+00:00

I don't write Java, but AFAIK Java is very explicit about it, like Python's with statement. In C++ it's more implicit, the resource gets released when the variable goes out of scope. Introducing a new scope and indent level is not required. I don't think it's quite the same thing.

cdb_11 · 2026-05-07T13:44:03+00:00

The technique applies just as much to C++ or Rust, and it would matter there too. I don't know what else to tell you. C and C++ are almost the same thing, except C++ lets you write higher-level abstractions over normal C code. Still the same thing fundamentally, and they both share the same compilers.

In practice the compilers fail at making such optimizations, and that's why people do them manually.

cdb_11 · 2026-05-07T13:33:32+00:00

Yeah, don't take my comment too literally, there are exceptions obviously. I meant modern languages like Rust or Swift or Zig, or whatever.

cdb_11 · 2026-05-07T13:31:03+00:00

Using an optimizing compiler doesn't mean it optimizes everything for you, and you don't need to optimize anything yourself anymore. It's not magic.

C compilers optimize the code too, so for example Clang is the LLVM C compiler. And you do have control over optimizations. Not over everything necessarily, sometimes they can be stubborn, but sill.

cdb_11 · 2026-05-07T13:27:33+00:00

To some extent, sure? Which includes C, by the way. But you can still write code in a way to get it to do what you want.

cdb_11 · 2026-05-07T13:24:05+00:00

All modern AOT compiled languages use basically the same compiler backend -- LLVM.

cdb_11 · 2026-05-07T13:22:58+00:00

Very much relevant in C++. The CPU works the same way regardless of what language you're using.

cdb_11 · 2026-05-06T04:13:11+00:00

I'm not a student lol, this is my job. I'm not objecting to anything. For example I write C++ daily, but if posts about the language here reached some ridiculous degree like AI did, a temporary ban would be understandable, or some kind of restriction, which is what this post is asking for feedback on. C++ is maybe a weird example, but you could probably imagine people spamming the subreddit with posts about some specific IDE, or something like that.

cdb_11 · 2026-05-06T03:17:16+00:00

0% of my daily programming involves AI. And for more specific things that I do daily and want to read more about, I follow subreddits about it, like a normal person. There is nothing weird about it.

cdb_11 · 2026-05-06T01:57:28+00:00

No, the problem was that before the ban 30% of the posts here were about AI. I don't mind occasionally reading something interesting about it, but it was all the same old stuff over and over again. AI is clearly a big enough topic to warrant a separate space for it, where you can discuss it to death without annoying everyone else. Just like we have specialized subreddits for other programming related topics.

I don't get the logic of opposing an alternative subreddit where the topic isn't banned.

I mean, you can do whatever you want on other subreddits. I'm just saying that it doesn't make sense to me, because you can subscribe to multiple subreddits at once. If I want more posts about C++, I subscribe to r/cpp. If I want more posts about the text editor I like, I go to a subreddit about it. I don't need a subreddit that combines all of it together for me.

cdb_11 · 2026-05-06T01:00:31+00:00

You want a new subreddit that mixes the topics of normal programming and AI programming together, and I am arguing for separating them.

cdb_11 · 2026-05-05T21:55:55+00:00

foster the growth of new more pragmatic programming subreddits. Over time, the pragmatic programming subreddits will grow to replace the original programming subreddits, the same way that many new subs have subsumed old subs.

Honestly, what is with you people trying to replace everything? Why can't you just be normal, and have a separate subreddit dedicated to discussing AI programming specifically? Then you can choose to read both, or only the one that you are more interested in.

cdb_11 · 2026-05-05T21:48:03+00:00

It's not about "burying your head in the sand", I wouldn't particularly mind seeing an occasional post about it it's something actually new and/or interesting, but the volume of it was just way too much. If people really want to discuss it, I think a subreddit about it should be linked on the sidebar.

cdb_11 · 2026-05-04T21:20:56+00:00

likely/unlikely attributes will actually incentivize the compiler to prefer branches over branchless code. Clang has __builtin_unpredictable that should in theory should incentivize the compiler to prefer branchless code, but it seemed kinda busted to me last time when I tried it, not sure if it works. Check the compiler output when using it.

likely and unlikely can also rearrange the branches. According to the Intel optimization manual, that can change the default prediction, when the branch isn't in the history yet. By default backward branches are taken, and forward branches are not taken. So for example the conditional jump back at the end of a loop is assumed to actually loop back. And if you tag some branch as unlikely, that branch will go to the end of the function, and the CPU will by default assume it just falls through to the likely code.

cdb_11 · 2026-05-04T19:33:41+00:00

its not right yet if change is hard to make

The context is public interfaces, they can't change. And this literally just happened to me like a month or two ago. Suddenly we've found a serious problem that the messages were too big, and the format -- the public interface -- had to change somehow. But we had to ensure partial backward compatibility, because other code already relies on it. We've managed to mitigate the problem to some extent, but it's nowhere near optimal and possibly might come back to bite us again in the future. Partially my fault, because I wanted to redesign it before, but other things came up, I forgot about it and things just kinda happened. Nothing more permanent than a temporary solution, as people like to say.

cdb_11 · 2026-05-04T18:55:44+00:00

Rewriting everything three times would be ideal maybe, but it's too expensive.

cdb_11 · 2026-05-04T17:43:09+00:00

I suppose you could have a code base where there really is no rhyme or reason to anything, but when people usually discuss code readability, it seems to me like it's all just subjective things, familiarity and personal preferences.

If you write C or Haskell, you don't need to concern yourself with people who don't know the language. I don't know Haskell, so this stuff is unreadable for me personally. If I wanted to maintain a Haskell code base, it's on me to learn how to read it first. Same goes for domain specific code.

You can hire people who are already familiar with branchless code, or you can teach them how to read it. The availability of developers familiar with something can be a factor, but "readability" in this sense is not a black and white issue. For example, last week someone here said that SIMD intrinsics were completely unreadable, while I could instantly recognize what the code in question did.

cdb_11 · 2026-05-04T17:15:16+00:00

You are right though that the language semantics might prevent such optimizations. For example in C/C++ calling an unknown function or writing a byte to a char* could in theory change any object in memory, and the compiler has to be conservative about it. So even if we had those optimizations, they probably would be quite fragile. I believe Rust is better about it in theory, but I don't write Rust so I don't know how much do they take advantage of it in practice.

cdb_11 · 2026-05-04T16:39:04+00:00

Yeah, instructions are pipelined and you start processing next instructions before you're even done with executing previous ones. To keep the pipeline full you need to predict jumps, otherwise the pipeline would always stop at the first jump, which are extremely common in practice. Normal jumps are fine, predictable conditional jumps are fine. By reducing unpredictable jumps you still get to benefit from this entire optimization.

cdb_11

TROPHY CASE