[mitchellh]

Snide and condescending (or at best: dismissive) comments like this help no one and can at the extremes stereotype an entire group in a bad light.

I think the more constructive reality is discussing why techniques that are common in some industries such as gaming or embedded systems have had difficulty being adopted more broadly, and celebrating that this idea which is good in many contexts is now spreading more broadly! Or, sharing some others that other industries might be missing out on (and again, asking critically why they aren't present).

Ideas in general require marketing to spread, that's literally what marketing is in the positive (in the negative its all sorts of slime!). If a coding standard used by a company is the marketing this idea needs to live and grow, then hell yeah, "tiger style" it is! Such is humanity.

[brabel]

> had difficulty being adopted more broadly

Most applications don’t need to bother the user with things like how much memory they think will be needed upfront. They just allocate how much and when necessary. Most applications today are probably servers that change all the time. You would not know upfront how much memory you’d need as that would keep changing on every release! Static allocation may work in a few domains but it certainly doesn’t work in most.

[AlotOfReading]

It's best to think of it as an entire spectrum from "statically allocate everything with compile time parameters" to "directly call the system allocator for every new bit of memory". It's just a helpful way to separate the concerns of memory allocation from memory usage.

What this article is talking about isn't all the way at the other end (compile time allocation), but has the additional freedom that you can decide allocation size based on runtime parameters. That frees the rest of the application from needing to worry about managing memory allocations.

We can imagine taking another step and only allocating at the start of a connection/request, so the rest of the server code doesn't need to deal with managing memory everywhere. This is more popularly known as region allocation. If you've ever worked with Apache or Nginx, this is what they do ("pools").

So on and so forth down into the leaf functions of your application. Your allocator is already doing this internally to help you out, but it doesn't have any knowledge of what your code looks like to optimize its patterns. Your application's performance (and maintainability) will usually benefit from doing it yourself, as much as you reasonably can.

[ulbu]

you don’t know up front how much memory you’ll need, but you know up front how much memory you have.

[chris-]

That's just saying "we push our memory problems up the stack so our clients / users need to deal with that". The reason this works is because human users in particular have become accustomed to software being buggy and failing often.

[brabel]

What ?? It’s exactly the opposite of that! Memory allocation on demand frees users from having to worry about configuring memory settings, which static allocation requires except if you overallocate, which is problematic if lots of applications start doing. I absolutely don’t like the argument that memory is nearly free! Most laptops still come with around 8GB of RAM which a browser by itself can consume already … there’s really not a lot left when you also got Docker, compilers, music app, email and so on running. I have 64GB and still have to close apps sometimes because software nowadays does stupid things like overallocating. Don’t do that.

[astrobe_]

Because garbage-collected languages are easier to teach and to use. So the low-level, low-resource or high-performance stuff is left to a handful of specialists - or "insects" according to Heinlein. Speaking of old things, this reminds me of one of Asimov's short stories, where someone who rediscovers mental calculus is believed to be a genius.

[jibal]

https://ia800806.us.archive.org/20/items/TheFeelingOfPower/T...

Not even calculus, just basic arithmetic operations.

[kennykartman]

Marketing is the thing that makes uninformed people adopt thing they don't need.

I dont think we need marketing, but rather education, which is the actually useful way to spread information.

If you think marketing is the way knowledge spreads, you'll end up with millions of dollars in your pocket and the belief that you have money because you're doing good, while the truth is that you have millions because you exploited others.

[chrisco255]

You complain about the very thing that lead to the experimentation and writing of this article, which is how one gets a real education:

"One of those techniques is static memory allocation during initialization. The idea here is that all memory is requested and allocated from the OS at startup, and held until termination. I first heard about this while learning about TigerBeetle, and they reference it explicitly in their development style guide dubbed "TigerStyle"."

Anyways, TigerStyle is inspired by NASA's Power of Ten whitepaper on Rules For Developing Safety Critical Code:

https://github.com/tigerbeetle/tigerbeetle/blob/ac75926f8868...

You might be impressed by that fact or the original Power of Ten paper but if so, it's only because NASA's marketing taught you to be.

[kennykartman]

If you think that publishing a paper is marketing, then we have quite different views.

Incidentally, I was aware of NASA paper before tigerbeetle was a thing. Not because someone marketed their work, but because I did my research over published ones.

[pmbanugo]

marketing is how ideas spread. And ideas that spread are those that win.

That's why AI-sloppy software would go viral and make loads of money while properly engineered ones die off.

When people need knowledge, they know where to find it. They don't need marketing for that.

[kennykartman]

I think that's a very narrow view of our society dynamics.

[diimdeep]

Lord moral tuning fork, listen to this, the more marketing you throw at people the more you decrease SNR, until you hear nothing but "welcome to cosco we love you" advertisements and you live in the reality of the same movie this phrase is from.

[pjmlp]

It was a common practice in 8 and 16 bit home computing.