Except for the times you do want it to run the CI.
LLM issues can often be solved by being more and more specific, but at some point being specific enough is just as time consuming as jumping in and doing it yourself.
Looking at their misrepresentations and over-exaggerations regarding Erlang it now seems like a long lead-up to a sales pitch. Their motivation to exaggerate deficiencies in existing approaches is to lend chapter 7 more rhetorical punch. All the same, I'm keen to hear what they have to say.
A real interesting read as someone who spends a bit of time with Elixir. Wasn't aware of the atomic and counter Erlang features that break isolation.
Though they do say that race conditions are purely mitigated by discipline at design time, but then mention race conditions found via static analysis:
> Maria Christakis and Konstantinos Sagonas built a static race detector for Erlang and integrated it into Dialyzer, Erlang’s standard static analysis tool. They ran it against OTP’s own libraries, which are heavily tested and widely deployed.
> They found previously unknown race conditions. Not in obscure corners of the codebase. Not in exotic edge cases. In the kind of code that every Erlang application depends on, code that had been running in production for years.
I imagine that the 4th issue of protocol violation could possibly be mitigated by a typesafe abstracted language like Gleam (or Elixir when types are fully implemented)
> They found previously unknown race conditions. Not in obscure corners of the codebase. Not in exotic edge cases. In the kind of code that every Erlang application depends on, code that had been running in production for years.
If these race conditions are in code that has been in production for years and yet the race conditions are "previously unknown", that does suggest to me that it is in practice quite hard to trigger these race conditions. Bugs that happen regularly in prod (and maybe I'm biased, but especially bugs that happen to erlang systems in prod) tend to get fixed.
True. And that the subtle bugs were then picked up by static analysis makes the safety proposition of Erlang even better.
> Bugs that happen regularly in prod
It depends on how regular and reproducible they are. Timing bugs are notoriously difficult to pin down. Pair that with let-it-crash philosophy, and it's maybe not worth tracking down. OTOH, Erlang has been used for critical systems for a very long time – plenty long enough for such bugs to be tracked down if they posed real problems in practice.
Erlang has "die and be restarted" philosophy towards process failures, so these "bugs that happen to erlang systems in prod" may not be fixed at all, if they are rare enough.
As of now, the post you're replying to says "bugs that regularly happen ... in prod"
Now, if it crashes every 10 years, that is regular, but I think the meaning is that it happens often. Back when I operated a large dist cluster, yes, some rare crashes happened that never got noticed or the triage was 'wait and see if it happens again' and it didn't happen. But let it crash and restart from a known good state is a philosophy about structuring error checking more than an operational philosophy: always check for success and if you don't know how to handle an error fail loudly and return to a good state to continue.
Operationally, you are expected to monitor for crashes and figure out how to prevent them in the future. And, IMHO, be prepared to hot load fixes in response... although a lot of organizations don't hot load.
not all races are bugs. here's an example that probably happens in many systems that people just don't notice: sometimes you don't care and, say, having database setup race against setup of another service that needs the database means that in 99% of cases you get a faster bootup and in 1% of cases the database setup is slow and the dependent server gets restarted by your application supervisor and connects on the second try.
More succinctly, Carmack only contributes his code to OSS, but not his time, and shouldn't impose his values on the wider community that contribute both.
> technically correct, but in context I think that's somewhat beside the point
Talking past people to argue on semantics and pedantry is a HN pastime. It may even be it's primary function.
As pointed out in the OP comment, it's basically 'money for jam' by the point he releases the source code:
> It's an entirely different thing; he made a thing, sold it, and then when he couldn't sell more of it, gave it away. That's nice!
Carmack has extracted as much profit as he could care for from the source code. The releasing of the code is warm fuzzy feelings for zero cost, while keeping it closed source renders zero benefit to him.
If that was the intent don’t you think it would be stated somewhere, or in the faq?
>“Talking” past
It’s only text, there’s no talking past. You can’t talk past someone when the conversation isn’t spoken. At best, you might ignore what they write and go on and on and on at some length on your own point instead, ever meandering further from the words you didn’t read, widening the scope of the original point to include the closest topic that isn’t completely orthogonal to the one at hand, like the current tendency to look for the newest pattern of LLM output in everyone’s’ comments in an attempt to root out all potential AI generated responses. And eventually exhaust all of their rhetoric and perhaps, just maybe, in the very end, get to the
Unless you recruit mainly via this new job board I can hardly see why employers would go for it, it would just show a very small percentage because you fill most openings via LinkedIn or whatever, damaging the company branding.
> You could just as easily describe someone with bootstrapping experience as being like an FAA crash investigator who investigates take offs.
Takeoff systems aren't analogous to prototype development. I don't know you'd build a prototype plane that's feasible to take to market, without having deep knowledge about how planes are built.
Early design decisions matter. And you don't get to that realisation without dealing with legacy systems where some upstart made terrible decisions that you're now responsible for.
> I think the blame more rests on Apple for falsely representing the quality of their product
There was plenty of other concerning stuff in that article. And from a quick read it wasn't suggested or implied the VO2 max issue was the deciding factor for the original F score the author received. The article did suggest many times over the ChatGPT is really not equipped for the task of health diagnosis.
> There was another problem I discovered over time: When I tried asking the same heart longevity-grade question again, suddenly my score went up to a C. I asked again and again, watching the score swing between an F and a B.
The lack of self-consistency does seem like a sign of a deeper issue with reliability. In most fields of machine learning robustness to noise is something you need to "bake in" (often through data augmentation using knowledge of the domain) rather than get for free in training.
> There was plenty of other concerning stuff in that article.
Yeah for sure, I probably didn't make it clear enough but I do fault OpenAI for this as much as or maybe more than Apple. I didn't think that needed to be stressed since the article is already blasting them for it and I don't disagree with most of that criticism of OpenAI.
Tbf, and in support of your broader point, there's no reading between the lines, because genuine intent is indistinguishable from deception with this kind of stuff, because the latter imitates the former. There's only expecting the worst, and being only occasionally wrong.
LLM issues can often be solved by being more and more specific, but at some point being specific enough is just as time consuming as jumping in and doing it yourself.
reply