[0]: https://i.pinimg.com/originals/c8/84/8e/c8848e81afa88a42bd4d...

Heh. Anyone remember the ping of death[0]? A lot (most?) of computers on the early internet didn't properly handle large packets, _especially_ from ICMP pings. Once upon a time, you could send a single ping w/ a packet size of 65536 and crash the remote.

[0] https://en.wikipedia.org/wiki/Ping_of_death

[0]: https://docs.python.org/3/whatsnew/3.14.html#a-new-type-of-i...

No, it isn't. Any decent datacenter will have on-site generation in event of power grid failure, anyway. When I was an intern, the company I worked for would routinely go off grid during the summer at a call from the electric company. The electric company actually gave us significant incentives to do so, because us running on our own 12MW generator was effectively like the grid operator farming out a 12MW peaker unit.

It's the same in the US. It's covered under CAT NMS (Consolidated Audit Trail, National Market System). Probably too much information at: https://www.catnmsplan.com/

Remember, it was originally release +20 years ago (goddamn, I feel old now); recorded video or even audio over the internet were much, much, MUCH rarer then, when "high-speed" speed internet for a lot of people meant a 56K modem.

Back then, most developer's first exposure to C# then was likely in either print form (books or maybe MSDN magazine).

HFT firms are (almost) always willing to buy or sell at or near the current market price. HFT firms basically race each other for trade volume from "retail" traders (and sometimes each other). HFTs make money off the spread - the difference between the bid & offer - typically only a cent. You don't make a lot of money on any individual trade (and some trades are losers), but you make money on doing a lot of volume. If done properly, it doesn't matter which direction the market moves for an HFT, they'll make money either way as long as there's sufficient trading volume to be had.

But honestly, if you want to learn about HFT, best do some actual research on it - I'm not a great source as I'm just the guy that keeps the stuff up and running; I'm not too involved in the business side of things. There's a lot of negative press about HFTs, some positive.

You can, but in the context of the standard, you'd be wrong to do so. Undefined behavior and unspecified behavior have specific, different, meanings in context of the C and C++ standards.

Conflate them at your own peril.

As someone who works in the HFT space: it depends. How frequently and how bad are the bad-trade cases? Some slop happens. We make trade decisions with hardware _without even seeing an entire packet coming in on the network_. Mistakes/bad trades happen. Sometimes it results in trades that don't go our way or missed opportunities.

Just as important as "can we do better?" is "should we do better?". Queue priority at the exchange matters. Shaving nanoseconds is how you get a competitive edge.

> I would posit is it things like network latency that would dominate.

Everything matters. Everything is measured.

edit to add: I'm not saying we write software that either has or relies upon unitialized values. I'm just saying in such a hypothetical, it's not a cut and dry "do the right thing (correct according to the language spec)" decision.

I was born after 1980 and I think you're beating a dead horse, here. You're conflating accessibility with convenience. Not just with this comment, but others you've made in this thread.

> those goddamn BIC pens all go bad (ink dries up or something), before I use even 5% of one of them.

Grab the pen by the end opposite the nib, give it a good shake for a few seconds, lick the nib, scribble on a scrap piece of paper until it starts writing again. Problem solved. You can't resurrect a dead laptop or computer by licking and shaking it (at least I've never succeeded in doing so).

edit to add: and yes `-isystem` is absolutely a useful tool. If memory serves, though, it doesn't protect from macro or template expansions, though.

Thank you! Separately, but related: fuck you, Google! (every time I have to deal with protobuf in C++, I curse Google and their "we don't give a shit about signed vs unsigned comparisons").

[0] https://www.ozonehouse.com/mark/periodic/

This has not been true since around 2.4 or 2.5. The oldest Python I have available to me currently is 2.7, and this holds then, as it does now in 3.13:

    >>> type(True)
    
    >>> type(1)
    

The reason something silly like `4 + True` works is because the bool type implements `tp_as_number` [0]. The reason it works this way is intentional because it would been a Python 3 str-style debacle if ints and bools were not interchangeable.

[0] https://github.com/python/cpython/blob/main/Objects/boolobje...

Uh...excluding the very recent cuts this year under Trump; the number of civilians in the US Federal work force has gone up fairly steadily. [0]

We had 23.592 million civilian employees in Jan 2025. 21.779M in Jan 2021, after being largely stagnant overall the previous 10 years. That's a net change in excess of 1.8M employees under Biden.

I do find it interesting that it appears that employee count was flat, or even down under Obama, but until COVID, there was a steady increase under Trump v1.

[0] https://fred.stlouisfed.org/series/USGOVT

I had something similar happen when I was taking microcomputers (a HW/SW codesign class at my school). We had hand-built (as in everything was wire wrapped) 68k computers we were using and could only download our code over a 1200-baud serial line. Needless to say, it was slow as hell, even for the day (early 2000s). So, we used a 68k emulator to do most of our development work and testing.

Late one night (it was seriously like 1 or 2 am), our prof happened by the lab as we were working and asked to see how it was going. I was project lead and had been keeping him apprised and was confident we were almost complete. After waiting the 20 minutes to download our code (it was seriously only a couple dozen kb of code), it immediately failed, yet we could show it worked on the simulator. We single-stepped through the code (the only "debugger" we had available was a toggle switch for the clock and an LED hex readout of the 16-bit data bus). I had spent enough time staring at the bus over the course of the semester that I'd gotten quite good at decoding the instructions in my head. I immediately saw that we were doing a word-compare (16-bit) instead of a long-compare (32-bit) on an address. The simulator treated all address compares are 32-bit, regardless of the actual instruction. The real hardware, of course, did not. It was a simple fix. Literally one-bit. Did it in-memory on the computer instead of going through the 20-minute download again. Everything magically worked. Professor was impressed, too.

Huh? This is not true.

    def foo(a, b, c): ...

    >>> def foo(a, b, c):
    ...     print(f"{a=}")
    ...     print(f"{b=}")
    ...     print(f"{c=}")
    ...
    >>> foo(1, 2, 3)
    a=1
    b=2
    c=3
    >>> foo(c=3, b=2, a=1)
    a=1
    b=2
    c=3
    >>>

Even with CPU bound code in Python, there are valid reasons to be using async code. Recognizing that the code is CPU bound, it is possible to use thread and/or process pools to achieve a certain level of parallelism in Python. Threading won't buy you much in Python, until 3.13t, due to the GIL. Even with 3.12+ (with the GIL enabled), it's possible (but not trivial) to use threading with sub interpreters (that have their own, separate GIL). See PEP 734 [0].

I'm currently investigating the use of sub interpreters on a project at work where I'm now CPU bound. I already use multiprocessing & async elsewhere, but I am curious if PEP 734 is easier/faster/slower or even feasible for me. I haven't gotten as far as to actually run any code to compare (I need to refactor my code a bit with the idea of splitting the work up a bit differently to account for being CPU instead of just IO bound).

[0] https://peps.python.org/pep-0734/