FYI:

I'm not engaging on Twitter. It's leadership is undermining saftey and enabling hateful content targeting my 🏳️‍🌈 and 🏳️‍⚧️ friends (among others).

But I still want to reach people here, so will be posting basic updates w/ links off-site for discussion.

hachyderm.io/@chandlerc

Thoughts on predictors.fail over where I regularly post:

hachyderm.io/@chandlerc/113…

(Reminder, I'm not active here, find me on hachyderm or bsky)

Really excited about what the team has accomplished here! Also, the post shares some really fun details of hardened libc++, huge credit to the #Clang, #LLVM, and libc++ community!

Proud to start sharing Google's strategy for tackling our remaining memory safety challenges: security.googleblog.com/2024/10/safer-…

High level, but it outlines the long-term strategy. We'll be sharing more detailed posts in this series.

#CPlusPlus #RustLang #CarbonLang

@chandlerc1024 *chanting in the distance* borrowck, borrowck, borrowck, bor…

@static_assert_0 Basically.

There may be some differences, but id generally expect us to have a borrow checker or something equivalent.

@chandlerc1024 What's the benefit of Carbon over Rust?

@JAldrichPL If it works, much more comprehensive, integrated, and incremental interop and even automated migration where possible.

@chandlerc1024 Does Carbon have a solution for safety yet? I seem to remember it was a “safe subset” approach initially right?

@static_assert_0 Carbon is still early stages, but we're aiming to have a similar level of safety to Rust or Swift long term.

Excited to share Google's memory safety strategy! We're working to build safer software by migrating to memory-safe languages like Rust as well as hardening our existing C++: security.googleblog.com/2024/10/safer-….

We'll be sharing more details in upcoming posts.

Would analyzers/sanitizers/debug tools etc. in the C/C++ ecosystem be upset if my code read 1 byte at the end of string views? for any useful data type/source of string view.

(More interested in real world answers than theoretical answers.)

@ocornut Yes, ASan and other sanitizers will complain.

You could also get unlucky and have mapped memory end. For example, with a string view of an exact page-sized string, but where it was shrunk to zero length at the end, you could easily have the one byte be on an unmapped page.

Amazing update to one of my favorite stories about memory safety from Android folks: security.googleblog.com/2024/09/elimin…

Degree to which memory safe languages reduces this category of exploitation, and lower the aggregate exploit severity of a product is remarkable.

hachyderm.io/@chandlerc/113…

And the fourth amazing edition of the Carbon Copy, your newsletter for #CarbonLang, is out! github.com/carbon-languag…

This strange tweet got >25k retweets. The author sounds confident, and he uses lots of hex and jargon. There are red flags though... like what's up with the DEI stuff, and who says "stack trace dump"? Let's take a closer look... 🧵1/n

🤷‍♀️ Some people have a fixed ceiling of thought-spend they want to use on their language. If you use things outside of that thought-spend they get frustrated and sad. (We'll ignore that to do similar in C takes either code generation or horrific macros...)

But some people just want to feel like they know everything about their language. Some people just want to feel like everything is simple and the only complexity is what they themselves introduce to the situation/project. This works great,

until you need to do complex things.

@__phantomderp TBH, few of your, or anyone elses PL tweets go as hard as this. +100, well said.

Hot off the virtual presses is the 3rd edition of the Carbon Copy!! =D

I'm particularly excited about this one as it digs in a bit deeper into some meaty bits of the language design.

github.com/carbon-languag…

#CarbonLang

I was disappointed when I read Carbon wasn't going to try to match Rust on mem safety, but this presentation on lessons learned from and putting their own spin on the Swift/Rust protocol/trait systems has some cool ideas, esp. part 2. Decidable checking!

youtu.be/FKC8WACSMP0?si…

@chandlerc1024 Ah interesting. I think it would he hard add the Rust method of checking after release -- lifetimes and the rules around shared vs mutable borrows and Send/Sync and Cell/RefCell thoroughly permeate all Rust APIs. Maybe the Carbon team is cooking something easier to retrofit tho?

@joseph_h_garvin Yeah, adding it afterward makes things harder, no doubt.

But we need to figure out how because we're starting with C++ which is already deeply unsafe, and interop is essential. So harder, but not avoidable IMO.

We have some good ideas tho, including making it a bit less painful

I would like to know how Carbon plans to make sure trait/protocol checking doesn't infinite loop in the presence of variadics though, do my parameter packs always need to stay the same length or shrink too? @chandlerc1024 ?

@joseph_h_garvin We definition check variadics with symbolic arity. This also lets us definition check the variadic's arity being valid in all uses of the pack, etc.

The CppNow talk about this should be posted soon, and the proposal for it is under active work: github.com/carbon-languag…

shaky shaky?

@FioraAeterna Oh yeah....

@SeanParent @tvaneerd @zygoloid Implementation defined: eel.is/c++draft/expr.…

@SeanParent @tvaneerd @zygoloid There are calling conventions that do callee-destruction of by-value parameters, which would make returning a reference to them dangle.

New blog post: Notes from the Carbon panel session at EuroLLVM 2024. muxup.com/2024q2/notes-f…