However, looking at the recent commits it doesn't quite look like the most solid foundation: https://github.com/shuaimu/rusty-cpp/commit/480491121ef9efec...

    fn is_interior_mutability_type(type_name: &str) -> bool {
        type_name.starts_with("rusty::Cell<") ||
        type_name.starts_with("Cell<") ||
        type_name.starts_with("rusty::RefCell<") ||
        type_name.starts_with("RefCell<") ||
        // Also check for std::atomic which has interior mutability
        type_name.starts_with("std::atomic<") ||
        type_name.starts_with("atomic<")
    }

There's also quite a lot of dead code. All of these warnings are around unused variable, functions, structs, fields:

    warning: `rusty-cpp` (bin "rusty-cpp-checker") generated 90 warnings (44 duplicates)

    Generated with [Claude Code](https://claude.ai/code)
    via [Happy](https://happy.engineering)

    Co-Authored-By: Claude <[email protected]>
    Co-Authored-By: Happy <[email protected]>

No logic, no coherence———just inconsistency.

---

Note: This is an experimental shitpost. Fork it. Share it. Use it. [EMOJI ROCKET]

It also looks like it's skipping some lifetime checks in some sketchy way

I'm not sure if it's a good or bad thing people expect the robots to produce proper code on the first attempt?

I don't understand why you feel it's not "constructive" to review the quality of code of a project. Are people supposed to just blindly believe in the functionality without peeking under the hood?

Initial praising doe not preclude rudeness. And complaining about a commit that was undone 30 minutes later is not only pointless in the presented context, it's a cheap attempt at insulting.

> Are people supposed to just blindly believe in the functionality without peeking under the hood

False dichotomy. No one said that. And we both know this is not the way regardless of the codebase.

I think the idea has merits and given the honesty of the post, it's rather more productive to comment on it instead.

Does it? There have been a gazillion such static analyzers. They all do one of two things: ignore the hard parts of tackle the hard parts. If you ignore the hard parts then your tool is useless. If you tackle the hard parts then your tool is orders of magnitude more complex and it still struggles to work well for real world projects. This is in the former category.

The article says "And since the static analysis is mostly statically scoped, it doesn’t require heavy cross-file analysis."

Oops. Suddenly you either handle aliasing soundly and your tool is plagued with zillions of false positives or you handle aliasing unsoundly and... you aren't getting what makes rust different. Separate compilation has been a problem for C++ analyzers for ages. Just declaring it to not actually be a big deal is a huge red flag.

Heck, even just approaching this as an AST-level analysis is going to struggle when you encounter basic things like templates.

The article says this: "Everybody tries to fix the language, but nobody tries to just analyze it." This is just flagrantly false. What's bizarre is that there are people at Stony Brook who have done this. Also, introducing new syntax (even if they are annotations) is more-or-less the same thing as "fixing the language" except that there is almost no chance that your dependencies (including the standard library) are annotated in the way you need.

    struct slot {
      uint32_t key;
      uint32_t value;
    }

You could work around that with a union or casts with explicit alignment constraints, but this is the shortest way to express that.

    union slot {
        uint64_t keyvalue;
        struct {
            uint64_t key: 32;
            uint64_t value: 32;
        };
    };

Edit: Note also that you can cast a pointer to slot to a pointer to uint64_t and that does not break strict aliasing rules.

And yet, we’re not supposed to criticize the tool or its makers? Clearly there’s more problems in this world than «lazy carpenters»?

Some people take that to mean that responses from LLMs are (by human standards) "always correct" and "based on knowledge", while this is a misunderstanding about how LLMs work. They don't know "correct" nor do they have "knowledge", they have tokens, that come after tokens, and that's about it.

This is not what you are being sold though. They are not selling you "tokens". Check their marketing articles and you will not see the word token or synonym on any of their headings or subheadings. You are being sold these abilities:

- “Generate reports, draft emails, summarize meetings, and complete projects.”

- “Automate repetitive tasks, like converting screenshots or dashboards into presentations … rearranging meetings … updating spreadsheets with new financial data while retaining the same formatting.”

- "Support-type automation: e.g. customer support agents that can summarize incoming messages, detect sentiment, route tickets to the right team."

- "For enterprise workflows: via Gemini Enterprise — allowing firms to connect internal data sources (e.g. CRM, BI, SharePoint, Salesforce, SAP) and build custom AI agents that can: answer complex questions, carry out tasks, iterate deliverables — effectively automating internal processes."

These are taken straight from their websites. The idea that you are JUST being sold tokens is as hilariously fictional as any company selling you their app was actually just selling you patterns of pixels on your screen.

Lawyers are running their careers by citing hallucinated cases. Researchers are writing papers with hallucinated references. Programmers are taking down production by not verifying AI code.

Humans were made to do things, not to verify things. Verifying something is 10x harder than doing it right. AI in the hands of humans is a foot rocket launcher.

Again, true for most things. A lot of people are terrible drivers, terrible judge of their own character, and terrible recreational drug users. Does that mean we need to remove all those things that can be misused?

I much rather push back on shoddy work no matter what source. I don't care if the citations are from a robot or a human, if they suck, then you suck, because you're presenting this as your work. I don't care if your paralegal actually wrote the document, be responsible for the work you supposedly do.

> Humans were made to do things, not to verify things.

I'm glad you seemingly have some grand idea of what humans were meant to do, I certainly wouldn't claim I do so, but I'm also not religious. For me, humans do what humans do, and while we didn't used to mostly sit down and consume so much food and other things, now we do.

Uhh, yes??? We have completely reshaped our cities so that cars can thrive in them at the expense of people. We have laws and exams and enforcement all to prevent cars from being driven by irresponsible people.

And most drugs are literally illegal! The ones that arent are highly regulated!

If your argument is that AI is like heroin then I agree, let’s ban it and arrest anyone making it.

You can't have it both ways. Either AIs are worth billions BECAUSE they can run mostly unsupervised or they are not. This is exactly like the AI driving system in Autopilot, sold as autonomous but reality doesn't live up to it.

But you just said we weren’t supposed to criticize the purveyors of AI or the tools themselves.

No, you expressed unqualified agreement with a comment containing

“And yet, we’re not supposed to criticize the tool or its makers?”

>Any critiques you may have for the tools which they use don't lessen this responsibility.

People don’t exist or act in a vacuum. That a scientist is responsible for the quality of their work doesn’t mean that a spectrometer manufacture that advertises specs that their machines can’t match and induces universities through discounts and/or dubious advertising claims to push their labs to replace their existing spectrometers with new ones which have many bizarre and unexpected behaviors including but not limited to sometimes just fabricating spurious readings has made no contribution to the problem of bad results.

The problem is that a researcher who does that is almost guaranteed to be careless about other things too. So the problem isn't just the LLM, or even the citations, but the ambient level of acceptable mediocrity.

Exactly, they're not forcing anyone to use these things, but sometimes others (their managers/bosses) forced them to. Yet it's their responsibility for choosing the right tool for the right problem, like any other professional.

If a carpenter shows up to put a roof yet their hammer or nail-gun can't actually put in nails, who'd you blame; the tool, the toolmaker or the carpenter?

I would be unhappy with the carpenter, yes. But if the toolmaker was constantly over-promising (lying?), lobbying with governments, pushing their tools into the hands of carpenters, never taking responsibility, then I would also criticize the toolmaker. It’s also a toolmaker’s responsibility to be honest about what the tool should be used for.

I think it’s a bit too simplistic to say «AI is not the problem» with the current state of the industry.

Just like as a software developer, you cannot blame Amazon because your platform is down, if you chose to host all of your platform there. You made that choice, you stand for the consequences, pushing the blame on the ones who are providing you with the tooling is the action of someone weak who fail to realize their own responsibilities. Professionals take responsibility for every choice they make, not just the good ones.

> I think it’s a bit too simplistic to say «AI is not the problem» with the current state of the industry.

Agree, and I wouldn't say anything like that either, which makes it a bit strange to include a reply to something no one in this comment thread seems to have said.

https://openai.com/policies/row-terms-of-use/

https://www.anthropic.com/legal/aup

OpenAI:

> When you use our Services you understand and agree:

Output may not always be accurate. You should not rely on Output from our Services as a sole source of truth or factual information, or as a substitute for professional advice. You must evaluate Output for accuracy and appropriateness for your use case, including using human review as appropriate, before using or sharing Output from the Services. You must not use any Output relating to a person for any purpose that could have a legal or material impact on that person, such as making credit, educational, employment, housing, insurance, legal, medical, or other important decisions about them. Our Services may provide incomplete, incorrect, or offensive Output that does not represent OpenAI’s views. If Output references any third party products or services, it doesn’t mean the third party endorses or is affiliated with OpenAI.

Anthropic:

> When using our products or services to provide advice, recommendations, or in subjective decision-making directly affecting individuals or consumers, a qualified professional in that field must review the content or decision prior to dissemination or finalization. You or your organization are responsible for the accuracy and appropriateness of that information.

So I don't think we can say they are lying.

A poor workman blames his tools. So please take responsibility for what you deliver. And if the result is bad, you can learn from it. That doesn't have to mean not use AI but it definitely means that you need to fact check more thoroughly.

Saying «I know that correlation doesn’t imply causation», but then only demonstrating correlation isn’t really bringing this discourse any further.

Appreciate that extending the date range of data would improve the claims, as would adding more sources - but anything else?

https://en.wikipedia.org/wiki/Loneliness_epidemic#Causes_of_...

This adds some complexity in the language, but it means that it’s far more expressive. In Ruby you can with nothing but Array#each write idiomatic code which reads very similar to other traditional languages with loops and statements.

This can sometimes be useful: A calling method can pass down a block or proc to control if/when it wants an early return.

Basically Ruby has two types of closures:

* A return in a lambda returns to the calling scope. So basically, it returns to after where the "call" method is invoked.

* A return in a block or a proc returns from the scope in which it was defined (this is also why you get LocalJumpError if you try to return a block or a proc, but not a lambda to the method calling the one where the block or proc is defined).

When you name a block, you get a Proc object, same as you get when you take the value of a lambda or proc.

In practice, that blocks in MRI are not Proc objects already is just an implementation detail/optimisation. I have a long-standing hobby project to write a Ruby compiler, and there a "proc" and a bare block are implemented identically in the backend.

    def foo
      p 1
      yield
      p 2
    end

    foo { break }

Well, this all depends on the definition of «function properly». Convergence ensures that everyone observed the same state, not that it’s a useful state. For instance, The Imploding Hashmap is a very easy CRDT to implement. The rule is that when there’s concurrent changes to the same key, the final value becomes null. This gives Strong Eventual Consistency, but isn’t really a very useful data structure. All the data would just disappear!

So yes, CRDT is a massively useful property which we should strive for, but it’s not going to magically solve all the end-user problems.

One simple answer to this problem that works almost all the time is to just have a “conflict” state. If two peers concurrently overwrite the same field with the same value, they can converge by marking the field as having two conflicting values. The next time a read event happens, that’s what the application gets. And the user can decide how the conflict should be resolved.

In live, realtime collaborative editing situations, I think the system just picking something is often fine. The users will see it and fix it if need be. It’s really just when merging long running branches that you can get in hot water. But again, I think a lot of the time, punting to the user is a fine fallback for most applications.

With CRDT, you have local consistency and strong convergence, but no guarantee of semantic convergence (i.e. user intent). I would still hire OP, but I would definitely keep him in the backend and away from UX

In general the automatic merging works pretty well most of the time. Where things go wrong is - for example - when people think they can put JSON data into a text crdt and have the system behave well. Instead the automatic merging breaks the rules of JSON syntax and the system falls over.

Yet here we are, circling back to collaborative editing...

At this point I think the term "CRDT" has too much baggage and I should probably stop using it, or at least not put it in blog post titles.

If two users concurrently edit the same word in a text document, how does your system help?

* first update sets task cancelled_at and cancellation_reason

* second update wants the task to be in progress, so sets started_at

CRDT's operate only at the column/field level. In this situation you'd have a task with cancelled_at, cancellation_reason, status in progress, and started_at. That makes no sense semantically, a task can't both be cancelled and in progress. CRDTs do nothing to solve this. My solution is aimed at exactly this kind of thing. Since it replicates _intentions_ instead of just data it would work like this:

action1: setCancelled(reason) action2: setInProgress

When reconciling total order of actions using logical clocks the app logic for setCancelled runs first then setInProgress runs second on every client once they see these actions. The app logic dictates what should happen, which depends on the application. You could have it discard action2. You could also have it remove the cancellation status and set in_progress. It depends on the needs of the application but the application invariants / semantics are preserved and user intentions are preserved maximally in a way that plain CRDTs cannot do.

For example, lets say we have a state machine for a task. The task is currently in the IN_PROGRESS state - and from here it can transition to either CANCELLED or COMPLETE. Either of those states should be terminal. That is to say, once a task has been completed it can't be cancelled and vice versa.

The problem I see with your system is - lets say we have a task in the IN_PROGRESS state. One peer cancels a task and another tries to mark it complete. Lets say a peer sees the COMPLETE message first, so we have this:

    IN_PROGRESS -> COMPLETE

    IN_PROGRESS -> CANCELLED (-> COMPLETE ignored)

In general, CRDTs never had a problem arbitrarily picking a winner. One of the earliest documented CRDTs was a "Last-writer wins (LWW) register" which is a register (ie variable) which stores a value. When concurrent changes happen, the register chooses a winner somewhat arbitrarily. But the criticism is that this is sometimes not the application behaviour what we actually want.

You might be able to model a multi-value (MV) register using your system too. (Actually I'm not sure. Can you?) But I guess I don't understand why I would use it compared to just using an MV register directly. Specifically when it comes to conflicts.

As for the specific scenario, if a client sets a task as COMPLETE and another sets it as CANCELLED before seeing the COMPLETE from the other client here's what would happen.

Client1: { id: 1, action: completeTask, taskId: 123, clock: ...}

Client1: SYNC -> No newer events, accepted by server

Client2: { id: 2, action: cancelTask, taskId: 123, clock: ...}

Client2: SYNC -> Newer events detected.

Client2: Fetch latest events

Client2: action id: 1 is older than most recent local action, reconcile

Client2: rollback to action just before id: 1 per total logical clock ordering

Client2: Replay action { id: 1, action: completeTask, taskId: 123, clock: ...}

Client2: Replay action { id: 2, action: cancelTask, taskId: 123, clock: ...} <-- This is running exactly the same application logic as the first cancelTask. It can do whatever you want per app semantics. In this case we'll no-op since transition from completed -> cancelled is not valid.

Client2: SYNC -> no newer actions in remote, accepted

Client1: SYNC -> newer actions in remote, none local, fetch newer actions, apply action { id: 2, action: cancelTask, ...}

At this point client1, client2, and the central DB all have the same consistent state. The task is COMPLETE. Data is consistent and application semantics are preserved.

There's a little more to it than that to handle corner cases and prevent data growth, but that's the gist of it. More details in the repo.

The great thing is that state is reconciled by actually running your business logic functions -- that means that your app always ends up in a valid state. It ends up in the same state it would have ended up in if the app was entirely online and centralized with traditional API calls. Same outcome but works totally offline.

Does that clarify the idea?

You could argue that this would be confusing for Client2 since they set the task to cancelled but it ended up as complete. This isn't any different than a traditional backend api where two users take incompatible actions. The solution is the same, if necessary show an indicator in the UI that some action was not applied as expected because it was no longer valid.

edit: I think I should improve the readme with a written out example like this since it's a bit hard to explain the advantages of this system (or I'm just not thinking of a better way)

He very much leans toward them being hard to use in a sensible way. He has some interesting points about using threshold functions over a CRDT to get deterministic reads (i.e. once you observe the value it doesn't randomly change out from under you). It feels a bit theoretical though, I wish there were examples of using this approach in a practical application.

``` fn add(x: num, y: num) = x * y ```

The server has the authoritative state, users submit edits, which are then rejected or applied and the changes pushed to others. The users is always assumed to be online for multiplayer editing. No attempt is made to reconcile independent edits, or long periods of offline behavior.

To prevent data loss, when the user is offline and desyncs, he gets to keep his changes and manually merge them back.

I'm sure this isn't a Google genius worthy implementation and fails in the incredibly realistic scenario where thousands of people are editing the same spreadsheet at the same time, but its simple and fails in predictable ways.

but no you dont need it

And if this happens, your experience is going to be terrible anyway.

Except for Zsh (~/.zshrc), SSH (~/.ssh/config), Vim (~/.vimrc), Curl (~/.curlrc), Git (~/.gitconfig). Apple could have chosen to patch these and move the configuration files into ~/Library if they really wanted.

I think it's entirely OK for long-established programs to adhere to their conventions; it's less surprising for the users. If you're going to change how things work, do so with minimum impact on the UI.

(I wish their GUI teams understood that.)

> Although IQ differences between individuals have been shown to have a large hereditary component, it does not follow that disparities in IQ between groups have a genetic basis[18][19][20][21]. The scientific consensus is that genetics does not explain average differences in IQ test performance between racial groups.[22][23][24][25][26][27].

First, let’s substitute emotionally charged terms for more neutral terms; e.g. imagine rather than discussing intelligence and race, we are discussing something else highly heritable and some other method of grouping genetically similar individuals, e.g. height and family. The analogous claim would therefore be that “although height differences have a large hereditary component, it does not follow that disparities in height between families have a genetic basis.” This seems very clearly false to me. It is in the realm of “I cannot fathom how an intelligent person could disagree with this” territory for me. If variable A has a causative correlation with variable B and two groups score similarly with respect to variable A, then they are probably similar with respect to variable B. Of course there are other variables, such as nutrition, sleep, and what have you, but that does not eliminate a correlation. In fact, for something which is “highly heritable” it seems to me that genetics would necessarily be the predominant factor.

It’s a really unfortunate conclusion, so again, I’d love to be wrong, but I cannot wrap my head around how it can be.

There's many scientists who have published the "contrary". They were not ostracized from science or from society as a whole. These saw next to none negative impact to their position while they were alive. Other scientists have published rebuttals and later some of the originals articles have been retracted.

J. Philippe Rushton: 250 published articles, 6 books, the most famous university professor in Canada. Retractions of this work came 8 years after his death.

Arthur Jensen: Wrote a controversial paper in 1969. Ended up publishing 400 articles. Remained a professor for his full life.

Hans Eysenck: The most cited living psychologist in peer-reviewed scientific journal literature. It took more than 20 years before any of his papers were retracted.

There's a lot of published articles about the "contrary view" that you can read. You can also read the rebuttals by the current scientific consensus (cited above).

> The analogous claim would therefore be that “although height differences have a large hereditary component, it does not follow that disparities in height between families have a genetic basis.” This seems very clearly false to me.

But this is not an analogous claim since you're talking about disparities between families. The analogous claim would be: "although height differences have a large hereditary component, it does not follow that disparities in height between groups have a genetic basis".

A very simple example for height[1]: The Japanese grew 10 cm taller from mid-20th century to early 2000s. Originally people thought that the shortness of the Japanese was related to their genetics, but this rapid growth (which also correlates with their improved economy) suggests that the group difference between Japanese and other groups was not related to the genetic component of height variance.

[1]: Secular Changes in Relative Height of Children in Japan, South Korea and Taiwan: Is “Genetics” the Key Determinant? https://biomedgrid.com/pdf/AJBSR.MS.ID.000857.pdf

Every group grew taller as they got richer, but Japanese people are still short even today when they are rich. So existence of other factors doesn't rule out the genetic factor.

Race, like the gender, is now considered a social construct.

The meanings of words are defined by a community of users who find them useful in communicating. Race and ancestry are both useful words.

That is comically retarded. Like do you have any understanding of the words you are using ?

If there's no genetic justification, how would it be possible to trivially determine someone's race just from their DNA ?

Genetic ancestry is determined by correlation with geographic origins and population. In other words, where a set of genetic markers are highly concentrated. It says nothing about race.

https://en.wikipedia.org/wiki/Duck_test

https://en.wikipedia.org/wiki/Pragmatic_maxim

This was my thinking, also. Good cluster of links.

Nobody in race sciences (anthropology, etc) claim that there are only unique races that are separate from each other and don't mix. This is a clear strawman.

The fact that there is mixing between races does not mean that races don't exist. You can make an emulsion out of water and oil, but water and oil still are their own things.

And the science has all kinds of specific categorization for human groups that go way beyond the rough separation into 3-4 main races. All the mixing, separation, migration, isolation, etc have been taken into account.

It's a pity this kind of topic/science is basically a taboo in the Western World and for real info and honest discussion have to go to other systems/countries/languages.

Between us, you are clearly the one with no clue about what he's talking about.

There’s more genetic variation within any so-called racial group than between groups, race mixing or not. Clearly, 'race' has no genetic justification.

You must be one of those clueless people who think that sex is fluid and is a social construct because there is in certain characteristics a bigger difference within each sex than between the medium of each sexes.

After all, the reason why no real object is an actual circle is because the definition of circle is so to say an "ideal" definition that no real object can fit in all it's precision. It's natural to assume that no real object will have all of it's "points" perfectly distributed according to a circle's equation (without even getting philosophical as to how these mathematical definitions relate to the real world, or if they do at all). If one rejects any "approximate", non exact application of the concept, then it will be mostly useless when it comes to describing or understanding the real world (because you won't be able to use it for anything).

On the other hand, the concept of "race" is quite the opposite to ideal: it's not "ideal" as the circle is, in fact it's more of a pragmatic/working definition. It's more like the definition of "chair": many things may or may not be considered a chair, but usually people don't feel that there's "no such thing as a chair" in the real world. On the contrary, it's more common to feel that anything "could" be a chair because it has a malleable definition based on the context, instead of nothing being "precisely" a chair because there are some rigid constraints to the definition that no real object can actually fit.

When the idea of races within the human species is pushed against, it's not because "race" is an ideal concept that no real thing may implement in all it's precision (as would be the case with the circle). I won't present these actual reasons (which could get quite political) here, but I will say that I definitely wouldn't consider those two claims to be in the same category:

- Saying that X real object is not a circle, or that no real object can be (exactly) a circle has to do with the fact that the concept of circle is ideal and by definition nothing "real" will fit it perfectly.

- Saying that (in the human species) there are no races is, however, not based on a quality of the definition of the concept of "race" (specifically, it's not ideal), but on some quantitative judgements about what kind of thing qualifies as a race an what doesn't (pretty much like the concept of "chair", "food", etc. which are not ideal and there's some room for discussion based on context when it comes to whether some specific object fits the category or not).

Races is like that, scientists can't define it but its still a useful concept like a chair. Scientists can't exactly define what a chair is either, but its still a very useful concept and we can discuss chairs and everyone understand what we mean.

The thing about race is that it has no biological justification. It's still 'real' of course but in the same way money has 'real' value. It's a powerful social construct.

> It's a powerful social construct.

This is 100% correct, and yet progressive academics have yet to figure out how to slot this fact into their ideology without creating incorrigible inconsistencies.

For instance - if race is a social construct just like gender, why is transracialism frowned upon, while transgenderism is lauded? Quoting Richard Dawkins, famous debunker of Creationist and religious bullshit [0]:

    Why is a white woman vilified and damned if she identifies as black,
    but lauded if she identifies as a man? That's topsy-turvy, because
    race really is a continuum, whereas sex is one of the few genuine binaries
    of biology.

    What matters, then, is that intersubjectively we have all agreed that
    ancestry is relevant to the determination of one’s race.

There is no science or biology on the far LGBTQ+ progressive left. Only pseudoscience and apologetics befitting of a Creationist.

[0] https://www.youtube.com/watch?v=cubkdBuvJAQ

[1] https://philpapers.org/archive/TUVIDO.pdf

[2] https://sci-hub.se/10.1007/978-1-4614-6086-2_9182

Also their Japan example seems poor. Japan remains a short a country relative to their prosperity. They're several centimeters shorter than a country with a similar GDP per capita, like Czech Republic. They're about the same average height as Somalians, despite having significantly better food security and a GDP per capita that's over 50 times higher.

Sequential consistency mostly become relevant when you have more than two threads interacting with both reads and writes. However, if you only have single-consumer (i.e. only one thread reading) or single-producer (i.e. only one thread writing) then the acquire-release semantics ends up becoming sequential since the single-consumer/producer implicitly enforces a sequential ordering. I can potentially see some multi-producer multi-consumer queues lock-free queues needing sequential atomics.

I think it's rare to see atomics with sequential consistency in practice since you typically either choose (1) a mutex to simplify the code at the expense of locking or (2) acquire-release (or weaker) to minimize the synchronization.

Wait, what? So you're saying this spinlock is buggy? What's the bug?

https://en.cppreference.com/w/cpp/atomic/atomic_flag.html