ozgrakkurt

Suppose you are implementing an application server (backend).

You can limit the concurrent requests that can be handled at a time to 2000 and limit memory per request handler to 2MB.

So you allocate 2000 x 2MB at program start.

Then you crate an arena allocator with (2MB limit) when starting to handle a request.

It will just fail if a request uses more memory than 2MB. This means you will basically never have OOM issues or a request using unexpected amount of memory to crash the server.

You also have performance benefits like:

- Allocation operation is basically an integer increment.

- Memory for a request is laid out linearly in memory and likely is pre-populated so you won't have page fault into the kernel.

- It is very unlikely to have double free or other memory management mistakes.

You can also fuzz the system in several ways to make sure requests can really never exceed that amount of memory usage so you don't have surprises in runtime.

If a request by a user really exceeds that much memory usage, you can just fail that request and log it so it will be debugged and fixed later.

You also don't need data structures like SmallVec (rust version of the thing) that are hybrid stack/heap allocated.

There are many intricacies to this approach but it works much better on scale when you have a large program that handles a large amount of memory.

It is super difficult to debug and fix memory usage issues on global allocator only programs in my experience.

I tried to fix one such issue on a database-like program in rust and it was impossible.

Also this means you don't absolutely need ownership/lifetime safety.

I am using this pattern in a C-like C++ codebase I have and it works really well.

I think it is already way bigger than the other bars combined right?

Selling it off might be a good solution

I would recommend reading a book about programing languages, most of those explain this imo.

What I understand from that is, byte code is portable while machine code isn't.

So you can write a byte code interpreter in C and you have fully cross platform toolchain.

It is also supposedly easier to generate bytecode compared to generating something like x86_64 machine code or assembly.

Imo what matters more is the execution and not the idea anyway so you shouldn't care about this:

> Any comments or suggestions, including, "that's a bad idea, you will fail because of XYZ", or, "save yourself the effort, here's one I wrote earlier..."?

AI slop alert after reading just the first section on the website.

The quote at the top isn't related to what any of this is so it is pretty funny while being obnoxious

what is a predicament?

You would be astounded how more efficient your program can be if you are doing decent amount of computation or IO.

You can try to understand some of it by doing some measurements and doing some napkin math using the hardware limits like internet bandwidth or IO read/write etc.

> You can always rewrite the code.

Akshually, you can never rewrite your code.

It comes from the mentality and quality of the people in the industry imo.

If you go to squarespace domain management website you will see it is utter garbage in terms of experience. It doesn’t have to be like this but the people that make it just aren’t good enough or don’t care.

Unfortunately it is same with blockchain and LLMs soon.

Blockchain can be super useful but there are hard problems that need to be solved and people that vacuum the investment up just aren’t interested in solving problems.

I see the same problem with LLMs because big companies want to pump horror stories and vibe coding instead of code review or security review or cost stabilization/profitability etc.

The people that behave this was just don’t have a chance of long term success imo.

These technologies could have been so much better if they were developed by different people

It is exceptionally easy to make things secure if you are developing conservatively.

Kind of like how permissions model of deno. If you make everything closed by default and selectively open it is very easy.

Not putting credentials to everything in jira isn’t related to using of ai for hacking imo

Yeah because government steals two breads from you if you get caught stealing a bread

This is a wrong mentality imo. Because we are nowhere near reaching a good quality and feature level on software in terms of the generally known theoretical ceilings.

For example you can use a database and see how it is nowhere near reaching any hardware limit. Or you can use some arbitrary software and see how it fails miserably once you start playing with options.

There is so much room for being better that I don’t think anything is justified for cutting including programmers.

Whether these companies will be able to sustain their business or weather software companies will prioritize paying LLMs instead of programmer I don’t know but the ceiling is way above