Hacker News new | ask | show | jobs
by fatneckbeardz 1335 days ago
My theory is everything would look alot more like Rust and Go.

IMHO it boils down to a single issue. Net time saved through automation. Consider an equation, for Task X with Software Y that is built to run on the hottest new machine coming out in the next 18 month cycle.

Told = Time task X will take without software Y

Tnew = Time task X will take with software Y + upgraded CPU

Tgross = gross time saved by installing Software Y + upgraded CPU (this is calculated as Told - Tnew)

Twaste = Time wasted through wonky installation, bugs, maintenance, build system problems, dependency hell of software Y + cpu upgrade

Tnet = Tgross - Twaste --> this is the only reason people use software. Does it, on the whole, save time?

So if a task X used to take 1000 hours, but with software Y on an upgraded CPU it takes 500 hours, but it requires 50 hours of waste, thats 500 gross hours saved, but 450 net hours saved.

https://smoothspan.files.wordpress.com/2007/09/clockspeeds.j...

When CPUs were speeding up by 2x every few years, then this equation was dominated by Tgross. Twaste was very small in comparison so users would tolerate alot of Twaste. Twaste was basically ignored for 20+ years.

Nowdays, CPUs are not speeding up much at all. Tgross is struggling to be anything significant. In fact sometimes, Tgross is -lower- than Twaste. So overall it doesn't even make sense to upgrade the software and CPU. So now the only thing in that equation we can improve upon anymore is Twaste.

That means nowdays, we want software that is easy to install, does not have dependency problems, does not have build problems, does not have memory bugs, or security flaws, and doesnt require tons of maintenance.

Go and Rust both improve on all those aspects versus older languages.

"what about parallelism" -> as you may know, slapping N CPUs on a board does not boost speed by N times. And there is an enormous amount of Twaste in the debugging since complexity of thread interaction has gone up by N something. With single thread CPU, Twaste remains constant. With a N-Cpu system, Twaste goes up in some proportion to N. So to get any savings you still need to attack Twaste, and that is done by intrinsic parallelism features built into the language, which both Rust and Go have to various extents.

caveat i have no idea if this is right i just made it up.

edit - this model also explains the Thin Client theory we are seeing which Comevus described below. Web is basically Thin Client theory finally successful after 40 years of PC domination. Web = lower Twaste - almost no dependency, no installation problems, no maintenance on user side.

this also explains containers. Containers try to attack Twaste for systems built on languages made for a Tgross world, like python and C and javascript.

another edit -> does this mean PC is dead forever? no. i forgot one major component of Twaste, which is dealing with bureaucratic waste of people trying to control what other people are doing on a computer. This form of Twaste dominated a lot of the old pre-PC days of computing, like monopolization, discrimination, racism, sexism, favoritism, nepotism, corruption, and all the other waste that humans insert into a process because , contrary to some popular opinions, a lot of human beings make their living off Twaste, not off Tgross.

So at some point the bureaucratic nonsense makes Twaste so large that even a small Tgross is better. So PC is not dead by this theory. Never fully dead anyways.

The end