Chandler Carruth

An attempt at striking a balance....

https://github.com/carbon-language/carbon-lang/pull/7694

#CarbonLang

RE: @gloriouscow@oldbytes.space

Scroll up to the start of this thread, and take it the whole way through. It is amazing. Just amazing.

RE: https://hachyderm.io/@chandlerc/116734192778208742

We have a recording available of this early preview now!!

Video: https://drive.google.com/file/d/1tQlzpnbWZfn2WtTFMoJgF93QteByBBwm/view?usp=sharing

Slides: https://chandlerc.blog/slides/2026-memory-safety-deep-3/

Transcript: https://docs.google.com/document/d/1JB9H3KzVixAPC5WIytS4AMyrvjwzC7TXqp596veLT34/edit?usp=sharing

See my post below for some big caveats -- this is just the very first, rough description of the model we're looking at. We still have lots to do to write it all up in a cohesive document, go through the exercise of fully mapping it onto a real set of standard library APIs, and of course, implementing it which is a huge future item of work.

But if you're interested in a peak at where we're going and like early-stage PL design, take a look!

PS: sorry I didn't post more updates about the live version, but thanks everyone who joined! The recording isn't the live version, just Josh presenting it, but it benefitted from the live presentation, all the questions asked, and all the feedback we've already received.

I've always wanted a tool that allowed actual, real SSH to behave mostly like `mosh`. I wanted durability across connection changes, laptop open/shut, etc. I could easily give up the nice latency hiding features of `mosh` (predictive echo, etc) for being truely an SSH replacement: agent forwarding, port forwarding, the works.

Unfortunately, I'm not a networking person, and so this had a pretty steap learning curve for me. Just too much for me to really commit the time and tackle it.

But _wow_ have AI coding tools gotten effective... I have successfully nudged AI coding tools to produce a `mosh`-like tool that uses vanilla `ssh` over its existing `ProxyCommand` capabilities through a fancy UDP / NAT-punching QUIC bridge. At least with black-box testing, it seems to pretty clearly do what I wanted on the tin...

That said, I'm not about to do anything with this w/o going through the code and understanding it. I still care about actual quality, understanding how code works, etc. But I'd love to have help from anyone interested in a solution to this problem, and willing to sift through AI-generated code and call it out on its BS or decide "yeah, this is reasonable". It's 100% Rust code, open source, etc. Would anyone be up for helping?

Eventually, I think I might be willing to shell out to even pay for a proper security review from a reputable firm, but want to make sure the basic software engineering of the core is legit first.

Happy new year everyone!

RE: @mekkaokereke@hachyderm.io

Yep.

And if you're worried that rich people will get richer because they benefit from these free services, there is also a solution to that categorically easier than means testing.

Ready? Wait for it ....

WEALTH TAX

It's really that easy. Like, so easy. So much easier than any kind of means testing. And instantly more constructive and effective.

And it is literally a return to the historical ways of sustaining a functioning society. Some receipts for those curious: https://itep.org/america-used-to-have-a-wealth-tax-the-forgotten-history-of-the-general-property-tax/ https://stantcheva.scholars.harvard.edu/sites/g/files/omnuum7746/files/2025-11/draft_v40.pdf

Really frustrating to see the "official story" C++ documentary, absent all the voices and perspectives of people refused to participate in it, and worse, those who were never asked to participate...

I even largely agree with what is said in it (at least about the language), I'm just sad about all the things _not_ said, and all the voices _not_ heard here...

Would you be interested in an early preview of the design we're converging on for Carbon's memory safety model?

If so, Josh on the Carbon team is planning to give a 2 hour talk covering:

• What the design is
• How it prevents use after free and data races
• What expressivity we expect it to support
• How it will support a transition from C++

It will only lightly cover comparisons with Rust's memory safety approach.

Again, this is an early preview, before we have started on implementation or even a more polished end-to-end write-up. Some of the design may change, and there are still some open questions, but the core looks reasonably solid and very promising.

What we are hoping to achieve with the presentation:

• Get folks up to speed on what we are thinking.
• Getting feedback earlier in our process while making changes is easier.
• Help us refine our exposition.

This talk will not go into:

• How we arrived at this design
• Concerns we had with alternatives we considered
• How the design will be implemented

We are totally okay if you would rather wait until we are further along -- we hope to give regular updates to the community. Also, while this session won't be recorded, we do plan to record the presentation in case you'd prefer to consume a video instead of attending live. And last but not least, our next step is a reasonably polished and complete written design if you would prefer to read a document.

We also expect detailed feedback on our approach and how we are describing the approach would mostly be asynchronous after you've had some time to digest the talk. We only expect to have time for minimal initial reactions and clarifying questions given the depth and complexity of the subject. Our plan is to follow-up afterward in email and/or a document to collect this feedback.

If you're interested in attending live, please put when would work for you here: https://www.when2meet.com/?36904183-wO2j2 and DM me or reach out on our Discord server: https://discord.com/channels/655572317891461132/708431848715452476

We'll post an update with the time(s) selectad and the join link (we use Google Meet for better or worse) to that Discord channel.

Love to see how mad the Onion is here. More folks should be this mad about this.

If you want a really solid critique, it's actually here too. They put their *all* into this piece and while it's sarcastic as usual, it really does cover *so many* aspects of how horrible the current trend of "news" in this space has been.

Go read it:
https://www.theonion.com/it-is-journalism-s-sacred-duty-to-endanger-the-lives-of-1850126997

Been mulling something... (No, this is not actually a sub-toot) Not sure I have it _quite_ articulated well yet, but getting close... Here is my current best attempt...

I think one thing that really misses the mark in culture efforts, inclusivity efforts, and things like codes-of-conduct for organizations & companies is trying to replicate the approach taken by government/state structures.

For example, using legalistic language to try and establish precision of wording in a CoC. Or structuring moderation rules or response policy as-if rules of law and governments. Or demand "adjudication" of moderation/CoC claims with an innocent unless proven guilty, shadow of a doubt, precise evidentiary rules, etc.

Fundamentally, the context here is critically _different_, and trying to apply the approach of one to the other is a mistake. In both directions.

Open source communities, even companies, are not sovereign states. They do not employ an armed police force or military to backstop their rules. If the state decides "you may not say that", they mean, "you may not say that and live as part of this state". And that determination is backed by the threat of violence. The state and the government _should_ be held to the highest possible standard. Judging someone guilty of a crime and enforcing it through state-backed violence of incarceration had _better_ be innocent until proven guilty, and proven with the highest standard of evidence, oversight, and rigor.

Getting banned from an open source community, or even being fired from a hot-shot tech job is _incredibly_ different. That's not to say that either of these is an inconsequential event -- they can be very consequential. And so folks I think feel motivated to push them to the higher standard. But we also need to be realistic, as these are not state-violence backed judgements. This is not the literal forced removal of your freedom or life. This is at _most_ the loss of an especially lucrative career that must be replaced with a categorically less lucrative career. And that's the worst case. Most moderation decisions are _hilariously_ less consequential. And it's entirely reasonable to use a less consequential process to arrive at them.

Well, I'm 42 and still have no answers... Not sure what that means....

We lost our kitty today after 18 years. She had CKD and survived over a year after reaching stage 3, which was remarkable... But still, completely devastated and lost without her...

Will likely be alternating between hiding from my grief with coding and even work, and collapsing under it. Apologies for any chaos this causes.

RE: @chandlerc@hachyderm.io

So I ran this poll, thanks folks for voting, and ... gotta say, I didn't expect it to be essentially a tie.

When I started, my bias was 100% "infinite columns". It seemed like the best option.

But the more I've thought about it, I've weirdly come around to the "80 columns" side. Going to give my rationale, and re-run the poll to see if I get a different result. Or who knows, maybe you all will decide to Boaty-McBoatface my poll out of any meaning, that works too.

Rationale for 80-columns: If the wrapping that happens when a line is too long is _good_, neither answer hurts. It only really matters when the wrapping of a line is both _bad_ and _necessary_.

When we wrap to 80-columns, we make necessary bad wrapping _worse_, but its already quite, quite bad. For example: we get 3 one-word bad wraps for example instead of 2-3 many-word bad wraps.

But we also make wrapping at all less necessary a decent fraction of the time. The benefit there (perfectly readable rendering) probably out-strips the slight worsening of an already bad state.

Also, if we wrap to 80-columns, then users hitting the bad state actually have a much better chance of being able to work around it by resizing a window in some way. At least, strictly more chances than infinite-width!

So, surprisingly, I'm now inclined to the 80-columns. WDYT?

@meowray@hachyderm.io FWIW, strongly disagree here.

I think it is entirely possible to have quality, velocity, and open contribution.

I'm not saying there isn't a tradeoff, but I think the above three can be preserved sufficiently.

For example, in LLVM, I think the bigger challenge than quality is that people view "contribution" as much more about "sending a patch" and not "reviewing a patch. As a consequence, the project has lost community and cultural prioritization of code review as an active and necessary part of contribution.

Also, "open contribution" doesn't mean you have to accept contributions. I think a project can still have meaningfully open contribution while insisting contributors balance their contributions between patches and review, and where contributions that are extractive are rejected until the contributor figures out how to make them constructive.

IMO, criteria for sustaining both quality & velocity in OSS:

• Strong expectation of total community code review in balance to total new patches -- this means that long-time contributors (maintainers) must do more review than new patches.
• Strong expectation of patches from new contributors rapidly rising to the quality bar where they are efficient to review and non-extractive.
• Strong testing culture that ensures a large fraction of quality is mechanically ensured
• Excellent infrastructure use to provide efficient review and CI so tests are effective

I think LLVM struggles with the first and last of these. The last is improving recently though!

Really sad to miss CppNow this year... =/ Wanted to attend, but have to be very selective in travel right now due to an very elderly kitty who needs a lot of medical care... Making it to NDC Toronto was the limit of the travel I could manage in the first half of the year.

That said, hope all the folks in Aspen are enjoying it and hope to see many of you next year!

Very sad to miss #EuroLLVM this year... Hope the conference goes well!

(I'm currently minimizing travel due to an elderly / sick kitty, but will certainly return in the future.)

Really enjoying this interesting and challenging write up about software engineering as it is changing underneath us: https://apenwarr.ca/log/20260316

I'm not sure I'm fully bought into the conclusions, but I find the core idea of quality being better achieved through a differnet process quite compelling. At least as an idea. Anyways, you should read it and have your own thoughts.

Choice pull-quotes for me:
"""
Every time something goes wrong, you have to ask, “How did this happen?” and then do a whole post-mortem and the Five Whys (or however many Whys are in fashion nowadays) and fix the underlying Root Causes so that it doesn’t happen again. “The coder did it wrong” is never a root cause, only a symptom. Why was it possible for the coder to get it wrong?
"""

"""
Maybe we finally have a compelling enough excuse to fix the 20 years of problems hidden by code review culture, and replace it with a real culture of quality.

I think the optimists have half of the right idea. Reducing review stages, even to an uncomfortable degree, is going to be needed. But you can’t just reduce review stages without something to replace them. That way lies the Ford Pinto or any recent Boeing aircraft.
"""

"""
Every team has some monoliths that are a little too big, and too many layers of reviews. Maybe we won't get all the way to Singularity. But, we can engineer a much better world. Our problems are solvable.

It just takes trust.
"""

@boomanaiden154@hachyderm.io @meowray@hachyderm.io

LLVM also isn’t as good as it could be at turning contributors into maintainers interested in doing review

I strongly agree FWIW.

I think there are a lot of different factors here, but one I want to highlight: do folks in the community work to recognize, reward, and make it desirable to do reviews? Do they support the reviewers and create a culture than doesn't just indicate "you need to" but causes people to want to participate in code review? To, literally, find joy and fun in it?

Speaking just for myself, this (in various forms, and combined with depression and other mental health issues) is what burned me out, and caused me to pull back from the LLVM community many years ago.

We've been trying to find a way to healthfully sustain this kind of review culture in Carbon and are having some good success. And as I'm doing better on the mental health front in the last year, I'm also trying to come back to being a bit more involved in LLVM. In large part, my goal and what I want is to figure out how to help nudge the culture in this direction.

FYI, https://ddbeck.com/notes/jj-git-push-bookmark-template/ is pretty nice!

I wrote up my own slugify function though:

```
"slugify(str)" = '''
truncate_end(
40,
str.first_line()
.replace(regex:'\. .*$', '')
.replace(regex:'^\[([^\]]+)\]\s+', '$1/')
.replace(regex:'[^[[:alnum:]] -]', '')
.replace(regex:'-{2,}', '-')
.replace(regex:'\s+', '-')
.lower()
)
'''
```

Think I might still want some more tweaks to this, but so far quite liking a bit more details in the branch name for when I see it in various surfaces like GitHub code reviews.

@curiouserrandy

Yeah, I am also thinking along similar lines.

The more I think about it recently, code review has ended up in an awkward place:

• Try to do optional code review, it just never happens
• Eventually, make it mandatory and pre-commit to ensure it happens
• Ooops, now it's not just a second set of eyes, it's a layer of review process to make progress

Pair programming I think neatly side-steps this doom loop, which in nice. But it has its own challenge due to its synchronous nature: timezones. This makes it incredibly difficult to insist on, especially in environments like open source projects.

What I want is an async code review process that feels more like pair programming rather than a layer of review, and so doesn't explode to the 10x cost. But not sure how to achieve that (yet).