C is easier to get a program to compile. Rust is easier to get a program working correctly.

The known unknowns and especially the unknown unknowns never get factored into an estimate. People only ever think about the happy path, if everything goes right. But that rarely every happens so estimates are always widely off.

The book How Big Things Get Done describes a much better way to factor in everything without knowing all the unknowns though - Just look a previous similar projects and look how long they took, take the average and bounds then adjust up or down if you have good reason to do so. Your project will very likely take a similar amount of time if your samples are similar in nature to your current task. And the actual time already factors in all the issues and problems encountered and even if you don’t hit all the same issues your problems will likely take a similar amount of time. And the more previous examples you have the better these estimates get.

But instead of that we just pluck numbers out of the air and wonder why we never hit them.

Might I add the idea that your terminal emulator must support your shell is utterly ridiculous?

TBH I am starting to come around to the idea of a tightly integrated shell and terminal emulator support. There are just things you cannot do with these being separate things. I am very tempted to explore the idea from the other end though - writing a shell that has a emulator built into it (like screen/tmux basically are). But I do think that this integration is needed for any per command features that is not just printing out a prompt.

It would be interesting to see what could be done with this type of integration but will likely break support for existing shells. Unless you maybe launch a shell for each command you run or something 🤔. Would like to seem more people experimenting with stuff like this and see what new things we could drive forward. We have been stuck with the current tty system since like the 80s to support devices that just dont exist anymore.

I think the issue fundamentally is that this isn’t what terminal emulators are. The terminal emulator initializes a TTY session and enters a shell environment (sh, zsh, fish, etc). The medium is text and cannot be anything else.

This is 90s thinking. Why must terminal emulators only be text and only do things that a physical terminal could? What makes teminals so nice is not that they work on 90s technology. Some terminal emualtors can already display images. Which is great. And the ideas they are introducing are still fundamentally text based, but are geared towards structuring that texts a bit more than a constant stream of characters on the screen.

Skill issue. Pipe your output to something (like a file or the “less” command)

This is a convenience issue not a skill issue. Yes you can pipe output to things but you need to know before hand that you want to do that. And with less you lose that output once you close less. And with files you have to clean them up after the fact. Both of these are inconvenient and need to be thought of before you run a command. IMO it would be nice to just run a command and then be able to collapse or expand or search its output after the fact and not have to preempt everything beforehand.

The argument that you can already do that in a much less convenient way is not a very good argument.

That is the Luddites argument against progressing anything. There are many problems with current terminal emulators that these newer ones are trying to fix and make the terminal experience better overall. Terminals as they currently work were designed the way they are to talk to dumb typewriters with a screen (that’s right, not keyboards, digital typewriters). And they have barely changed at all since then.

Personally looking at these terminals they have a lot of niceties that I would love to use. But IMO these benefits are not worth the costs these particular terminals also have. One being closed source and requiring an account and the other being electron - no benefit is worth that. But to bury your head in the sand and claim they have no benefits at all is wrong.

Begin able to view images in the terminal would be amazing alone - just like you can cat a text file. I would hate to need to launch a GUI program every time I wanted to see what was inside a text file but that is exactly what I need to do for images or PDFs.

Being able to collapse the output of a command would be nice as well. The number of times I have had to scroll for days to get to the output of a previous command because I happen to run a noisy one but still want to check what something previously had done would save me quite a bit of annoyance. And being able to search just the last commands output would be great - like an after the fact, interactive grep with context. And being able to quickly copy the output of the last command would also be great.

Just factor it into your estimates and make it a requirement to the work. Don’t talk to managers as though it is some optional bit of work that can be done in isolation. If you do frequent refactoring before you start a feature then it does not add a load of time as it saves a bunch of time when adding the feature. And helps keep your code base cleaner over the longer term leading to fewer times you need to do larger refactors.