toprerules

8 ms·

1.
by toprerules 1mo ago
So software engineers weren’t already dealing with requirements gathering and contextualizing a problem from real humans or describing work to be done to other people on their team? This isn’t leadership, it’s just communication. Suddenly r
2.
by toprerules 3mo ago
Your confusing concurrency with parallelism. Async allows one core to switch between many threads of execution that can do work and not stop one thread of execution because it needs to wait for a resource. It's beneficial to use async
3.
by toprerules 7mo ago
Writing code is cheap. Owning code is getting more and more expensive. SWEs sacrificed their jobs so that SREs could have unlimited job security.
4.
by toprerules 7mo ago
If the human race is wiped out by global warming I'm not so sure I would agree with this statement. Technology rarely fails to have downsides that are only discovered in hindsight IMO.
5.
by toprerules 7mo ago
I would have said the same thing a year or two ago, but AI is capable of doing deep dives. It can selectively clone and read dependencies outside of its data set. It can use tool calls to read documentation. It can log into machines and ins
6.
by toprerules 7mo ago
Staff engineer (also at FAANG), so yes, I have at least comparable experience. I'm not trying to summarize every level of SWE in a few sentences. The point is that AI's infallibility is no different than human infallibility. You m
7.
by toprerules 7mo ago
Same situation as when an engineer can't figure something out, they translate the problem into human terms for a product person, and the product person makes a high level decision that allows working around the problem.
8.
by toprerules 7mo ago
The question isn't whether businesses will have 0 human element to them, the question is does AI offer a big enough gap that technical skills are still required such that technical roles are still hired for. Someone in product can have
9.
by toprerules 7mo ago
The answer is the AI. It's already handling complex issues and debugging solely by gathering its own context, doing major refactors successfully, and doing feature design work. The people that will be held responsible will be the produ
10.
by toprerules 7mo ago
After working with the latest models I think these "it's just another tool" or "another layer of abstraction" or "I'm just building at a different level" kind of arguments are wishful thinking. You&#x
11.
by toprerules 9mo ago
Ah, I thought this was adding refinement types to Rust based on Liquid Haskell. Disappointed.
12.
by toprerules 9mo ago
I switched to mutt, started getting through my email in half the time in took me using a GUI, and never looked back. Being able to write simple expressions to filter email, mass delete, and avoid embedded javascript are killer features. I c
13.
by toprerules 11mo ago
This is an essential use case for XDP - this is how FB's firewall works, and above that their LB uses the same technology. The beauty of XDP is that it's all eBPF. Completely customizable by injecting policy where it's needed
14.
by toprerules 11mo ago
XDP is built into the kernel. DPDK is a huge framework that invasively bypasses the kernel and has to remain compatible as an external project.
15.
by toprerules 11mo ago
In the case of XDP, the reason it's so much faster is that it requires 0 allocations in the most common case. The DMA buffers are recycled in a page pool that's already allocated and mapped at least queue depth buffers for each ha
16.
by toprerules 11mo ago
DPDK is a framework with multiple backends, on the receive side it can use XDP to intercept packets. You can't compare the efficiency of the frameworks without talking about the specific setups on the host. The major advantage of XDP i
17.
by toprerules 11mo ago
I think the title is a little disingenuous and the idea of using a redirect is certainly not novel. The solution for XDP egress should be able to handle all host egress including sr-iov traffic. This works with a very specific namespace d
18.
by toprerules 11mo ago
I sincerely wonder how some people go around having 0 emotional attachment to any of their hobbies or passions - or maybe you're just extremely unfortunate and live your life completely focused on producing output for someone else.
19.
by toprerules 11mo ago
> there are teams already that absolutely do not hand-code anything anymore The only instances I've seen so far are from developers who are really, really bad at coding, but, under the false delusion of the Dunning-Kruger effect, be
20.
by toprerules 11mo ago
> Coding is the means to an end, not the end itself. For the early MIT hackers, and for many of us still today, it absolutely is. It's also not about the input mechanisms, which have changed over the years. Solving problems, turning
21.
by toprerules 1y ago
No one uses dtrace anymore. bpftrace is integrated into the kernel and can extract btf type information embedded into the kernel binary.
22.
by toprerules 1y ago
It sounds like you've only ever written code without dealing with it in production. You can't always plug your code into an IDE when your debugging someone else's JVM app on a remote server.
23.
by toprerules 1y ago
Because if I'm debugging a critical issues and wading through multiple layers of processes and system interactions, I don't want to have to learn a bespoke toolkit and debugging system for every single process.
24.
by toprerules 1y ago
That's a really narrow view of the world, and I think another Javaism to think that Java is the entire world. Today's multi-service deployments run tens if not hundreds of auxiliary processes not using Java. They use network overl
25.
by toprerules 1y ago
I admire Java as a success story, but I still have a deeply ingrained aversion to it for many reasons. I will admit that many of the reasons are due to Java's legacy as the language of bloated corporations, and its creation of overly v
26.
by toprerules 1y ago
Hard disagree, macros almost always lead the "too clever for you own good" even when the macro system is safe. Macros should always be used sparingly, and I think that Rust teeters on the edge of encouraging too much complexity fo
27.
by toprerules 1y ago
As a systems programmer I found Rust relatively easy to learn, and wonder if the problem is non-systems programmers trying to learn their first systems language and having it explicitly tell them "no, that's dangerous. no, that do
28.
by toprerules 1y ago
As systems programmer there are no better options. C is inherently unsafe, C++ is awful to work with and unsafe without careful use of pre-made safe abstractions that can't catch everything at runtime... I have written C for decades an
29.
by toprerules 1y ago
People in academia are notoriously disconnected from real software development, so I wouldn't use them as an example of what to do or not do. You can be judicious with your time without avoiding any inconvenience to accomplishing a goa
30.
by toprerules 1y ago
I use new tools all the time, almost on a weekly basis. Most of those tools have bugs, software isn't perfect. Our job is to be good at finding and fixing issues in tools, and the beauty of open source is having access to fix bugs were

More ›