[simplotek]

> Yeah, you can always ship a shitty SaaS or plug libraries you don't understand into each other and still make a lot of money.

What you're failing to understand is that the SaaS or plug libraries are not shitty. They might even be better than anything someone who reads SICP like the bible can possibly put together. Why? Because they focus on the right level of detail and abstraction instead of wasting time and effort on irrelevant and useless details. And they deliver it far faster.

I repeat: the StatsD daemon is written in Node.js. it's a >100MB Node.js application to receive, aggregate, and send UDP packages. The StatsD daemon is perhaps the most popular metrics sidecar out there, and no one cares it's not a 1MB C app.

> Statsd is like ~4000 lines of code, which is absolutely tiny; it's a trivial codebase.

Don't you get the point? It's a Node.js app that took a few lines of code to out together to handle UDP packages. Writing the same thing in C would not be hard and it would be far more efficient, but it would be entirely pointless because slapping together a Node.js application performance wise is already good enough. What does this say about the cargo cult beliefs of SICP fundamentalists ?

> You can't write fast JavaScript if you don't know how arrays are represented in memory.

Sure you can. You just hear that arrays are faster and use those not bothering with any irrelevant low-level detail. And who exactly advocates using JavaScript for a UDP server and mention performance needs with a straight face?

> You can't optimize SQL queries if you don't know how a database works.

Don't you get the point? The point is that you don't need to waste your time bothering with performance tuning if your goal is designing a working system. Bothering about irrelevant details like that is a waste of time. Decades ago someone smart already stated that premature optimization was the root of all evil. The first rule of software optimization is "Don't". And here you are trying to argue that being bothered about low level details is relevant for the sake of optimization? Don't.

[inimino]

You don't realize that Scheme used a garbage collected high level language at a time when C would have been the norm. This is like having 40000 npm dependencies today, convenient and very practical.

The smart person was Knuth, who said 97% of the time, you shouldn't think about optimizations, but you shouldn't be complacent but look out for the 3%. This is the same Knuth who gives all his code examples in MIX, the assembly language he created for this purpose.

[zelphirkalt]

The problem is not one thing in particular, but composition of these things, which are getting more and more bloated, because no one applies the fat-reducer to them. I don't know what statsd does, but the point is, that when using it from another program, you suddenly have all that baggage of dependencies and insufficiencies as part of your program. This trend continues until things are horribly bloated. Best place to see this trend is modern websites, that merely show some static info, but require the viewer to download megabytes of JS bloat, and otherwise only show a white screen.

When composing fat, most of the result will be fat as well. Ultimately we do not gain much from our more powerful machines, because at the same time we make it so, that for the same functionality the have to process much more.

[avx56]

I didn't say there was anything wrong with statsd itself, just that it's not a particularly complex application. You can produce a working, useful (to some people) web application/website/whatever people call this shit nowadays but it will not be very fast if you don't optimize anything.

Slack is a web app that is incredibly slow, but still useful: yes, I can send people messages and it doesn't immediately crash, but it also takes up ~300mb of RAM on a fresh tab, which is completely absurd. I still use it because I have to but if it was optimized by people who had a clue what they were doing, it would be significantly faster, and use less memory.