Which war? This happened in the West Bank!

For people who don't follow this, the West Bank has a different government vs Gaza (they are not friends!), and is in fact pretty compliant wrt Israel.

I regularly go to a nearby cinema that also shows older movies. Watching a movie like "Ran" (Akira Kurosawa) in a restored 4k version on a big screen is quite an experience. (Tickets are 10€ btw.) Often I go with a friend, but occasionally I also go alone. There's something about spending 2 or 3 hours in a dark room entirely focussing on a piece of art.

Ran is such a good movie to watch in a theatre. I saw Rashomon for the first time in a theatre and it was a life-altering experience

Sad to see this flagged. Articles like these are exactly why I come to HN. Technology does not exist in a moral vacuum! You cannot reasonably keep "politics" away from this site when large tech companies are actively involved in killing people and destroying democracy.

why did this get flagged?

Usually it's either

1. Certain users do not like "political" topics on the front page. But as I said, the very idea of "apolitical" tech news is naive, especially in times like these.

2. Some users want to suppress it because it goes against their own political interests.

Either way, it's a gross misuse of the flag button. I am wondering: are there any consequences for wrongly flagging submissions?

lotta tech bros in palantir, and they read HN too, mate.

Unfortuantely, while I do come here for these kinds of discussions, it's moistly because I've excised the sociopathic and nationalistic folks from much of my medua and it's much easier to find those values among wanna-be venture capitalists.

I "value" their opinions insofar as they have an outsized influence on our world:

I feel like if I want to stay tapped into the progress folks are making on building the Torment Nexus, this website is where I will find folks breathlessly cheering it on.

What's fun about it?

It's like seeing your kid learn how to walk. They'll fail a couple of times, but they'll get toughen up and finally learn.

If you implement the actual game logic in a scripting language like Lua, hot reloading becomes trivial. sol2 is a really awesome Lua binding library for C++: https://github.com/ThePhD/sol2

Thanks for the Lua bindings suggestion!

It's just that I quite dislike using such a scripting language. It's personal preference, for sure, but here's a bit more context https://news.ycombinator.com/item?id=47220602

alloca() is super useful, but it's also quite dangerous because you can easily overflow the stack.

The obvious issue is that you can't know how much space is left on the stack, so you basically have to guess and pick an arbitrary "safe" size limit. This gets even more tricky when functions may be called recursively.

The more subtle issue is that the stack memory returned by alloca() has function scope and therefore you must never call it directly in a loop.

I use alloca() on a regular basis, but I have to say there are safer and better alternatives, depending on the particular use case: arena/frame allocators, threadlocal pseudo-stacks, static vectors, small vector optimizations, etc.

> The obvious issue is that you can't know how much space is left on the stack [...]

Oh, huh. I've never actually tried it, but I always assumed it would be possible to calculate this, at least for a given OS / arch. You just need 3 quantities, right? `remaining_stack_space = $stack_address - $rsp - $system_stack_size`.

But I guess there's no API for a program to get its own stack address unless it has access to `/proc/$pid/maps` or similar?

You can do something like:

    void *get_sp(void) {
        volatile char c;
        return (void *)&c;
    }

Or, in GCC and Clang:

    void *get_sp(void) {
        return __builtin_frame_address(0);
    }

Which gets you close enough.

It's certainly possible on some systems. Even then, you have to fudge, as you don't know exactly how much stack space you need to save for other things.

Stack memory is weird in general. It's usually a fixed amount determined when the thread starts, with the size typically determined by vibes or "seems to work OK." Most programmers don't have much of a notion of how much stack space their code needs, or how much their program needs overall. We know that unbounded non-tail recursion can overflow the stack, but how about bounded-but-large? At what point do you need to start considering such things? A hundred recursive calls? A thousand? A million?

It's all kind of sketchy, but it works well enough in practice, I suppose.

Personally, I only use alloca() if:

1. I know that the function will never be called recursively and

2. the total amount of stack allocation is limited to a few kilobytes at most.

alloca() is more problematic on embedded platforms because default stack sizes tend to be tiny. Either document your stack usage requirements or provide an option to disable all calls to alloca(). For example, Opus has the OPUS_NONTHREADSAFE_PSEUDOSTACK option.

If your API includes inline assembly, then it's trivial. Go's internals would need it to swap stacks like it does. But I doubt any of that is exposed at the language level.

> $system_stack_size

Does such thing even exist? And non-64 bit platforms the address space is small enough that with several threads of execution you may just be unable to grow your stack even up to $system_stack_size because it'd bump into something else.

> Does such thing even exist?

AFAIK no. There are default stack sizes, but they're just that, defaults, and they can vary on the same system: main thread stacks are generally 8MiB (except for Windows where it's just 1) but the size of ancillary stacks is much smaller everywhere but on linux using glibc.

It should be possible to get the stack root and size using `pthread_getattr_np`, but I don't know if there's anyone bothering with that, and it's a glibc extension.

.NET bothers with it, to support RuntimeHelpers.EnsureSufficientExecutionStack [1] and other things. See the pthreads calls used to here [2].

[1]: https://learn.microsoft.com/en-us/dotnet/api/system.runtime....

[2]: https://github.com/dotnet/runtime/blob/b6a3e784f0bb418fd2fa7...

If you have well defined boundaries, you can move the stack to an arbitrarily large chunk of memory before the recursive call and restore it to the system stack upon completion.

And if you never do reach completion, you can just garbage collect that chunk. AKA "Cheney on the MTA": https://dl.acm.org/doi/10.1145/214448.214454

> alloca() is super useful, but it's also quite dangerous because you can easily overflow the stack.

This is not a problem for Go, because it has resizable stacks.

Yes. How do so many people fall for this guy? I find him pretty creepy, to be honest.

Pretty sure he’s a complete fraud too. He associates himself with MIT despite only having had a short stint teaching non-credit classes. One of his papers was apparently so flawed it’s been wiped from existence. Plenty of info online if you want to go down the rabbit hole.

FWIW C++ has quite a few async I/O libraries that support io-uring. For example, ASIO has had a io-uring backend since 1.21 (late 2021).

Except Trump himself repeatedly claimed that the exporting country is paying the tariffs and that the US is earning billions of dollars. And many of his followers seem to believe this.

Trillions, in fact

https://www.forbes.com/sites/tylerroush/2025/08/31/trump-say...

Might be collecting lots of money as tariffs but they’re acting as a national sales tax. Defrays the cost of the tax cuts to some degree I guess.

Right, someone has to pay for these tax cuts eventually. The rich certainly won't.

Not in other languages. In German, for example, it would very weird to think of railroads (Bahn/Eisenbahn/Bahnstrecke) as roads (Straßen). Would you also claim that a hedgehog is a pig?

But autobahn is a road, no?

Yes, but "Bahn" actually means "track", "path" or "lane". "Bahn" in the sense of "railroad" is an abbreviation of "Eisenbahn" (literal translation: "iron tracks"). So "Autobahn" has nothing to do with railroad, it just means "car track".