Now imagine that he's interested in finishing his game, not the intricacies of raycasting algorithms.

Idk, depends on the situation. Is he a student trying to show stuff on a resume? Is he a professional trying to sell a product? Is he a researcher trying to report findings? A startup trying to land a pitch?

The value isn't objective and very much depends on end goals.People seem to trounce out the "make games, not engines" without realizing that engine programmers still do exist.

It was just a small personal test of skill with no purpose or stakes. Not even really with intent to make a real game, just a slice of something that resembled a game to see how far I could get without help. Then, once I got as far as I could, research and see how I could do better.

got to have a password manager password, and a login password

Write that down on a piece of paper.

Oh, you must mean [email protected].

I used to have [firstname]@gmail.com when gmail was in beta. They took it back when they went live :(

American jurisprudence has the best standard for incitement in the world, the Brandenburg standard: imminent lawless action. "Imminent" is vital, and unique to America; the government is barred from constructing hypothetical situations around acts of speech to prosecute them, as is easy to do with quite a lot of speech.

And we only reached it in the 1960s! Freeing speech is always an active fight.

Yeah, the trusty manual becomes #1 at around the same time as one starts actually engineering. You've entered the target audience!

These days, I often just go straight to the source (when available) to clear some confusion about the library/software behavior. It can be a quite nice 10 mn break.

I'm interested in the claimed real-time capabilities, but it's hard to find anything about them written there. Still, I like the hardware integration.

Real-time is some of the most misused jargon in modern history.

In general, most JIT or VM can't even claim guaranteed latency. People that mix these concepts betray their ignorance while seeming intelligent.

FreeRTOS is small and feasible.

VxWorks if your budget is unconstrained.

LinuxRT kernel (used in LinuxCNC) with external context clocking, and or FPGA memory DMA overlap module (zynq SoC etc.)

Real-time is a specialized underpaid area, and most people have too abstract of an understanding of hardware to tackle metastability problems. =3

yeah the claim is ambiguous because the beam itself is only guaranteed soft real time, leaving it open ended might make ppl think hard real-time especially since its hardware

They support writing RTOS tasks in C as I understand it.

Do you actually think dead simple failover is comparable to elastic kubernetes whatever?

> Do you actually think dead simple failover is comparable to elastic kubernetes whatever?

References to "elastic Kubernetes whatever" is a red herring. You can have a dead simple load balancer spreading traffic across multiple bare metal nodes.

Thanks for switching sides to oppose yourself, I guess?

> Thanks for switching sides to oppose yourself, I guess?

I'm baffled by your comment. Are you sure you read what I wrote?

The predictable cost, you mean, making business planning way easier? And you usually have two, because sometimes kernels do panic or whatever.

People will have to come up with something else besides "le acronym from le computer makes my domain sound le computery, even though there is no cognizable relationship to I/O whatsoever", I guess. (Just kidding, it'll be around forever)

No it isn't, their strategy is great at increasing the rate at which they select those deadly "bad hires". There's just an insane amount of risk in doing these sorts of tech interview things; code up a quick monte carlo simulation to convince yourself if you like. It's just that the risk doesn't fall on the improperly aligned humans conducting the interview, it's offloaded onto the company.

Exactly, you could just as easily hire a bad candidate because they got lucky, and this happens all the time.