ilovecaching

Reminder that neovim is completely free, you can modify the editor using Lua, it has a renaissance of new awesome plugins, LSP support for the official Rust LSP server, and as a system developer you can run it on a target device or quickly switch between a serial console and your editor using tmux. Plus, you can easily add new LLM integrations or wrap tools in about a half an hour of hacking. My neovim setup is easily 10x more productive than RustRover.

Long term I think bootc containers will win the war. It has better backing and the weight of Podman behind it. Sysext will likely play a role, but I think flatcar is a losing horse.

The grass is always greener. Rust also has rough edges and there's maybe a fraction of a fraction of a percent of Rust code out there to work on in the corpus of systems software, and a lot of it has to interface with C anyway. Even crates in Rust are overly complicated and they've set up a system that allows people to squat on well known names.

I think if you want to work on systems software you should enjoy working with legacy cruft, otherwise you're just going to be miserable. I mean it's everywhere from the language, to the POSIX APIs, to device drivers, to hardware quirks... C++ is only a quarter of the problem.

I primary write Rust/C for a living, but I would pick Go in any situation if I could. I understand Rust's appeal as a shiny spaceship, but it adds a lot of complication for not enough benefit if you can use a garbage collector. Why deal with boxing, lifetime annotations, and async when you could just write plain Go.

Go is easier for onboarding, it's fixed the major issues people have had with it - it has modules, it has generics. It's easy to package a binary versus deal with having a Python venv.

Go is just the best common denominator and that's what the majority of people need. I really feel that people want to use Rust because it's interesting and fun, not because it's really the better tool for the job. The vast majority of applications can use GC and are not resource constrained by Go's runtime or binary size.

I don't think the onus is on the original project to maintain compatibility with a fork. Neovim made it pretty clear from the beginning that they were going to fracture the ecosystem and now we have colorschemes in Lua that can't be used in vim... say what you will about Emacs, but at least all of their distros can run the same code.

From my perspective as a vim user, neovim has only made my life worse by splitting plugin authors into two camps without any real benefit over what we had in vim. The only good thing about neovim is it caused some nice features to be added to vim, which the neovim authors could have just contributed themselves without trying to fight for control of the ecosystem with Bram. Neovim has really just made things worse for everyone.

And forks diverge... in the case of neovim by tens of thousands of LoC. In what way is forking a stable product a guarantee that the fork will remain stable?

I use default vim, I believe it was a mistake to fracture the ecosystem with plugins that can only be used with neovim. I have also not found any neovim functionality that sells neovim over vim. Vim is fast enough that I have never even thought about it's speed. With term, termdebug, fzf, ripgrep, and ALE with LSPs and Vim's excellent built in support for auto-completion, tag browsing, and cscope, there's really nothing I can't do in another editor I can't do faster in vim and as a bonus I find that I know more about regular expressions than most IDE programmers.

I've had one vanilla vim breakage in over a decade of use. A common pattern I see that inhibits vim usage is:

- Using too many plugins without understanding all that vim has to offer.

- Cargo culting configs instead of building up little by little.

- Trying too hard to rice vim in appearance without adding meaningful utility.

The same applies for Emacs. Vim and emacs are powerful editors not controlled by corporations, have succeeded for decades when other editors have floundered, can run in any basic computing environment/terminal, and are logically present in many Unix tools. Like all of software engineering, a deeper understanding of the system you're using pays huge dividends in the long run.

In short, take the time to learn one of these editors in it's basic form and then nurture a small config that can go a long way, and you will find success.

I'm not sure what company you're working for where generating code that may or may not be correct and needs careful analysis is somehow increasing your coding velocity to the point where it's trumping higher level thinking or protecting your IP or not getting into expensive lawsuits. I would like to hear more.

I never said anything about AI development.

Being cautious in order to keep one's IP and job safe during an economic downturn isn't shortsighted, it's playing the long game. AI isn't going anywhere, and waiting and seeing how the legalities shake out and how companies will want to consume this internally is the smart play.

Jumping onto a new technology with unknown risks and getting burned is shortsighted.

Just want to say that I'm not going to touch any AI tools until the legalities are ironed out, and I absolutely won't be using it at work without very clear approval. AI poses a huge risk to businesses as programmers start feeding code into other companies backends without thinking and pulling out random snippets from projects with varying licenses.

This is why I stick to a terminal based editor. You can use it practically anywhere with minimal resource usage. You can use it remotely so any machine is your workstation. You can use it on a machine without a GUI at all.

With the new AI plugins I doubt even Jet Brains will be able to offer much over what Vim and Emacs can provide with fugitive, magit, fzf, etc. providing best in class features while still running on actual terminals.

The Makefile one is important. Make is still the best tool for managing a dependency graph, adding project commands, building artifacts of any kind, whether it be building docker images, binary objects, or spinning up integration environments. You can use make anywhere and everywhere, it's powerful but it's also simple on the surface and battle tested.

For DevOps in general I have learned to KISS, always know how your tools work, and focus on observability and low hanging automation. If you can't observe or understand how your systems works, you're screwed. You need metrics, logs, statistics, in one place that you can easily build queries with. You should be able to see everything at the fleet level down to the innards of each machine with no troubles.

Complexity is where bugs hide. Do you really think Rust protects you from every class of bugs? It doesn't even protect you from all memory bugs.

I've saved most of this thread so that I can link it when someone asks me why I don't use Rust for systems development yet. In some ways Rust is worse than C++ with these completely out of orbit contrived math problems in the type system.

C is a simple language, but it's still difficult for beginners to understand systems software because it's complex. Adding something like this were people are inventing complexity in the language itself out of boredom is a recipe for disaster and is much worse than the terrible things than can happen in C.

Please just learn to write simple code and solve hard problems, rather than writing complex code to solve contrived problems.

I've worked on a lot of large and complex projects (mostly kernels) using just vim, git, gdb, cscope, and ctags for development for the past 15 years. I think I've encountered maybe one or two quality of life vim bugs in that time, and a few annoying gdb bugs.

Like AI, until someone shows me something that can come up with novel solutions to deeply technical problems, simple tools and intelligence on the part of the programmer is what works.

This is definitely just an ad for ergomake, there's barely any networking knowledge here at all.

The problem is that system libraries DO solve a problem that docker recreates - the kernel can efficiently map in a virtual address range for shared libraries and then add the map to all of the tasks that are using the same library, and the disk space is minimal because you only have maybe a few copies of the same lib. For some pieces like glibc, that's huge savings system wide.

With container images you're bundling your app with exactly the libraries it needs at the exact versions you want. This means that the kernel is loading all of this auxiliary pieces for you, distinct copies, that then have to reside in their own mappings, so you get no saving there (it's actually slower in terms of program startup), and then you also are wasting tons of disk space to have all of these duplicate dependencies lying around.

Really, the idea of duplicating an entire os tree for containers is just a bad idea, and it leads to lots of super vulnerable images and destroys the whole concept of sharing a system base for performance and storage wins.

It’s literally OCI compatible, integrates with systemd and LSM, and runs rootless by default. Podman is 100000% better designed on the inside with the same interface on the outside.

At this point I stay far away from anything Docker Inc. Podman already has an architecture that makes way more sense on Linux. There are plenty of free alternatives for image registries, but self hosting is also super easy (I mean why not just run a registry container and be done with it).

I’m confused… you’re talking about avoid a local copy of sparse regions… Linux already does that at the level of the inode. There’s also a seek operation to move past the next hole. Not sure why you would carry around metadata the filesystem is already tracking for you.

If you want to smash rocks, go smash rocks. I'm not against people who want to use emacs, or org mode, or ed and keep it to themselves. I am against people making bold faced claims to outsiders in order to entice them into an ecosystem that is solidly last century. I am against perpetuating myths and ignoring the terrible UX and learning curve of emacs+org mode. And I find it appalling how emacs drones flock to every emacs or org mode post on hacker news and spout off a bunch of nonsense about how org mode is basically nirvana.

I'm not interested in hearing about how you hate the cloud, or you need a terminal based mail editor because "bells and whistles don't appeal to you", or you need to control every aspect of your system down to the ROM to get anything done. Most of us just want to get stuff done and focus on our actual problems, and that's easy to see - big corpos aren't building out your dream world because no one wants it, that's capitalism baby. Most of us want a secure cloud. Most of us want nice, modern, easy to use features and the advances that have come with decades of UX and AI research.

It's not you, a system like org mode that allows a user to be terribly bad is a failed system. It's a productivity system that makes you unproductive. It's the kind of yak shaving emacs users love to sell to unsuspecting programmers when they could use modern tools that actually increase their productivity from the start and don't suck them down a rabbit hole of wasted time only to realize they have to set up a small company's worth of infrastructure just to secure and sync notes.

Again, you are living in the past.

- I can share a note with my wife and kids and they can live edit together.

- I can encrypt my notes and share them across the cloud.

- I can send my notes in an email, I can embed photos, videos, emails, messages in my notes.

- I can send my notes directly to my reminders and attach them to a reminder.

- I can can documents and sketches directly from my notes.

- My notes automatically look for keywords to turn into dates and reminders.

- My notes can add tags and have automatic backups and recovery.

You can also put code blocks within a note, export it, and then run it through a code executor, which is way safer than having some sort of editor automation that will slurp up a random note and hack your computer and steal all your credit card info.

Don't use org mode. As I said in another comment in this thread, the whole idea is just egregious yak shaving.

Does org mode have semantic understanding of keywords and a language AI to record my tasks for me? Then it's doomed. Does it sync in the cloud and have world class security (only storing decryption keys at rest in specialized hardware, locally on a TPM like device)? Then it's doomed. Does it have beautiful graphical interfaces for tablet, phone, and PC? Then it's doomed. Does it require you to learn how to use an antiquated text editor that only a small niche of non-programmers are using? Then it's doomed.

You can use org mode even if it is doomed to be irrelevant to normal people. It will continue to work. But it's not magic, please STOP TELLING ME IT'S MAGIC. It's not better than what's out there. There's companies sinking tons of money into todo apps and note taking apps that are integrating modern technologies that make any advantage of org mode complete obsolete in the world of advanced GUIs and language models.

1. Having N tools that are 95% the same is just frustrating for everyone trying to find a tool that will be maintained.

2. Contributing to a project that almost does what you want leads to better tools that are also maintained so they can be relied upon to build new things.

3. Instead of building the Nth version of something, you could be working on something novel.

Theres no value from building something new if you can just learn how something that exists works and contribute to it instead. NIH syndrome is actively harmful to open source.

I feel like org mode has almost become a joke it’s so oversold as the answer to all of life’s note taking problems. Never mind it’s not at all optimized for the most common device - the phone, or has any concept of cloud backed synchronization between devices. And I’m sure managers love it when their employees need to give a presentation and they pull out the old trusty pine book and start presenting something they made in emacs…

I think we all know using difficult tools tickles our programmer brains, but you have to ask yourself, is this really better than using Bear etc. in 2023 for 99% of your note taking needs?

Why not just use mkosi? There are so many tools that do this already and mkosi is cross distro and can do super modern stuff like use UKIs.

Care to share the specifics? Embedded programming in of itself is difficult and tedious, and unless you really love it, professionally makes you less money than much easier forms of SWE. But I'm curious to understand if you are mad at embedded or mad at Rust.