It's crazy to me to think that I was hoping to move my home network to 10GbE in the next few years, around 2006-2007... Twenty years after most home networking is still at the 2005 level of a 30€Netgear GS108

The future is here. https://www.balticnetworks.com/products/mikrotik-crs304-4x-1...

Wifi got insane upgrades over that time. Wifi 7 is usually faster than most ethernet setups now.

In throughput but not in latency, and especially not in variability

> If you add exceptions to a library that didn’t previously use them then I almost definitely have to update my code.

No, that's the whole point. You let them bubble up to the top of the event loop and you report the error to the user. As a user, anything else leads to shitty software where the programmer tries to outsmart the world around them (and fails, obviously, leading to worse end-user experience than just admitting that you don't and can't have control over everything)

What user? I work on systems where there might not be a keyboard or a mouse or a display and where the use of there is one doesn’t care that the “flooblutz was out of turving.” The only thing stack unwinding gets me is it forces me to restart my program from the beginning.

^^^ truth speaker

Addendum: I, for one, have used software that would constantly show exception-related error message dialogs.

Hell, I'm forced to use such software at work because we're (at least for now) stuck with a horrible legacy vendor.

It is not fun. So, no, "just show it to the userand let them decide" doesn't actuality resolve anything either.

> If you crash from an unhandled exception, you don't.

.. you absolutely get a stack trace from unhandled exception in c++, that starts where the exception is thrown? At least with clang and GCC, maybe MSVC isn't able to.

foo.cpp:

    #include <stdexcept    
    void bar() { throw std::runtime_error("boo"); }
    void foo() { bar(); }
    int main() { foo(); }

running:

    $ g++ foo.cpp -std=c++23 -g
    $ ./a.out
    terminate called after throwing an instance of 'std::runtime_error'
      what():  boo

    $ coredumpctl gdb
    ...
    #7  0x00005555555551bb in bar () at foo.cpp:3
    #8  0x00005555555551da in foo () at foo.cpp:4
    #9  0x00005555555551e6 in main () at foo.cpp:5

it's a basic example, but it's how I've always done all my debugging in C++ since forever

Sure, in a desktop program you do. In embedded exceptions are a scourge because they crash your program until someone can get back out there to power cycle it. At least with return-codes you can continue execution even if you failed to effect the change you wanted. If that was ancillary to the system’s core function then the system keeps running.

Pretty sure esp32 just rebooted automatically when unhandled exception is thrown for instance

It's crazy for me to think that people cannot see how wrong it is from the normal speed video. For me it's obvious and infuriating, it physically feels like it's punching my retina

> If you can deliver the same thing in fewer correct lines of code

it really depends on what you're doing. If your goal is "become interoperable with the N different and incompatible network protocols that people have devised for doing task X" I'd really like to know a solution that doesn't have at least some part of the amount of code that scales with N.

Example: consider https://bitfocus.io/connections which connects to 700 different things. Right now it's written with Node.JS, with one repo per connection (example: https://github.com/bitfocus/companion-module-meyersound-gala...). Let's say you want to make a similar product but that runs on ESP32 where performance is paramount so you need C++ or Rust. How do you do that without at least as many lines of code as the existing JS implementations for every system supported by Companion?

Without looking at the details, I expect that each network protocol has a checksum of some form, and there are likely a lot less than N different checksum algorithms. Similarly I expect several will have encryption - using one of a few standard algorithms (if any doesn't use a standard algorithm you have a strong case to say not supported). I also expect that there is a lot of protocol parsing - this can be done as custom hand coded for each, or using a parsing framework (and likely there are some places of generic code in between).

Parent said "I'd really like to know a solution that doesn't have at least some part of the amount of code that scales with N."

You're arguing the inverse: that at least some parts of the code are independent of N. Sure. But the topic is the part that isn't.

This is still not an argument for more lines of code. It demonstrates that lines of code are positively correlated with number of features, yes. But that's like saying the number of nails scales with the size of a house. More nails does not create more house.

> More nails does not create more house.

sure, but less nails definitely prevents you from having more house

Japanese carpenters would like to have a word.

Apparently roughly ~150k math PhDs live on earth right now, assuming they all know Lean that's between 0.001% and 0.002% of earth population so quite closer to no one than one

Allowing closed-source to exist is always the less moral choice for many reasons (one example being ecological sustainability)

> How fast do you want your slideshow to be?

we're in 2026, 240hz screens are becoming common. Nothing in the end-user experience should take more than 3-4ms. My personal goal when developing is keeping things at at least 60FPS and ideally 120 when building the whole stack with ASAN / UBSAN / stdlib's debug modes.

For instance when looking at this the first thing I thought was to try to make an installation which permanently recurses the codec's application on itself at each frame, to give the impression of a constantly moving landscape. Impossible on a smaller machine if computing a single frame takes 150ms.

That's fine reasoning for video, but if someone is actually looking at a still picture for more than 1/240th of a second, the fine detail matters a bit more. These are different applications, with different sweet spots in the time/quality trade-off.

would be great to have the weights somewhere

or maybe erlang / elixir do not have 1/1000th of the libraries and features available to C++ thus it's more efficient to port what can be ported? would you rather have the whole of C++ ported to erlang?