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
In ancient Egypt, there were various trade unions, usually organized by profession
One of the most interesting was the thieves' union
Suppose someone stole yr carpet at night, and in the morning you'd go to the office of the head of the thieves' union, pay 25% of the carpet's value, and get it back. Much better than modern insurance!
Sounds a little like the Thieves' Guild in Discworld.
> The Thieves' Guild was established early in Lord Havelock Vetinari's rule of Ankh-Morpork. Lord Vetinari realised that what people crave is stability, and that, while it is impossible to stamp out crime altogether, it is possible to regulate it. The major gang leaders of the city were therefore called to the Patrician's Palace, where they agreed to be held responsible for ensuring a socially acceptable number of thefts.
> While initially the main money-making venture of Thieves' Guild members remained theft, albeit under strict guidelines and leaving a receipt, more recent books show a system of "insurance", whereby people may pay a fee directly to the Guild and therefore become immune to robbery for a specified period.
"There must be a hundred dollars in there", he moaned, "I mean that's not my league, I can't steal that much! You've got to be in the Guild of Lawyers to steal that much!"
Even without reaching for fantasy, the real world has plenty of examples of "regulated crime" with various degrees of officialdom. From the Japanese Yakuza of the Showa era, to the mafia of postwar Italy, governments will often prefer to deal with organised crime by striking deals and agreeing to shared rules of engagement.
When I lived in Glasgow's leafy suburbia, my local pub was roughly equidistant between a pair of taxi offices and the local police station, so the regulars were in roughly equal quantity off-duty police or off-duty small-to-medium-scale gangsters.
Despite this, the pub was considered neutral ground and the hats were very much off, in there.
And nobody would ever be so improper as to be a grass or a "bent copper".
But, equally, it might become known that someone particularly unpleasant may be found in a particular place, alive and well at least until the weekend, or it might become known that someone's more questionable side businesses were getting a little too noticeable and maybe older and wiser heads needed to offer them some friendly advice, before they got themselves in trouble over it.
And so it went, peaceful for everyone, unless the old boy that had a stroke was in, throwing pound coins at people's heads and shouting "ELVIS!" until they put Elvis on the jukebox for him.
Simpler times, long gone now, washed away in a flood of gentrification, and now there's nothing really keeping the nastier elements in check.
> Even without reaching for fantasy, the real world has plenty of examples of "regulated crime" with various degrees of officialdom. From the Japanese Yakuza of the Showa era, to the mafia of postwar Italy,
Sort of, unless you lost it to a fire or flooding, which the thieves guild presumably wouldn't cover.
Also, is this really true or an urban myth? I'm not finding sources googling this, at most I can find mentions that there were during some norr unstable periods maffia-like structures with large unofficial power.
To protect their homes from floods and fires, the ancient Egyptians made sacrifices and offerings to deities like Hapi (god of the Nile)[1] and Bastet[2]
But this naive actuarial model with a 100% deductible is obviously far less sophisticated than modern insurance ;)
This sounds like something out of a historical fantasy novel or a video game. Why wouldn't the robbery victim just get a bunch of dudes to go down and take the rug and kill everyone? I mean, it really tied the room together
There are papyri of tomb robber confessions, but those were more along the line of the thieves needing to fence their goods and bribing various officials. Not explicitly selling stolen goods back to the victim
This seems ridiculous. People wouldn’t tolerate getting “taxed” like this unless the thieves union also had a lot of muscle like a modern extorting criminal organization.
>One of the most interesting was the thieves' union
>Suppose someone stole yr carpet at night, and in the morning you'd go to the office of the head of the thieves' union, pay 25% of the carpet's value, and get it back. Much better than modern insurance!
This Soviet project developed two Russian-language PLs: Robic[1] and Rapira[2]. Robic was similar to Logo, but unlike Logo, which had only one actor - a turtle, Robik had several: a Train, an Ant, a Painter, and so on
Rapira was more like SETL + Python. It was a dynamic interpreted PL with a rich set of compound data types, such as sets, records (associative arrays), and so on. Compared to the contemporary BASIC, it was ADVANCED
Like Logo, Robik was used to teach programming to kindergarthen-age children, while Rapira was aimed at high school students
In my school we had a Logo-like PL where you controlled a kangaroo and a more complex one where you сontrolled a robot arm with an internal stack that worked on a rectangular array of items. I remember the robot blowing up when you triggered a logical error like going out of bounds or a stack over/underflow.
Even if you have an insurable interest, moral hazard may arise - acting recklessly or other abuse, while knowing you are insured/covered. Somewhat similar to friendly fraud in retail/ecommerce.
Insurance normally has fine print about those things. Life insurance doesn't pay out for suicide. Fire insurance doesn't pay out if you intentionally burn your house down (the fire department also will investigate because even though it is their job they don't like risking their life fighting fires)
You can get insurance without the above provisions, but it will cost a lot more. Once in a while someone manages to collect on a claim for loss of their expensive cigars after they smoke them - but this is rare and usually not worth the cost.
This may vary by country, it isn't a subject I'm particularly familiar with, but at least in the UK that isn't true - many, I think most, life insurance policies here do pay out for suicide. There's just a period of years between the start of the policy and when suicide starts to be covered, to prevent people who are planning on killing themselves from being able to take out insurance just before doing so.
some life insurance policies pay out for suicide after an initial exclusion period. this is often six or twelve months. insurers can include it because suicide claims are relatively uncommon.
if there is evidence that someone took out the policy with the intention of creating a claim then the insurer may treat it as fraud and decline it.
UNIX for PDP-7 in Assm -> UNIX for PDP-11 in Assm -> UNIX for PDP-11 in C
https://news.ycombinator.com/item?id=42644851
and
https://news.ycombinator.com/item?id=43245166
reply