toprerules

What kind of code/projects do you work on?

I feel like I'm taking crazy pills, because every time I try to use AI for any of my projects - including the "better" Anthropic and OpenAI models, I get terribly written, buggy code that has nothing to do with the domain or question. Unless I'm feeding it actual softball, single function questions it adds almost no value to my dev cycle. Mind you, all of this terrible code also costs a ton in tokens.

It's sad because I have seen some truly remarkable progress in LLMs, but I feel like we aren't allowed to be honest anymore that LLMs aren't going to replace programmers or moderate our expectations.

As someone who has worked at a few of the FAANGs, having thrift/grpc is a godsend for internal service routing, but a lot of the complexity is managed by teams building the libraries, creating the service discovery layers, doing the routing etc. But using an RPC protocol enables those things to happen on a much greater scale and speed than you could ever do with your typical JSON/REST service. I've also never seen a REST API that didn't leak verbs. If I need to build a backend service mesh or wire two local services together via an networked stream, I will always reach for grpc.

That said, I absolutely would not use grpc for anything customer or web facing. RPC is powerful because it locks you into a lot of decisions and gives you "the one way". REST is far superior when you have many different clients with different technology stacks trying to use your service.

Your house a single failure domain, you're not really going to be resilient to a lot of common failures, and most of these home labs have every device plugged into the same UPS, so there's really no difference between the power failure domain of 10 Pis and one desktop computer plugged into a UPS connected to your home router.

Do yourself a favor and buy a NAS and a compatible UPS. Any modern NAS software will speak one of the UPS IP protocols to handle graceful shutdown if your power goes off. Once you have the money, buy a second NAS and put it in a relatives house, set up a wireguard/tailscale tunnel between the two devices, and use it for offsite backups.

You can buy a Synology NAS for less than the cost of this rack and it will do everything this rack can do including running containers. You can build your own NAS and run Unraid or FreeNAS or what have you for even less.

I suppose. You could also use a single desktop and set up your own virtual network bridge, attach multiple veths connected to separate network namespaces, or attach tun devices with virtual machine images running raspberry pi os under qemu, set up DHCP for their virtual mac addresses, set up routing tables, and save yourself some money and time inserting raspberry pis into a pre-built rack. Learning how to set up a rack of servers can be done for free if you already have a Linux machine.

The one thing I don't understand about these Pi based mini-racks is why you would build a home lab that's less powerful than your client devices. My 24 U rack exists precisely because I want on demand, large amounts of compute/GPU for compiling, transcoding, encrypting, etc. and the cloud is too expensive. If you're going to make the investment into any type of home labbing, why gimp yourself with devices that can only run small services you could run on a single old desktop using containers?

You’re missing the whole point of an immutable distro. If you have a hobby project on a regular distro, you run apt-get update or whatever, it installs 200 packages and half of them run scripts that do some script specific thing to your machine. If something goes wrong you just bought yourself a week’s worth of debugging to figure out how to roll back the state.

If you update using an immutable distro, you rebase back on to your previous deployment or adjust a pin and you’re done. Immutable distros save you tons of time handling system upgrades, and the best part is you can experimentally change to a beta or even alpha version of your distro without any fear at all.

You don’t understand what immutable distros are for. Imagine you need to upgrade 500k machines and your options are either run an agent that has to make the same changes 500k times and hopefully converges onto the same working state no matter the previous state of the machines its running on, or you pull a well tested image that can be immediately rolled back to the previous image if something goes wrong.

Saying it’s just about integrity is like saying docker images are just about integrity… they absolutely are not. They give you atomic units of deployment, the ability to run the same thing in prod as you do in dev. Many other benifits.

The whole point of ostree is that your systems image has a minimal amount of stuff in it, a la you’re only doing upgrades when there is a kernel update (which is essentially impossible to avoid rebooting for no matter what OS you’re using, even SerpentOS the other commenter linked can’t do kexec updates).

You use something like distrobox to use a rolling release with regular package updates on the atomic core.

There’s a lot of comments in here about desktops, but IMO why even discuss Linux on the desktop… 99.9999% of Linux deployments are not Arch installs on old Thinkpads. Immutable distros *are* becoming a de-facto standard for server deployments, IoT devices, etc. They improve security, enable easy rollbacks, validation of a single non-moving target for systems/hardware developers…

There’s also been a ton of very advanced development in the space. You can now take bootable containers and use them to reimage machines and perform upgrades. Extend your operating system using a Dockerfile as you would your app images:

https://github.com/containers/bootc

First, you don’t have full control of your system. Your system is running an unknown amount of code as binary firmware blobs even if you’re using a completely open source kernel. Hopefully you’re compiling every package yourself and not using pre-compiled binaries from your distribution’s repositories.

Second, immutable distros are primarily a distribution and update mechanism that vastly improves the current model of running X number of package updates and scriplets on every machine and hoping it works. There’s nothing that stops you from remounting a filesystem as rw at least on any of the distributions that I know of. There’s also plently of stateful, rw holes for data and configuration on “immutable” distros.

Somehow they are adding RHEL, but not Fedora which what the majority of WSL users would want to use.

I also end up avoiding python not because it's a bad language, but because it's so much more convenient to work with compiled artifacts that worry about shipping around a bunch of source or object files and a full compiler. Not to mention the speed of using Go and the ability to write concurrent code without a lot of effort.

The only time I really use python is when I need a quick and dirty script.

> Let's remember, they likely don't know how to use the terminal either these days.

Which is a huge issue. If all you know how to do is crank up a GUI and write code, you are easily replaceable in a world where the demand for SWEs has gone way down. The best thing I ever did in my career is invest in learning how things actually work. Learning how something like Vim works is just a litmus test for absorbing and applying information quickly. Vim is just one in hundreds of tools I've learned how to use and string together.

You can do all the things you mentioned in Vim. I also can't imagine that you would be comparing the performance of VSCode and Vim, my vim with all of its plugins and vim script starts up in 95ms. That's faster than the threshold of human perception.

I think you missed the point of my comment you are replying to. You can get things done in any editor. The point is that Vim/Emacs have been around for decades and last your whole career, VSCode has been around for a fraction of the time and killed off the previous editor, Atom, that everyone though was "the editor".

I'm already seeing this as part of my mentoring work. It's very problematic.

Those developers frankly sound like idiots, I don't think they should be coding at all. Also yes, all of those things are easily done in both vim and emacs.

What tools, what helpers? I hear this comment a lot and it's just ignorance on the part of people who clearly have never tried to actually learn how to use (Neo)vim or Emacs. I've used Jetbrains, VSCode, Atom, Xcode plenty and there's nothing that I can do in those IDEs that I can't do in Vim besides things related to platform specific SDKs.

I'm an OS developer and in my view using printf is like seeing only half the world at once. There's a whole world of platform specific decisions that are made at compile time and runtime that you can only see through the lens of a good assembly debugger.

You're also talking about debugging apps running comfortably in the idillic world created by the OS. It's much harder to debug foundational pieces with printf's when the program immediately panics or early printing isn't available.

In my opinion it's good to build habits that can be generalized to all sorts of software and not limit oneself to writing code in a highly structured environment where most of the work is done for you. I can trace through a program faster than someone can insert/remove printfs and recompile their program, and I don't need to think about what to print. I can look at everything at that point in time, covert data to strings, look at the stack, registers, etc. Very powerful stuff.

I've seen so many editors come and go, and yet I've been using Vim for the past 20 years and have never had a problem. As stupid as it sounds, if I could give one piece of advice to any entry level SWE, it would be to learn Vim or Emacs and just stick with it for your whole career.

Ok, but now every time you switch commits you have to wait for clangd to reindex. Grepping in the kernel is just as fast and you can do it without running a 4GB+ process that takes 10+ minutes to index

Your argument is a false dichotomy and thus a logical fallacy. Not all steps forward in abstraction or code generation are necessary good steps and have to be considered on their own merits. If LLMs are indeed superior, then you should be able to articulate their merits without condescending to fallacious attacks.

I mean, what's holding you back from using neovim? Great plugins, same LSPs, anything that's missing you can code up yourself in Lua, works over ssh... what are you really gaining by using VSCode?

So what are your general thoughts on Rust? Would you use it again? How does it compare to using C or C++? Did you enjoy working in it? What was disappointing/motivating about the language?

I love seeing grpc grow. An rpc system with a schema and code generation is a must for internal services. Grpc has worked really well for me.

This is true for languages that try to be all things to all people (a la Java). All languages are DSLs, and if you target just a few specific domains and beat back the masses who want the language to expand beyond its intended purpose, than simplicity remains possible.

When I first came to React my understanding was that React/Flux were all but a package deal, and that I better use Redux because it seemed so popular. Redux quickly became a pain point in terms of boilerplate and added cognitive load. Now a top level stateful component works for 90% of my use cases.I feel the same way about React Router. Maybe if you're building something quite large or complex these prepackaged tools make sense, but I personally have gone the way of Golang and started to prefer a little copying over adding an extra dependency and I've found that React is wonderful by itself. I encourage anyone who will listen to try ditching Redux in favor of a single top level stateful component.

But by pushing complexity into third parties, the vast majority can benifit from a smaller spec and less cognitive load. It's a trade off for sure, but I think as a language designer you have to be careful not to let the 1% convince you that the 99% needs x feature. There are tons of existing Go projects that are working just fine as is. How many of them really need more than what exists already?

The similarities are striking. Both have a problem with undocumented or experimental modules for everyday tasks, both use compiler plugins to make sure that every package is using its own superset of the language (although in Rust this only applies to nightly), both tout lofty goals while rarely producing production grade systems. Rust is the first toe dip into the world of blog posts heralding the"coming of the age of reason" when we all see the error of our ways for writing dangling pointer references and impure functions. To be a complete cynic, I hope Rust runs right away from over generalized abstractions and the Haskell indifference to achieving real success by overcomplicting even the most mundane of problems.