No, both, where I'm loosely using "ethnicity" to denote "genetic population cluster". E.g. the R1a haplogroup is associated with Corded Ware and is not found in these populations while the R1b haplogroup is (R1b is associated with Yamnaya and its absence in Corded Ware is still something of a mystery with various theories being currently debated).
I do not disagree with the point that some superficial aspects are inspired by the PDP-11, I disagree with that this has anything to do with the fundamentals of computing architecture.
It would also completely contradict the whole idea that everything today simulates the PDP-11 design because of C, as few architectures have this auto-in/decrement addressing modes despite C having native syntax.
You are being somewhat disingenuous with your comment ;-)
PDP-11 was hugely influential in the later designs of various Hardware, Software, OS, Languages etc. See for example; Dave Cheney's What Have We Learned from the PDP-11? - https://dave.cheney.net/2017/12/04/what-have-we-learned-from... The conclusion from the article;
While its development was sometimes chaotic, and not without its flaws, the PDP-11 is at the intersection of many threads of history.
Hardware, software, programming languages, operating systems, have all been influenced by the PDP-11. I wager there is not a single person in this room who cannot trace the lineage of the language they work with, the computer they use, or the operating system it runs, back to the PDP-11.
And that is worth celebrating.
While the PDP-11 instruction set was certainly influential in the design of the "C Abstract Machine" the latter was generalized to accommodate other architectures extent at that time (eg. Honeywell 6000, IBM System/370) with enough flexibility that you can implement a C compiler for almost any architecture you can think of. That is its strength.
David Chisnall's criticisms in his C Is Not a Low-level Language: Your computer is not a fast PDP-11 (https://queue.acm.org/doi/10.1145/3212477.3212479) has to do mainly with the fact that the abstract machine was serial execution with no concept of memory protection/models. But this very flexibility is what makes C easily portable to dinky little MCUs which do not have those features while allowing the programmer to explicitly program those using libraries on more complex processors with lots of parallel cores, mmus etc.
Thus a single thread runs on a "C abstract machine" on a core (i.e. the bare minimum) and it is up to the programmer to manage interactions between the threads on various cores. We have lost nothing but perhaps burdening the programmer with more knowledge of hardware complexity which was an acceptable tradeoff then. Note also that there already exists various extensions to C to handle parallel programming directly eg. "Concurrent C" by Narain Gehani et al. The industry however chose to settle on external libraries and optional thread support in C11 again keeping with its minimality and flexibility mantras.
Chisnall's article. A lot of the general criticism would still apply if you replace "PDP-11" with "von Neumann architecture" which makes the whole thing a bit weird. But also many specific comments about C are bit off (the cost of copying padding, the sequencing, provenance, etc.)
Yeah, maximum concurrent clients being 50 is nothing and you're already seeing a large gap. That is the whole point of the BEAM - it scales well with concurrent stuff which is important with web in general and very important for LiveView.
50 is the hardware limit, not a personal choice. The code is free and accessible from the article itself. If you can run tests with more, I'd be happy to update the graphs and the conclusion.
this can't be true, If that hardware can run Django and Phoenix, it for sure can handle orders of magnitudes more concurrent clients than 50 even before you start tuning the OS and the runtime.
> Playwright headless Chromium
maybe you mean you're unable to generate more than 50 concurrent clients using Playwright+Chromium - but that's the wrong tool for loadtesting.
Loadtest should run from a different machine or cluster of machines/VMs. You can generate up to ~ 64K outgoing connections per IP address / alias. With 17 IP addresses/aliases you can generate up to C1M.
You're giving me statements and advice without knowing either the hardware I use or the tools.
I don't have the resources to do this kind of massive testing; if you're up for doing it yourself, I'd be happy to update the data.
Your "Concurrency" benchmark ends at 50 concurrent clients. Continue testing at C1K, C10K, C100K, C1M, C2M, etc.
That's for a single node.
Then try multiple nodes / cluster - C1M, C2M, C10M, etc.
Also, all concurrent clients should send periodic pings / keepalives and do something useful (e.g. some CPU work, not just being idle).
Then you'll have to change your conclusion from:
> The data answers my original question: yes, Django LiveView holds up against Phoenix LiveView. In day-to-day operations they are practically equal.
to
> The data answers my original question: yes, under *toy* load Django LiveView holds up against Phoenix LiveView. For *toy* operations they are practically equal.
Since you seem so knowledgeable about this, why don't you do it yourself? The code is available in the repository. I'm sure you'll do much better than I can.
Natural idempotence requires deep understanding of the domain, which developers (and coding agents) do not always have. Also, it's still a limited solution, which doesn't solve the generic case. So it's each much easier to use technical idempotency solutions like:
- stamp every initial request / domain event with the UUID (idempotency key)
- use client-side IDs instead of using server-generated ones with RETURNING
- use PUT instead of POST
- use UPSERTs
- etc.
IMO, you migh as well use CQRS/ES which is a natural evolution of this idea of modeling the physical reality rather than trying to reduce it to CRUD/L
Here, we can draw an analogy between natural hedging and financial hedging (derivatives). Natural hedging requires planning, preparation, and hard work, and even that doesn't cover every scenario, but it's cheap. With derivatives, you pay someone else to take care of it. The other party may not even understand the underlying asset, but they have quant models (a technical solution)
RE: the question about the first mentions of idempotency keys, IMO cryptographic nonces (numbers used only once) are somewhat related. Idempotency keys are used to facilitate message replay, while nonces are used to prevent replay. But the basic idea is similar
I didn't really mean to emphasize CRUD when I mentioned REST. Just that it is an example of a natural mapping for some domains. I'm not a fan of anything trying to solve distribute system problems with only middleware. The end-to-end mapping needs to traverse the messaging layer, but cannot really be made robust when the endpoint are naive to the distributed reality.
A similar analogy is how 2-phase commit protocols enact (virtual) escrow.
It doesn't matter CRUD, REST, 2PC, or middleware in general. From my PoV they're all technical solutions used to avoid deep modeling of the domain and its workflows, and instead trying to model the real world using generic primitives without understanding it first, or maybe with surface-level understanding only
Also, learning data engineering and BI helps one better model the real world than generic methods. It's somewhat similar to CQRS/ES, but with much more prior art
language families, not ethnicities