Everything being passed by object reference just means every case is equally unclear.

  answer = frobnicate(foo)

Will frobnicate destroy foo or not?

No. It can’t. It can only destroy its own reference to foo, not the calling scope’s reference.

Right, but I don't care about the reference to foo (that's a low-level detail that should be confined to systems languages, not application languages) I was asking about the foo.

Right, but that reference is all the function has. It can’t destroy another scope’s reference to the foo, and the Python GC won’t destroy the foo as long as a reference to it exists.

The function could mutate foo to be empty, if foo is mutable, but it can’t make it not exist.

>> I sorely miss it in Python, JS and other languages. They keep me guessing whether a function will mutate the parent structure, or a local copy in those languages!

No mention of references!

I don't care about references to foo. I don't care about facades to foo. I don't care about decorators of foo. I don't care about memory segments of foo.

"Did someone eat my lunch in the work fridge?"

"Well at least you wrote your name in permanent marker on your lunchbox, so that should help narrow it down"

Then I don’t know what you mean. If you have:

  foo = open(‘bar.txt’)
  answer = frobnicate(foo)
  print(foo)

then frobnicate may call foo.close(), or it may read foo’s contents so that you’d have to seek back to the beginning before you could read them a second time. There’s literally nothing you can do in frobnicate that can make it such that the 3rd raises a NameError because foo no longer exists.

Damn that's fast! I'm gonna stick my business logic in there instead.

It's not even that bad.

As long as it's actual json, it doesn't matter if it's pretty-printed or not, since `jq` can fold and unfold it at will.

I frequently fold logs into single lines, grep for something, then unfold them again

Weird, that's exactly how I feel reading Go:

  func (lst *List[T]) Push(v T) {
    if lst.tail == nil {
        lst.head = &element[T]{val: v}
        lst.tail = lst.head
    } else {
        lst.tail.next = &element[T]{val: v}
        lst.tail = lst.tail.next
    }

}

And this one doesn't even have the infamous error-checking.

You cherry picked a contrived example but that's one of the cleanest generics implementations.

Now imagine if it had semicolons, ->, ! and '.

> You cherry picked a contrived example

List.add is contrived? What are you doing that's simpler the list.add?

> but that's one of the cleanest generics implementations.

You're saying it's typically worse than this?

He is referring to

  &element[T]{val: v}

the & is a pointer, which is common across most languages, but the [T] is a dynamic type T. Otherwise it would be just

  &element{val: v}

He says that element[T] is a clean/simple implementation of generics.

Please, it supports a hole at best. Maybe a pit. No way will this let you construct an abyss.

Plenty of languages, including very serious ones like C and Rust, have bounded recursion depth.

Then let me rephrase:

If every iteration of a while-loop cost you a whole stack frame, then I'd be very rude about that language.

This works, btw:

  #include <stdio.h>

  long calc_sum(int n, long acc) {
    return n == 0
      ? acc
      : calc_sum(n-1, acc+n);
  }

  int main(void) {
    int iters = 2000000;
    printf("Sum 1...%d = %ld\n", iters, calc_sum(iters, 0));
    return 0;
  }

> If every iteration of a while-loop cost you a whole stack frame, then I'd be very rude about that language.

Well, sure, but real programmers know how to do while loops without invoking a function call.

> Your logs are lying to you. Not maliciously. They're just not equipped to tell the truth.

The best way to equip logs to tell the truth is to have other parts of the system consume them as their source of truth.

Firstly: "what the system does" and "what the logs say" can't be two different things.

Secondly: developers can't put less info into the logs than they should, because their feature simply won't work without it.

That doesn't sound like a good plan. You're coupling logging with business logic. I don't want to have to think if i change a debug string am i going to break something.

You're also assuming your log infrastructure is a lot more durable than most are. Generally, logging is not a guaranteed action. Writing a log message is not normally something where you wait for a disk sync before proceeding. Dropping a log message here or there is not a fatal error. Logs get rotated and deleted automatically. They are designed for retroactive use and best effort event recording, not assumed to be a flawless record of everything the system did.

> You're also assuming your log infrastructure is a lot more durable than most are.

Make actions, not assumptions. Instead of using a one machine storage system, distribute that storage across many machines. Then stop deleting them.

> Dropping a log message here or there is not a fatal error.

I would try to reallocate my effort budget to things that actually need to work.

Drop logging completely, and come back to it once you have a flawless record of everything the system did. The reconsider whether you need it.

> You're coupling logging with business logic

Yes, the system shall not report that "User null was created" if it was actually "User 123 that was created".

String? Not a chance, make a proper type-safe struct. UserCreated { "id": 123}

> I don't want to have to think if i change a debug string am i going to break something.

Good point, you should probably have a unit test somewhere.

Your logic wouldn't be dependent on a debug string, but some enum in a structured field. Ex, event_type: CREATED_TRANSACTION.

Seeing logging as debugging is flawed imo. A log is technically just a record of what happened in your database.

> Design decisions like write-ahead logs, large page sizes, and buffering table writes in bulk were built around disks where I/O was SLOW, and where sequential I/O was order(s)-of-magnitude faster than random.

Overall speed is irrelevant, what mattered was the relative speed difference between sequential and random access.

And since there's still a massive difference between sequential and random access with SSDs, I doubt the overall approach of using buffers needs to be reconsidered.

Can you clarify? I thought a major benefit of SSDs is that there isn't any difference between sequential and random access. There's no physical head that needs to move.

Edit: thank you for all the answers -- very educational, TIL!

Lets take the Samsung 9100 Pro M.2 as an example. It has a sequential read rate of ~6700 MB/s and a 4k random read rate of ~80 MB/s:

https://i.imgur.com/t5scCa3.png

https://ssd.userbenchmark.com/ (click on the orange double arrow to view additional columns)

That is a latency of about 50 µs for a random read, compared to 4-5 ms latency for HDDs.

Datacenter storage will generally not be using M.2 client drives. They employ optimizations that win many benchmarks but sacrifice on consistency multiple dimensions (power loss protection, write performance degrades as they fill, perhaps others).

With SSDs, the write pattern is very important to read performance.

Datacenter and enterprise class drives tend to have a maximum transfer size of 128k, which is seemingly the NAND block size. A block is the thing that needs to be erased before rewriting.

Most drives seem to have an indirection unit size of 4k. If a write is not a multiple of the IU size or not aligned, the drive will have to do a read-modify-write. It is the IU size that is most relevant to filesystem block size.

If a small write happens atop a block that was fully written with one write, a read of that LBA range will lead to at least two NAND reads until garbage collection fixes it.

If all writes are done such that they are 128k aligned, sequential reads will be optimal and with sufficient queue depth random 128k reads may match sequential read speed. Depending on the drive, sequential reads may retain an edge due to the drive’s read ahead. My own benchmarks of gen4 U.2 drives generally backs up these statements.

At these speeds, the OS or app performing buffered reads may lead to reduced speed because cache management becomes relatively expensive. Testing should be done with direct IO using libaio or similar.

At the 4K random reads impacted by the fact that you still cannot switch Samsung SSDs to 4K native clusters?

I think that is a bigger impact on writes than reads, but certainly means there is some gap from optimal.

To me a 4k read seems anachronistic from a modern application perspective. But I gather 4kb pages are still common in many file systems. But that doesn’t mean the majority of reads are 4kb random in a real world scenario.

That’s literally faster to do a full table scan below a particular table size.

SSDs have three block/page sizes:

- The access block size (LBA size). Either 512 bytes or 4096 bytes modulo DIF. Purely a logical abstraction.

- The programming page size. Something in the 4K-64K range. This is the granularity at which an erased block may be programmed with new data.

- The erase block size. Something in the 1-128 MiB range. This is the granularity at which data is erased from the flash chips.

SSDs always use some kind of journaled mapping to cope with the actual block size being roughly five orders of magnitude larger than the write API suggests. The FTL probably looks something like an LSM with some constant background compaction going on. If your writes are larger chunks, and your reads match those chunks, you would expect the FTL to perform better, because it can allocate writes contiguously and reads within the data structure have good locality as well. You can also expect for drives to further optimize sequential operations, just like the OS does.

(N.b. things are likely more complex, because controllers will likely stripe data with the FEC across NAND planes and chips for reliability, so the actual logical write size from the controller is probably not a single NAND page)

SSD controllers and VFSs are often optimized for sequential access (e.g. readahead cache) which leads to software being written to do sequential access for speed which leads to optimization for that access pattern, and so on.

It depends on the side of read - most SSD’s have internal block sizes much larger than a typical (actual) random read, so they internally have to do a lot more work for a given byte of output in a random read situation than they would in a sequential one.

Most filesystems read in 4K chunks (or sometimes even worse, 512 byes), and internally the actual block is often multiple MB in size, so this internal read multiplication is a big factor in performance in those cases.

Note the only real difference between a random read and a sequential one is the size of the read in one sequence before it switches location - is it 4K? 16mb? 2G?

That's not possible. It's not an SSD thing either, it always applies to everything [0].

Sequential access is just the simplest example of predictable access, which is always going to perform better than random access because it's possible to optimize around it. You can't optimize around randomness.

So if you give me your fanciest, fastest random access SSD, I can always hand you back that SSD but now with sequential access faster than the random access.

[0]: RAM access, CPU branch prediction, buying stuff in bulk...

Some discussion in the FragPicker paper (2021) FWIW: https://dl.acm.org/doi/10.1145/3477132.3483593

> Our extensive experiments discover that, unlike HDDs, the performance degradation of modern storage devices incurred by fragmentation mainly stems from request splitting, where a single I/O request is split into multiple ones.

SSD block size is far bigger than 4kB. They still benefit from sequential write

Read up on IOPS, conjoined with requests for sequential reads.

Same with doing things in RAM as well. Sequential writes and cache-friendly reads, which b-trees tend to achieve for any definition of cache. Some compaction/GC/whatever step at some point. Nothing's fundamentally changed, right?

pity Optane which solved for this quite well, was discontinued.

It really is a shame optane is discontinued. For durable low latency writes there really is nothing else out there.

Maybe it's more like being a taxi driver using a self-driving car.

Yep, this is the only analogy that makes sense. And if, like in the taxi situation, you are the owner of the taxi license, then you win because you keep making money but now you don't have to drive. But if OTOH you are just driving for a salary, bad news, you need to find another job now. Maybe if you are a very good driver, good looking and with good manners, some rich guy can hire you as his personal driver but otherwise...

You implemented Specifics.

One of my pet-hates is fellow developers who call an implementation 'generic', but when you peek inside, there's just if-statements that (at best) cover the already-known input types.

Usually I point to Generics as an example of what "generic" actually means: You peek inside List<T>, it doesn't know about your type, it does the right thing anyway.