toprerules

You may want to consider learning how to debug software before writing software.

If they were both built by the same person then the answer is obvious, just use the free and open source one without built in telemetry.

Incorrect, many of them do, and make the determination that a few nice to have features doesn't outweigh the cost, lock in, and incongruence with the use of open source software where possible.

I know several world class developers who have invented corner stone technologies that use text editors without any plugins and just run the compiler in a separate window. It turns out that you actually are not held back by not having your hand held by an IDE, it was just a skill issue.

Nowadays I just use an LLM. None of these features are relevant anymore. Unless JetBrains has a proprietary LLM that is better at coding than what ever else is on the market (they don't) then there's no reason to pay money for their products.

I am not even particularly bullish on AI, but not seeing how LLMs have made IDEs irrelevant is like using Vim and crying foul about IDEs without trying one out.

Fedora uses more stock and Red Hat is a far, far bigger contributor to Linux and OS as a whole (especially the kernel and systemd). Fedora stays more true to the only OSS ethos. IMO Fedora is the better pick.

If I had to use Ubuntu I would fight to use Debian instead.

I've now watched people go from Sublime to Atom to VSCode to Cursor. Truly it's wild how much value I've gotten out of sticking with just Vim and occasionally trimming my config.

I have no desire to move to Neovim. The Neovim community seems hell bent on turning Vim into another Emacs kitchen sink style ecosystem where no one values moderation and everyone is installing 100+ plugins they don't need. I haven't seen a single Neovim feature that actually helps me get work done more efficiently than how I already do it with Vim. Neovim feels like the first step since ed where the lineage has truly gone in the wrong direction.

Just want to say everyone should be using podman. Its architecture is way more sane and integrates with Linux on a far more basic level (a regular process that can be started via systemd, etc. instead of a root daemon. Run it as root to get privileged containers).

They've also built an incredible ecosystem around podman itself. Red Hat has been absolutely cooking with containers recently.

It seems like out of Lynx, Links, and w3m, Lynx is the only one still under active development with a recent-ish release. w3m seems to be completely dead.

Oh yes, I'm with you. I didn't say I liked it. I am a low level munger and I like it that way - the lowest layers/oldest layers of the stack tend to be the pieces that are well written and stand the test of time. Where I see AI hitting is at the upper, devil may care, layers of application stack that will be an absolutely hellscape to deal with as a competent engineer.

You're missing the point, there are specific reasons why these stacks have grown in complexity - even if you introduce "API for AI interface" as a requirement, you still have to balance that with performance, reliability, interfacing with other systems, and providing all of the information necessary to debug when AI gets it wrong. All of the same things that humans need apply to AI - the claim for AI isn't that it deterministically solve every problem it can comprehend.

So now we're looking at a good several decades of us even getting our human interfacing systems to amend themselves to AI will still requiring all the current complexity they already have. The end result is more complexity not less.

People are absolutely insane with their takes on AI replacement theory. The complexity of our stacks has grown exponentially since the 70s. Very few people actually comprehend how many layers of indirection, performance, caching, etc. are between their CRUD web app and bare metal these days.

AI is going to increase the rate of complexity 10 fold by spitting out enormous amounts of code. This is where the job market is for developers. Unless you 100% solve the problem of feeding every single third party monitoring tool, logging, compiler output, system stats down to the temperature of RAM, and then make it actually understand how to fix said enormous system (it can't do this even if you did give it the context by the way), then AI will only increase the amount of engineers you need.

Awesome. AI isn't making Vim less relevant, it's now more relevant than ever. When every editor can have maximum magic with the same model and LSP, why not use the tool that lets you also review AI generated diffs and navigate at lightning speed. Vim is a tool that can actually keep up with how fast AI can accelerate the dev cycle.

Also love to see these local solutions. Coding shouldn't just be for the rich who can afford to pay for cloud solutions. We need open, local models and plugins.

That's every piece of technology. If this wasn't the case, we wouldn't have jobs. Resistance to change on the basis of "it will cause more problems" halts all technological progress. If you think you can do better, show. me. the. code.

100% of people who dislike systemd can't come up with a better solution that solves all of the problems that systemd was created to solve.

The best config system I've ever seen used plain old Python to generate static configs. Everyone knows Python. Python is easy to do data munging in, as demonstrated by it's popularity as the #1 data science tool. There's boundless libraries to make Python more functional, use stricter typing, or reduce the amount of side effects it can cause. Even Starlark is just a dialect of Python.

You can spend decades building a complicated configuration language, use a bespoke functional language as Mill does, but if you're a single company that can enforce code quality and just wants to get the job done, I feel like everything else is just unnecessary and over-engineered to scratch some academic itch for a "better system" that enforces "purity" at the cost of velocity.

I also think that now that LLMs are on the rage, how much context do you think they have for bespoke config language vs Scala vs Python? I think we know the answer to that one.

I don't use DAP so I can't help you there. I use vim for editing code. When I need to debug I run lldb or gdb in a separate tmux window, if I need to see the code I enable TUI mode. There are many wrappers including TermDebug, Vimspector, termdbg, etc. to add visual breakpoints, but I have never found them necessary - because again gdb/lldb can already show you the code in various formats including assembly. It sounds like you are using Pycharm in exactly the same way you can already use a standalone debugger.

For Python I find a built in debugger especially unnecessary. Most interpreted languages have a debugger that can be triggered from the source code to drop into an interpreter, and Python is no exception - see pdb and breakpoint().

Can't really say enough good things about Vim. I retired early as a staff software engineer because of the work I did using Vim. From hacking silly games in C in high school to now, I've always been able to use Vim and run circles around any "modern" text editor or IDE. I feel like I owe Vim as much public praise as I can give so others can reap the rewards like I did.

What really frustrates me is how little people seem to want to invest in their tools, or the outright lies they tell themselves about how much configuration they need to use Vim on a daily basis. My Vim config is 200 lines, and my last commit was 3 years ago. I've invested maybe a few days of my life into configuring Vim and I use it 8-16 hours a day.

Vim can do so much on its own. It has autocomplete, fuzzy finding, integration with build systems, file search, navigation using a directory browser, jump to symbol, parse compiler output to jump to bugs, support for gdb and breakpoints, a built in terminal, copy to and from the system clipboard, and with literally 8 lines of code you can get support for every linter, LSP, etc. known to man, fuzzy finding, and git integration that let's you use native git commands with seamless editor integration.

Technology has diminishing returns. If technology does everything for us then what's the point of existing.

In what way is a hammer an intellectual tool?

It sounds like your perception of how a computer works is incredibly flawed. ram doesn't sit unused, the kernel uses it for caching and locality. The more RAM you give the kernel, the more you can have resident in the slab cache, the page cache, the filesystem cache, the network backlog, etc. Even on very large machines with more RAM than an average desktop, the kernel can still make use of almost all of it.

I work on efficiency so when people say things like "it's ok for my IDE to be an inefficient pile of garbage that locks up resources" it makes me wonder what kind of program they are producing.

I'm a Vim user, but I occasionally try JetBrains/VSCode to see what I'm missing out on and RustRover, CLion, Goland etc. are by far the most sluggish pieces of software I've used. I am demonstrably slower on them than using Vim with my fuzzy finder, LSP, and AI integrations.

I thought Fleet might add the "magic" to something more VSCode like, but I also don't understand the long term vision.

I don't tinker with Vim. I wrote my config many years ago and I touch it maybe once every few years. Otherwise it's completely rock solid.

I also find it highly amusing when people talk about needing to get work done and Vim, I mean I didn't get staff at one of the highest paying, hardest companies to climb at because I was sitting there tweaking configs instead of having impact. Vim lets me have impact by getting out of my way and letting me do precisely what I need to do wherever I need to do it.

I've reached a level (staff engineer at MAANG) that I consider to be difficult to obtain using plain old Vim, and I've noticed that other high performers tend to still use Vim or Emacs. There's plenty of amazing developers who use VCode, JetBrains, etc. but I think there are certain personality traits - seeks out barriers to entry, likes to demagic tools through exploration, values completely open source, highly tinkerable community driven projects, etc. that explain this phenomenon more than feature set or ease of use.

When I read about how complicated VSCode's remote editing was (which I knew about before this article) it just made me want to use VSCode less. I can just ssh into a machine and use whatever editor is on the machine. VSCode's solution works, but it's also not nearly as elegant or universally applicable, and is more prone to breaking.

Also, Tramp is still quite awful, sorry Emacs users (netrw isn't any better).

This must be your first hype cycle then. Most of us who are senior+ have been through these cycles before. There's always a 10% gap that makes it impossible to fully close the gap between needing a programmer and a machine doing the work. Nothing about the current evolution of LLMs suggests that they are close to solving this. The current messaging is basically, look how far we got this time, we will for sure reach AGI or full replaceability by throwing X more dollars at the problem.

As a systems programmer, Rust has won. It will take decades before there is substantial Rust replacing the absurd amounts of C that runs on any modern Unix system, but I do believe that our of all the replacements for C/C++, Rust has finally gained the traction most of them have lacked at the large companies that put resources behind these types of rewrites and exploratory projects.

I do not think Zig will see wide adoption, but obviously if you enjoy writing it and can make a popular project, more power to you.

As a fellow "staff engineer" LLMs are terrible at writing or teaching how to write idiomatic code, and they are actually causing me to spend more time reviewing than I was previously due to the influx of junior to senior engineers trying to sneak in LLM garbage.

In my opinion, using LLMs to write code comes as a faustian deal where you learn terrible practices and rely on code quantity, boilerplate, and indeterministic outputs - all hallmarks of poor software craftsmanship. Until ML can actually go end to end on requirements to product and they fire all of us, you can't cut corners on building intuition as a human by forgoing reading and writing code yourself.

I do think that there is a place for LLMs in generating ideas or exploring an untrusted knowledge base of information, but using code generated from an LLM is pure madness unless what you are building is truly going to be thrown away and rewritten from scratch, as is relying on it as a linting, debugging, or source of truth tool.

You can do this without needing a terminal aware tool. There are tools, and it's easy to write one yourself, that tee buffers the output of every command you run, then pipe the last command into your AI tool. You could also easily support N command buffers.

Then you don't need to be locked into using iTerm2.

Why would you favor this approach over say, a command line tool that can pipe input into and out of a configurable AI backend, fork subprocesses to perform agent based tasks, etc. The amount of tokens is always bounded by what the user chooses to pipe into the tool. The Unix model is battle hardened, time tested approach. This tool seems like it locks you into iTerm2.

I feel like 95% of the developers who are touting AI are doing web dev or app development - a field which has low stakes, low barrier to entry, and an incredible amount of reinventing the wheel - all things that an LLMs is naturally going to excel with. I can't imagine you'd hold these same beliefs if you were writing control software for a life saving medical device where a single bug could kill someone, where the board package is proprietary and not understood by an LLM, and the thing is written in a C dialect combining only half the features of C99 with a subset of obscure compiler flags.

That's just it, I try not to write the boring parts at all. That's what libraries and design pattern are for - avoiding writing boilerplate.

I certainly can see it being useful for writing additional tests, although I am very worried based on what I've seen that it will introduce more bugs than it's worth, which is why it's still a tool I use for hobby projects and not for real work.