fleventynine

At the end of the day, I'm being paid to ensure that the code deployed to production meets a particular bar of quality. Regardless of whether I'm reviewing code or writing it, If I let a commit be merged, I have to be convinced that it is a net positive to the codebase.

People having easy access to LLMs makes this job much harder. LLMs can create what looks at the surface like expert-written code, but suffers from below-the-surface issues that will reveal themselves as intermittent issues or subtle bugs after being deployed.

Inexperienced devs create huge commits full of such code, and then expect me to waste an entire day searching for such issues, which is miserable.

If the models don't improve significantly in the future, I expect that most high-stakes software teams will fire all the inexperienced devs and have super-experienced engineers work with the bots directly.

I upgraded to this exact CPU from a 200MHz pentium in the fall of 2000. Easily the largest jump in performance of any upgrade I've ever done.

Another impressive early HDTV example:

https://youtu.be/eMefy5VK9TI - Toto, Montreaux, 1991

There are some reasonably affordable models like https://www.lcsc.com/product-detail/C5272996.html that are powerful enough for many tasks.

> Can’t offload everything into the compiler. It is already too slow.

Speak for yourself. On embedded platforms I'd happily make my compiles twice as slow for 10% code size improvements.

When looking at the rv32imc emitted by the Rust compiler, it's clear that there would be a lot less code if the compiler could choose different registers than those defined in the ABI for the arguments of leaf functions.

Not to mention issues like the op mentions making it impossible to properly take advantage of RVO with stuff like Result<T> and the default ABI.

Rigid ABIs aren't necessary for statically linked programs. Ideally, the compiler would look at the usage of the function in context and figure out an ABI specifically for that function that minimizes unnecessary copies and register churn.

IMHO this is the next logical step in LTO; today we leave a lot of code size and performance on the floor in order to meet some arbitrary ABI.

Rustc does a good job of removing unused code, especially with LTO. The trick is to make sure the std library main/panic/backtrace logic doesn't call code you don't want to pay for.

IIRC there's also a mutex somewhere in there used to workaround some threading issues in libc, which brings in a bespoke mutex implementation; I can't remember whether that mutex can be easily disabled, but I think there's a way to use the slower libc mutex implementation instead.

Also, std::fmt is notoriously bad for code size, due to all the dyn vtable shenanigans it does. Avoid using it if you can.

Regardless, the only way to fix many of the problems with std is rebuilding it with the annoying features compiled out. Cargo's build-std feature should make this easy to do in stable Rust soon (and it's available in nightly today).

The Rust standard library in its default config should not be used if you care about code size (std is compiled with panic/fmt and backtrace machinery on by default). no_std has no visible deps besides memcpy/memset, and is comparable to bare metal C.

> This means there's no target too small for the language, including embedded systems. It also means it's a good choice if you want to create a system that maximizes performance by, for example, preventing heap allocations altogether.

I don't think there's is any significant different here between zig, C and Rust for bare-metal code size. I can get the compiler to generate the same tiny machine code in any of these languages.

It's still above where it was a few weeks ago. I don't see why this is news.

"My attention is a limited resource. In order to prove that you're a serious human, please donate exactly $157.42 to the Rust maintainers fund and paste the receipt link here".

No mention of 120Hz; I'm waiting for a 6k or higher-density display that can do higher refresh rates.

Non-systems languages still need to interact with systems languages, over the network or directly. The lack of unsigned types makes this way more painful and error-prone than necessary.

> If you call a method which returns an unsigned int, how do you safely pass it to a method which accepts a signed int?

The same way you pass a 64-bit integer to a function that expects a 32-bit integer: a conversion function that raises an error if it's out of range.

Still no unsigned integer types in the standard library after 26 years?

I don't know about gifted programs, but anything that separates kids who don't want to learn from those who do is a good thing; far to much time is wasted in America's schools catering to bad behavior.

Yeah, I think to make a system using this really scale you'd have to add support for this protocol in your load balancer / DDOS defenses.

Does anyone know what it looks like when you use a line scan camera to take a picture of the landscape from a moving car or train? I suspect the parallax produces some interesting distortions.

Because i can produce 5 clean, properly sized commits in the time it takes to do one round of reviews, so they have to be stacked. It's important that the CI run independently on each commit, and each commit builds on the work of the previous one.

> Are there any improvements to be done to Git?

Github's workflow for stacked PRs is still terrible. There's plenty of room for improvement.

I've had a lot of success writing driver test cases against the hardware's RTL running in a simulation environment like verilator. Quick to setup and very accurate, the only downside is the time it takes to run.

And if you want to spend the time to write a faster "expensive mock" in software, you can run your tests in a "side-by-side" environment to fix any differences (including timing) between the implementations.

Historically, the price difference between MMF and SMF transceivers was greatest at the highest speeds. That doesn't seem to be the case anymore for short-range transceivers.

Apples to oranges. SR is for short runs inside a building. LR is for sending signals across a city.

For short runs inside a building, the transceiver prices are much more comparable. Compare https://www.fs.com/products/251819.html?now_cid=4089 to https://www.fs.com/products/282973.html?now_cid=4089

Multi-mode transceivers used to be a lot cheaper than single mode, but now they're around the same price for short distances. From what I can tell, most datacenters appear to be making the switch to single mode even for in-room networking.

> The difference is private companies that accumulate too much waste and useless things can fail and be replaced.

Unfortunately, there isn't enough competition for this to be true. In many markets the largest incumbents are able to build a moat to stop smaller, smarter companies from competing. Sometimes this is regulatory capture, but it can also be that the market is a natural winner-take-all market, and in that case well-thought-out regulation can be necessary to enforce competition.

Venture capitalists shy away from funding companies that want to compete in a well established market. They view it as a race to the bottom with no huge payout.

Once a company is large and well established, it can be as bloated and inefficient as any government, and it will extract rent with it's IP, real-estate, and means-of-production for decades before it has to worry about failure.

With the sheer volume of local exploits found in the Linux kernel, I don't really consider these SELinux/AppArmor mitigations to be that useful. Sure, they reduce the attack surface a bit, but if I actually need isolation between workloads, it's best to do it below the kernel (with a VM).

If an attacker gets execution in userspace, it's best to assume they can also get into the kernel via some 0-day local privilege escalation...

With 64 XGS-PON customers per SFP+ module, the only active equipment you need to terminate connections for over 60,000 customers fits into a single rack. Large centralized buildings are largely obsolete unless you want to offer services beyond basic Internet access.

Geforce 256 and 2 were fixed-function; I don't believe the first shaders showed up until Geforce 3.

Because of this mismatch there aren't many young folks with these skills; expect these salaries to flip around once most of the experts retire.