Most people in the world wants some form of ethnic cleansing - that's why you get 'ethnic quarters' in most large cities, people generally like to be around their own 'kind'.
HN user
cv5005
Current LLMs don't pass the turing test.
Remember, the interrogator is allowed to be hostile, so they would obviously employ all known prompt injections and typical LLM 'gotchas' to figure out who the AI is.
There's no namespacing feature provided so you're left with the convention of picking a few letters as a prefix and hoping it doesn't overlap and yet is succinct enough to not be annoying.
I've been using C on a daily basis for 30+ years and name collisions has just never been a problem.
Granted, it might be due to lack of a package manager so micro dependencies ala import is_even is not a thing here, but still, in practice, no name collions occurs.
Chinese film having 100% chinese cast = good.
American film having a single white male lead = not good.
Never quite understood why people are so obsessed with meta programming capabilities in a language, be it templates, comptime, macros, whatever.
I program mostly in C, if I need 'meta' programming I just write another C program that processes C source code (I've written a simple C parser), then in my build script I build in two stages, build meta program, run it, build rest of program.
Simple, effective, debuggable (the meta program is just normal C), infinite capabilities - can nest this to arbitritary depths, need meta-meta programming? Make a program that generates a meta program.
One need to write it manually each time in each function where some cleanup is needed.
You can structure your code to not need cleanup in every function.
The biggest problem with destructors is, how do you handle errors? close() can fail you know?
One reason is that c++ still hasn't gotten 'trivial relocatability' right - i.e being able to memcpy/memmove and not have to call constructors/destructors when growing your vector class.
Yeah I dont think a single current LLM would fool me in a turing test - I would obiously use all kinds of prompt injection techniques, ask about 'dangerous' or controversial topics, ask about random niche facts in varied fields, etc.
std span is not bounds checked.
Having different types seems wrong to me because endianess issues disappears after serialization, so it would make more sense to slap an annotation on the data field so just the serializer knows how to load/store it.
This was an MFC project, so your old standard win32 common controls that looks the same since 98 or so.
Well it's still a 32 bit program so I guess that helps. Would probably require some porting to make it 64 bit native, but as long as you use the WPARAM, INT_PTR typed and what not correctly it 'should just work'.
I'm an embedded programmer who occassionally needs to write various windows programs to interface with embedded devices (usually via serial port or usb), and I find it a breeze to write native gui programs in pure win32 and c++.
Recently had to add a new feature to and old program that was last updated in the XP era and two things to note:
1. The program did not need to be updated to run on Vista, 7, 10 and 11, shit just kept working throughout the years.
2. I loaded the project into Visual Studio 2022, it converted from VC6 and compiled without problems, added the feature, shipped a new .exe to the customer, and it just worked.
What other platform has that backwards and forwards compatibility success story?
Not a fan of methods.
Why should the first argument be so special? And how do you decide which struct should get method if you have a function that operates on two different types?
Eventually it wont need to write any code at all. The end goal for AI is "The Final Software" - no more software needs to be written, you just tell the AI what you actually want done and it does it, no need for it to generate a program.
Then there's the static initialization order fiasco
One of the reasons I hate constructors and destructors.
Explicit init()/deinit() functions are much better.
Is it? rust has to ditch llvm to be able to replace c++ - or rewrite llvm in rust.
A good compiler will only do that if the register spilling is more efficient than using more stack varibles, so I don't really see the problem.
Bitwise identical output from a compiler is important for verification to protect against tampering, supply chain attacks, etc.
That's because you need to implement a bunch of gcc-specific behavior that linux relies on. A 100% standards compliant c23 compiler can't compile linux.
My personal threshold for AGI is when an AI can 'sit down' - it doesn't need to have robotic hands, but it needs to only use visual and audio inputs to make its moves - and complete a modern RPG or FPS single player game that it hasn't pre-trained on (it can train on older games).
For systems programming the correct way is to have explicit annotations so you can tell the compiler things like:
void foo(void *a, void *b, int n) {
assume_aligned(a, 16);
assume_stride(a, 16);
assume_distinct(a, b);
... go and vectorize!
}This data is publically available to anyone in Sweden:
Your salary (well, last years taxable income), debts/credit rating, criminal history, address, phone number, which vehicles and properties you own and which company boards you're on.
One of organized criminals biggest income these days are scamming rich old folks because it's so trivial to get all details needed (and who to target) to be a pretty convincing bankman, IRS type agent/etc.
Some of it you have to kind of manually request at various places, but it's all available.
So data breaches aren't really that big of a deal when everything is already public.
You don't have to do int2ptr for mmio or absolute addresses, you can punt that to the linker.
extern struct uart UART0;
Then place that symbol at address X in your linker script.CVE-2025-32463
Looks like a logic bug to me? So rust wouldn't have helped.
Those are exactly the kind of bugs you might introduce when you do a rewrite.
And if I want a vec(int *)? These token pasting 'generic' macros never work for non-trivial types.
Pick an appropriate base type (uintN_t) for a bitset, make an array of those (K * N/4) and write a couple inline functions or macros to set and clear those bits.
simd doesnt make much sense as a standard feature/library for a general purpose language. If you're doing simd its because you're doing something particular for a particular machine and you want to leverage platform specific instructions, so thats why intrinsics (or hell, even externally linked blobs written in asm) is the way to go and C supports that just fine.
But sure, if all youre doing is dot products I guess you can write a standard function that will work on most simd platforms, but who cares, use a linalg library instead.
Not any different from C - a given C compiler + platform will behave completetly deterministically and you can test the output and see what it does, regardless of UB or not.
How does the rust compiler assure that when compiling to machine code? Machine code is less safe than C after all.