You are using mutexes, they are on the Actor message queues, amongst other places. "Just use mutexes" suggests a lack of experience of using them, they are very difficult to get both correct and scalable. By keeping them inside the Actor system, a lot of complexity is removed from the layers above. Actors are not always the right choice, but when they are they are a very useful and simplifying abstraction.
I've written a non-distributed app that uses the Actor model and it's been very successful. It concurrently collects data from hundreds of REST endpoints, a typical run may make 500,000 REST requests, with 250 actors making simultaneous requests - I've tested with 1,000 but that tends to pound the REST servers into the ground. Any failed requests are re-queued. The requests aren't independent, request type C may depend on request types A & B being completed first as it requires data from them, so there's a declarative dependency graph mechanism that does the scheduling.
I started off using Akka but then the license changed and Pekko wasn't a thing yet, so I wrote my own single-process minimalist Actor framework - I only needed message queues, actor pools & supervision to handle scheduling and request failures, so that's all I wrote. It can easily handle 1m messages a second.
I have no idea why that's a "huge dead end", Actors are a model that's a very close fit to my use case, why on earth wouldn't I use it? That "nurseries" link is way TL;DR but it appears to be rubbishing other options in order to promote its particular model. The level of concurrency it provides seems to be very limited and some of it is just plain wrong - "in most concurrency systems, unhandled errors in background tasks are simply discarded". Err, no.
Big Rule 0: No Dogmas: Use The Right Tool For The Job.
Is there a similarly short/simple solution not using all of the built ins? Haven't worked with prolog in a while but should be easy enough with primitives (albeit with more duplication)?
He hates on C++ pretty much the same as he does on Rust. Your argument seems to be that Rust is better than C++, which is akin to trying to make the case that Cholera is better than Smallpox.
Language wars are boring and pointless, they all have areas of suckage. The right approach is to pick whichever one is the least worst for the job at hand.
The other reason jump changes are not a revolution and have remained just a curiosity is physics, something that's ignored by the article.
For non-ringers, in change ringing the bells rotate 360 degrees each time they strike, from mouth up to mouth up. The clapper hits the bell when the it has rotated roughly 270 degrees from mouth up and is more or less horizontal, approximately 2 seconds after it starts moving. The bells are usually in the 100kg to 1000kg range (for US folks, that's 220lb to 2200lb), although they can be up to 4000kg. The only point when the ringer can exert control on the bell via the rope is when it is near the balance and mouth upwards, and speeding it up or slowing it down any more than one "beat" is physically very difficult on heavier bells, particularly if you are doing it for a full peal, which usually takes 3+ hours.
That link (like the Wikipedia article) is talking about the mechanism by which the bell is rung, not what is rung out on them i.e. they are not ringing the changes.
It's got compositions on the page, a link to a PDF with compositions in it and a link to the Veronese ringing association which has many more examples - if you can read Italian.
93% of the rings of 6 bells or more which are rung for English style change ringing are in England. Source: https://dove.cccbr.org.uk/
Change ringing is a branch of Group Theory and is mentioned in Knuth. The Steinhaus–Johnson–Trotter algorithm for efficiently generating permutations was published in the early 1960s, but has been known about by change ringers since the 1600s. Source: https://en.wikipedia.org/wiki/Steinhaus%E2%80%93Johnson%E2%8...
I'm licensed by The Engineering Council in the UK for doing computery stuff, and by the relevant European body. I've been writing software for a living for most of my 40+ year career, and still do. So Chartered Software Engineers do exist.
My favourite example of the underlying probabilistic nature of LLMs is related to a niche hobby of mine, English Change Ringing. Every time someone asks an LLM a question that requires more than a basic definition of what Change Ringing is, the result is hilarious. Not only do the answers suffer from factual hallucinations, they aren't even internally logically consistent. It's literally just probabilistic word soup, and glaringly obviously so.
Although there isn't a vast corpus on Method Ringing, there is a fair amount; the "rules" are online (https://framework.cccbr.org.uk/version2/index.html), Change ringing is based on pure maths (Group Theory) and has been linked with CS from when CS first started - it's mentioned in Knuth, and the Steinhaus–Johnson–Trotter algorithm for generating permutations wasn't invented by them in the 1960's, it was known to Change Ringers in the 1650's. Think of it of Towers of Hanoi with knobs on :-) So it would seem a good fit for automated reasoning, indeed such things already exist - https://ropley.com/?page_id=25777.
If I asked a non-ringing human to explain to me how to ring Cambridge Major, they'd say "Sorry, I don't know" and an LLM with insufficient training data would probably say the same. The problem is when LLMs know just enough to be dangerous, but they don't know what they don't know. The more abstruse a topic is, the worse LLMs are going to do at it, and it's precisely those areas where people are most likely to turn to them for answers. They'll get one that's grammatically correct and sounds authoritative - but they almost certainly won't know if it's nonsense.
Adding a "reliability" score to LLM output seems eminently feasible, but due to the hype and commercial pressures around the current generation of LLMs, that's never going to happen as the pressure is on to produce plausible sounding output, even if it's bullshit.
Horses for courses, as they say.
reply