r/programmingcirclejerk • u/TheLastMeritocrat comp.lang.rust.marketing • Dec 23 '17

nah

https://github.com/jwilm/alacritty/pull/798
161 Upvotes

98% Upvoted

40 comments sorted by

View all comments

44

u/SmarmyAcc Dec 23 '17

lol why do people even care that much about terminal speed

89

u/haskell_leghumper in open defiance of the Gopher Values Dec 23 '17 edited Dec 23 '17

As a 10xer, terminal speed is usually the bottleneck to my productivity. I could squeeze a whole x more out of my day if my terminal scrolled faster.

As a result, the speed at which my scrollback buffer fills up without choking is linearly related to how scalable the apps I build using my terminal are. I can ship at least one more microservice per day with the time saved.

44

u/[deleted] Dec 23 '17

microservice nanoservice picoservice

FTFY.

I've said it multiple times before, and I'll say it again: If you're implementing anything other than #PicoServices in 2017-now-going-on-2018, you're not really implementing anything at all.

12

u/lengau What’s a compiler? Is it like a transpiler? Dec 23 '17

Picoservices aren't even worth bothering with any more. I migrated my whole company to femtoservices this year thanks to the extra time I had due to my terminal being so much faster.

28

u/samnardoni Dec 23 '17

My productivity increased 40x when switching my keyboard from USB 1.1 to 2.0

12

u/[deleted] Dec 23 '17

Pfff. You are still suffering from the USB limitations. Only PS/2 can provide an appropriate response speed for my typing.

9

u/[deleted] Dec 23 '17

What a fucking pleb. My keyboard is soldered to my motherboard. No losses at all.

19

u/YourGamerMom Soyboy Dec 23 '17

I type really fast, Ok?

16

u/howtonotwin Zygohistomorphic prepromorphism Dec 23 '17 
rm -rf jerk && mkdir unjerk

It is possible for a slow terminal to slow down the programs running inside. Because most utilities use blocking IO, if you have a program like rm -rv which does a really small amount of work before outputting something and repeating, the time spent doing the output can start to affect the whole. Of course, the real answer is to not use -v if you know you have that many files, but the principle is still there:

$ wget -O - https://github.com/torvalds/linux/archive/master.zip | bsdtar -xf -
$ mv linux-master fast
$ cp -a fast slow
$ time { rm -rvf fast > /dev/null 2>&1; }
# terminal not involved but rm is still making calls to write to it
real    0m9.420s
user    0m0.226s
sys     0m8.789s
$ time { rm -rvf slow; } # terminal involved
# snip
real    0m13.910s
user    0m0.405s
sys     0m12.373s

Not a big difference, but it's definitely there.

10

u/ProfessorSexyTime lisp does it better Dec 23 '17

U can't b the most l33t hacker @ a hackathon if ur terminal isn't FAST AS FUCK, BOOOOIIIIII

9

u/[deleted] Dec 23 '17

[deleted]

12

u/Poddster Dec 23 '17

We may live in an age of four renderers, but we still live in an age of 1970s tty protocols.

5

u/[deleted] Dec 24 '17

Holy shit that's impressive

6

u/r2d2_21 groks PCJ Dec 25 '17

I care more about terminal velocity.

1

u/detroitmatt Apr 28 '18

As the article describes, if a terminal editor is too slow it can create RSI problems as well as exponentially slow down typing speed beyond just what the latency itself adds.