I don’t think this is the only reason.

You could do this with Nim, Nim 2’s ARC model is compatible with c++’s RAII. Nim supports moves, destructors, copies, etc. see https://nim-lang.org/docs/destructors.html

You can import C++ classes, member functions, free functions, etc. easily with importcpp

importcpp for the code you are incrementally porting over. You could write a libclang script to do this for you. Exportcpp for what you any code that have been ported but have dependencies in C++ land.

My best guess is they want C++ compatibility and a new language due to preferences, more control over the compiler, etc. which are all valid reasons

Not to disagree, but to amplify - FWIW, most of what you say was also the sales pitch for C++ over ANSI C in the early 90s vs. the "pure Java" mentality that shortly followed in the late 90s (with a megaton of Sun Microsystems marketing to re-write almost everything rather than bridge with JNI). People neglect how practical incrementalism can be.

Also, FWIW, it is very ergonomic for Nim to call C (though the reverse is made complex by GC'd types). { I believe similar can be said for other PLangs you mention, but I am not as sure. } It's barely an inconvenience. Parts of Nim's stdlib still use libc and many PLangs do that for at least system calls. You can also just convert C to Nim with the c2nim program, though usually that requires a lot of hand editing afterwards.

Maybe they should write a C++2carbon translator tool? That would speed things up for them. Maybe they already have and I just haven't heard of it? I mean the article does say "some level of source-to-source translation", but I couldn't find details/caveats poking around for a few minutes.

> I think this page describes "what" but not "why" of Carbon.

Maybe the page was updated recently, but there is a "why" link near the top:

https://docs.carbon-lang.dev/#why-build-carbon

What I would like to see is more documentation on the "why not" that summarizes why other languages and proposals are not sufficient. For example, Safe C++ proposal[1] appears to satisfy all requirements, but I can't find any reference to it.

[1] https://safecpp.org/draft.html

In which way is C++ an "objectively pretty bad language"?

I have done C++ for a living and it is not the easiest but there is tooling and warnings as errors that catch a lot of the errors before even you make a mistake.

It is true that packaging is more challenging but it is also true that it is very configurable ro squeeze performance as much as possible (which is on of C++'s niches). And by squeezing I mean beyond setting a release build. You could for example decide to go with LTO + PGO + remove position independent code and do static linking for all dependencies, for example.

You can do virtually anything that no other language can do and whwn you need it, believe me it is useful.

But you can still code every day code wirh your lambdas, ranges, smart pointers and virtual interfaces.

I understand C++ has some baggage but is is very far from being an "objectively bad language" in ly opinion. More so if you take into account its performance and library availability, which is second to none for almost any task, except maybe for the typical enterprise-like Java app or web stuff, byt niw C++26 will include reflection and annotations, so this could be a game changer.

> Carbon exists so that it's possible to migrate a large C++ code base, like Chrome, from C++ to something saner, incrementally.

_Incrementally_: a C++ project can be incrementally made more sane also using constructs to avoid and constructs to use once the problem domain is confined. In my past, I had successfully implemented this quest for 3 different fairly large C++ projects. This is not a strong selling point for carbon.

A similar example is Facebook/Meta inventing Hack to progressively replacing the old PHP code.

> That's what makes Carbon different from any other language: D, Zig, Nim, Rust etc.

I know you can compile C++ files to object files, pass them to the D compiler, and have them call eachothers' functions. I've never tried it though.

--------

g++ -c foo.cpp

dmd bar.d foo.o -L-lstdc++

--------

https://dlang.org/spec/cpp_interface.html

Zig is designed to interoperate like this with C, and Kotlin with Java.

Zig is nowhere near memory safe. Even some basic semantics (passing arguments as values or references) are horribly broken. https://github.com/ziglang/zig/issues/5973

The real "why" is because, unlike other languages, Google can't strong-arm or bribe C++'s ISO committee into doing its bidding, and that has caused problems for Google in the past. Carbon is a language born out of a corporate hissy fit.

I kind of appreciate fn, personally. It's nice having function declaration lines with two less unnecessary characters in their length.

"func" is fine; "function" is too long. "fn" is also good, but for example, Go was designed with "func," and it's one of the most successful, readable languages in the world, so why not?

I like it the most when there's no keyword. Just name() and return type.

fwiw, many PLs find themselves needing to have C FFI if they want to support MacOS. It's not just a convenience thing.

But couldn’t one argue that’s true of most languages, they promise incremental progress toward rewriting your behemoth into miniature monoliths? I think the only one where they clearly drew the line at being able to pull in headers is .Net. You just can’t do it. Others like Golang or rust, you can point to the C headers and bam…

Honestly, while I find the syntax terse, I welcome more low level languages able to push performance.

Stockholm syndrome, after learning C++ syntax, surely it wasn't all for nothing, I can't accept that.

This was essentially how DMD (the reference D compiler) was translated to D. However this was mostly a restricted subset of C++ common to both of them, e.g. no diamond inheritance, no operator overloading whackiness.

Nim would be the best choice for this at the moment, imho

importcpp what you need. exportcpp for the other way around

[] here can be read as similar to <> in Rust, C#, Java, or C++ templates (but move the content after the `template` into the function declaration). It's not weird if you're familiar with generic programming (and C++ programmers, the target audience of Carbon right now, will all be familiar with it, they use it with their STL algorithms and collections if nothing else). The () is the ordinary "here is the parameter list" used in pretty much every C-syntax language. C doesn't have generics, so there are several ways people have extended that base C-ish syntax to support generics: <>, [], template<>, and a few others have all been done in the past.

https://en.wikipedia.org/wiki/Generic_programming - Worth studying up on if you're unfamiliar with it.

Square brackets do not indicate "this is a type". Instead they indicate "these things were deduced from their context"

The joke is that no* c++ dev actually likes the bracket syntax for templates.

* I might be slightly exaggerating.

It's an ongoing project, specifying a date here wouldn't make much sense.

What's wrong with fn? It's perfectly understandable. I don't understand what the bikeshedding about keywords like this is about.

I use emacs' prettify-symbol mode to turn every language's function keyword into ʩ. Don't think I incurred in God's wrath just yet.

How about "proc"? Too different? I don't like fn either but function is too much. Fun and func aren't great either. I'd go with proc or fn.

C++ does not have a function keyword at all, I wonder why did they add it in the first place.

Nim 2 doesn’t require gc, with arc/atomicArc. The only thing you really need to be careful about is when you use ref types or custom owning types. Otherwise, manual memory management can be done in Nim pretty easily.

Hypothetically you could importcpp fns, classes, etc when compiling with nim cpp

Source-to-source translation is definitely planned. We've even done some early experiments.

But we need to get the language and interop into good shape to be able to thoroughly test and evaluate the migration.

The reason the Safe C++ proposal wasn't mentioned is that it came years later. =] I'll see if it makes sense for us to update that section a bit, this probably isn't the only thing that we should refresh a bit to reflect the last few years of developments.

FWIW, the biggest challenge with Safe C++ is that WG21 rejected[1] that direction. And it was developed without building a governance model or way to evolve outside of WG21, and so doesn't seem to have a credible path forward.

[1]: FWIW, some members of WG21 don't agree with this characterizationp, but both the author's impression and the practical effect was to reject the direction.

Swift seems to be doing a decent job of this (and C++ interop for that matter)

I would be stunned if you could compile arbitrary c++ to rust or d, unless by "compile" you mean "painfully hand-translate and spend months fixing subtle errors". you are underestimating the sheer complexity of the language.

Given that Carbon's space is "languages with full interoperability with C++," I don't think D and Zig are in that space.

As to "getting it right" - things are not so simple. The emphasis on memory-safety soundness is based on some empirical hypotheses, some better founded than others, and it's unclear what "getting it right" means.

From a software correctness perspective, the road to sound memory safety is as follows: 1. We want to reduce the amount of costly bugs in software as cheaply as possible, 2. Memory unsafe operations are a common cause of many costly bugs, 3. Some or all memory bugs can be eliminated cheaply with sound language guarantees.

The problem is that 1. memory safety refers to several properties that don't all contribute equally to correctness (e.g. out-of-bounds access causes more serious bugs than use-after-free [1]), and 2. soundly guaranteeing different memory safety properties has different costs. It gets more complicated than that (e.g. there are also unsound techniques that have proven very effective to consider), but that's the overview.

It is, therefore, as of yet unclear which memory safety properties are worth it to soundly guarantee in the language, and the answer may depend on the language's other goals (and there must be other goals that are at least as important, because the empty language guarantees not only all memory safety properties but all (safety [2]) correctness properties, yet nobody uses it as it's useless, while a language like ATS can be used to write many useful programs, but few use it because it's just too costly to use well). The goal is always to find the right balance.

For example, Java soundly guarantees lack of use-after-free at the cost of increased memory footprint; that may be "getting it right" for some programs but not all. Rust soundly guarantees lack of use-after-free at the cost of imposing strong and elaborate typesystem constraints (that, as is often the case, are more constraining than the property they guarantee); that, too, may be "getting it right" for some programs, though not all. Zig guarantees lack of out-of-bounds access in a simple language at the cost of not guaranteeing lack of use-after-free, and that may also be "getting it right" for some programs but not all.

So what "getting it right" means always depends on constraints other than safety (Rust and Zig want to consume less memory than Java; Java and Zig want to be simpler than Rust; Java and Rust want to guarantee more memory safety properties than Zig). If Carbon wants to be more interoperable with C++ than Java, Rust, or Zig, then it will have to figure out what "getting it right" means for Carbon.

[1]: https://cwe.mitre.org/top25/archive/2024/2024_cwe_top25.html

[2]: https://en.wikipedia.org/wiki/Safety_and_liveness_properties

Probs too archaic?

To avoid any possibility of reintroducing the Most Vexing Parse?

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

It doesn't, but you can pretend it does:

  auto my_function(int, double) -> int;

They probably want to use the same arrow signature and need something in place of auto as omitting it completely would complicate parsing.

I see. So, it's just a slide-ware bullet point right now? It would be helpful to really emphasize a word like "planned" in that bullet. It might have been lifted from some future-sounding/plan-oriented list and now the material makes it seem like it's actually available.

To your footnote, this has been a constant refrain from WG21. One of the biggest achievements from yourself and many others was getting WG21 to explicitly reject P2137 the "Goals and priorities" paper rather than dithering and refusing to commit as happened for "Safe C++" and for the ABI paper.

I believe that getting WG21 to actually say "No" was very useful to have non-technical leadership people understand that C++ can't be the solution they need.

Once you've done this work though, what stops the codebase from slowly drifting back into the less sane realm it previously resided in? It seems pretty reasonable to be concerned that a company that produced a messy codebase once is capable of making it messy again, and given that turnover is inevitable in the long term (which is the timeframe that seems relevant given that long-term compatibility in C++ codebases is kind of the whole reason this discussion is happening), it doesn't seem like relying on an individual to enforce the rules is super viable. The obvious way to enforce this sort of thing is through tooling, and there's no tool more powerful than literally making it impossible to express the undesirable code in the language itself in the first place.

You're right that incrementally rewriting isn't much of an advantage over C++ itself, but I think you're missing the point that the emphasis on "incremental" is to highlight the advantage in rewriting C++ code in Carbon over alternatives that don't provide as much compatibility (with Rust being somewhat notorious for being suggested by outside parties as a target for rewriting in whenever discussions about C++ codebases happen). The argument for Carbon over C++ isn't specifically that it can be rewritten incrementally, but that it's just a better language, which has benefits _after_ the rewrite. To be clear, I'm sure that someone could come up with reasonable objections to that claim as well, but I think it's distinct from the part you're objecting to, and it's worth treating as a separate concern.

It's a great feature, and D has a bunch of support for this kind of thing.

But D and C++ have just enough differences to make extern(C++) not be automatic. It can take some pretty arcane metaprogramming to get things to work, and some things are impossible.

It's also worth pointing out that D isn't trying to be fully compatible with C++.

is there any news? the website has no information and doesn't really highlight anything other than their launch at a conference in 2022.

I don't even code in kotlin but I know that kotlin has function as fun :P

Such small things as using __ __ in python and small inconveniences (lua's 1 instead of 0) really has a lot of people, what do I say.. yea, polarized on this matter.

Keywords usually are quite pronounceable, and some of them are even proper words. How do you read fn?

fun, press tab, modern IDE fills in the remaing function characters.

Unfortunately we keep designing languages for people using notepad.

Nowadays my editor even writes full blocks at a time.

The c++ notation for functions (and types in general) is horrible, and makes parsing much more expensive than it needs to be. Fixing it is step one if you are making a modern language.

We have zero disagreement here (actually true of all responses to my comment - an odd circumstance on HN). What you call "`ref` types" is what I meant by "GC'd types". I actually like that the Nim compiler changed from `--gc=X` to `--mm=X` a while back as the key distinction is (& has always been) "automatic vs. manual".

Elaborating on this cross-talk, any academic taxonomy says reference counting is a kind of GC. { See, the subtitle or table of contents of Jones 1996 "Garbage Collection: Algorithms for Automatic Dynamic Memory Management", for example. } Maybe you & I (or Nim's --mm?) can personally get the abbreviation "AMM" to catch on? I doubt it, but we can hope!! :) Sometimes I think I should try more. Other times I give up.

Before the late 90s, people would say "tracing GC" or "reference counting GC" and just "GC" for the general idea, but somehow early JavaVM GC's (and their imitators) were so annoying to so many that "The GC" came to usually refer, not just to the abstract idea of AMM, but to the specific, concrete separate tracing GC thread(s). It's a bit like if "hash table" had come to mean only a "separately chained linked list" variant because that's what you need for delete-in-the-middle-of-iterating like C++ STL wants and then only even the specific STL realization to boot { only luckily that didn't happen }.

I am trying to run Carbon in Godbolt.

Printing as in the example from Carbon's Github repository, does not work. 'Print("Test");' gives a complaint about not finding 'Print'.

Is there a compiler, maybe an online one, for Carbon, or some way to compile and run Carbon code? And if not, what are the plans for that?

Did Safe C++ ever have a full, correct, fully compliant, reference implementation, or was there only (closed-source) Circle as some kind of reference implementation? Circle, as far as I know, is closed-source.

Explicitly and between the lines, Carruth and Google have made it clear that the “bad” part of C++ from their perspective is the standards committee.

In particular, the committee’s unwillingness to make ABI-breaking changes to the language, or more abstractly, to consider the needs of organizations with huge active code bases at least as seriously as those with huge legacy code bases.

Assuming the right culture, which unfortunately many C++ shops lack, that is why we have things like Orthodox C++ and similar movements.

...and Swift w/ Obj-C

no need for memory safety to be in the language. It can still be checked at compile-time:

https://www.youtube.com/watch?v=ZY_Z-aGbYm8

Splendid reply! I'm a big fan of Carbon and so I really appreciate when people make solid arguments for its tradeoff space.

I counted the word “sound” in this reply 8 times. When I the word sound there is always the word Rust nearby. It is just a coincidence, of course.

Main goal for Carbon is to port existing code first, general purpose second, with Google internal teams as main customer.

If it ever goes beyond that remains to be seen.

The Carbon team is the first to point out that anyone doing green field development should reach out to Rust or any managed language that fits the project scope.

Carbon is just trying to bring a rust-like edition to cpp, there's no reason for non cpp users to Carbon.

I think there are parallels with functional languages on the JVM. The parts that are the worst are the parts that were built for maximum interoperability. Not to mention that the JVM forces classes on you at the deepest opcode levels.

Compatibility with C++ is fine, but so far it seems carbon's safety story is entirely a wishlist rather than anything yet. Seems like Carbon might be a more of a place to demonstrate features for C++ committees than a real language?

Personally I have hand it up to here with lousy programmingn languages that make it easy for me to write bugs.

Yes. pjmlp answered here, but before he posted his reply, nxobject commented with the roadmap which covers 2025 and beyond:

https://docs.carbon-lang.dev/docs/project/roadmap.html

Even on the submitted page, the oldest you could claim it represents is 2024. But I stand by my earlier remark. When linking to an active project's documentation or home page, unless it's to a specifically dated version of it, a date doesn't make sense. For instance, linking to something specific in Python 2.6 documentation, maybe add a date. But if it's just to python.org, it would be absurd to tag it with [1991].

Although it was a journey, starting with HipHop and other tools before arriving there.

Well for one, in addition to templates it has definition checked generics. That alone justifies it to me, but it's far from the only improvement.

These are strong points and I think the methodology behind Carbon is the correct one. The elephant in the room is that once Google decide to drop Carbon my existing code base will be dependant on a dead technology and then I am screwed.

I find it hard to trust Google to maintain any software nor to write software that is maintainable by a community. They write software for themselves and themselves alone.

> As to "getting it right" - things are not so simple. The emphasis on memory-safety soundness is based on some empirical hypotheses, some better founded than others, and it's unclear what "getting it right" means.

It means eliminating undefined behavior, and unplanned interaction between distant parts of the program.

> What _is_ interesting is that I get the impression that Carbon is being workshopped with the C++ community, rather than the wider PLT community -- I worry that they won't benefit from the broader perspectives that'll help it avoid well-known warts elsewhere.

FWIW, we're working hard whenever looking at an aspect of the language to look at other languages beyond C++ and learn any and everything we can from them. Lots of our design proposals cite Swift, Rust, Go, TypeScript, Python, Kotlin, C#, Java, and even Scala.

Being able to change things. It's like all downsides of backwards compatibility but on a binary level

As to things ABI prevents:

- scoped_lock was added to not break ABI by modifying lock_guard

- int128_t has never been standardized because modifying intmax_t is an ABI break. Although if you ask me, intmax_t should just be deprecated.

- unique_ptr could fit in register with language modifications, which would be needed to make it zero-overhead, compared to a pointer

- Many changes to error_code were rejected because they would break ABI

- status_code raised ABI concerns

- A proposal to add a filter to recursive_directory_iterator was rejected because it was an ABI break

- A proposal to make most of <cstring> constexpr (including strlen) will probably die because it would be an ABI break.

- Adding UTF-8 support to regex is an ABI break

- Adding support for realloc or returning the allocated size is an ABI break for polymorphic allocators

- Making destructors implicitly virtual in polymorphic classes

- Return type of push_back could be improved with an ABI break

- Improving shared_ptr would be an ABI break

- [[no_unique_address]] could be inferred by the compiler should we not care at all about ABI

Source: https://cor3ntin.github.io/posts/abi/

F# uses “fun” and I like it. The vowel does help a bit and I never confuse it with the English word. The worst one IMHO is Haskell’s “\”.

Since interop is such a big design goal I wonder if fn was chosen after analyzing the impact of alternative keywords present in large c++ code based that would impact interop in a negative way (eg requiring more escaping).

> Making destructors implicitly virtual in polymorphic classes

Not sure what to think of this one. Either one introduces a new keyword to opt out (not great), or all public destructors of an abstract base class are implicitly marked virtual (not great and another "hidden" language feature like threadsafe-statics).

After all, an abstract base class does not need its destructor to be public.

0 vs 1 indexing has an actual semantic difference that you have to keep in your head at ~all times, but could have a text editor plugin that rewrites func<->fn since it's purely syntactical.

What is inconvenient about it?

Usually as "function"

fun

fn

A compatibility required by C.

Well, the Carbon team primarily focusses on one customer: Google. If management decides "it's carbon now" then a few thousand developers will write carbon or change jobs. If they are then somewhat successful inside Google, people leaving will spread it.

I don't think it will reach the same distribution as other languages, as the niche is "large C++ projects, which want to transition to something else without rewrite" for anybody else there are a huge number of alternatives.

Depends on how much people one sends to WG21 voting sessions, some folks at Reddit would assert contracts only got into C++26, thanks to Bloomberg votes.

Probably referring to "large tech companies that grew in the Web 2.0".

Yeah, agree that it sounds slightly off initially.

Nah, IMO they're both pretty suboptimal, and if Rust is going to choose between two bad options, it might as well choose the overwhelmingly familiar option. (Sadly, my strong opinions on what type parameter and indexing syntax should look like are too large for this margin to contain.)

Pony's keywords are the best. "fun" and "be" are just, well, fun lol.

I agree, I hate fn. Also not a fan of func though.

Implementation would be by modifying clang. Traverse the clang ast emitting the new language instead of llvm IR.

You wouldn't get idiomatic code out but with some effort you'd get rust/d/c/other which clang compiles to the same IR as the original.

How much refactoring is warranted afterwards would depend on how much effort you put in to recreating templates / header files / modules etc on the fly.

I'm not sure I'd choose to do this myself if I was in Google's position but it would be tempting.

> being workshopped with the C++ community

Honestly seems like a dubious idea. The C++ community that remains are even more "just get good" than before. They still think UB all over the place is fine.

For me Go is a success story.

Eliminating undefined behaviour is a means to an end (reduces problematic bugs, but not all undefined behaviour is equally responsible to such bugs), and it's not a binary thing (virtually all programs need to interact with software written in languages that don't eliminate undefined behaviour, so clearly there's tolerance to the possibility of undefined behaviour).

Don't get me wrong - less undefined behaviour is better, but drawing a binary line between some and none makes for a convenient talking point, but isn't necessarily the sweet spot for the complicated and context-dependent series of tradeoffs that is software correctness.

Make sure you're checking out Hylo. I'm not sure that its ideas are right for Carbon, but if you're looking for a credible alternative to Rust's take on safety, I think it's one of the better ones.

Chandler I would love to be involved in Carbon development to shape its development to be usable at my company or alternatively to use it in my own projects. What is the best way to stay involved in Carbon development? Just the discord?

If "fun" and "func" are already "not great" (because, I presume, they're too long), then "fun[TAB]" is not the solution.

Mind you, I'm not saying that your solution doesn't work. Just that it doesn't work for the GP.

The open addressed hash tables basically don't exist for a long time. The various strategies for collision handling in these tables are from the 1980s or later and if you don't have a collision strategy you can't use this as a general purpose container. I'm pretty sure I never used a hash table which didn't use separate chaining until at least the 1990s and perhaps later.

So that's maybe a bad example. In the same way I think it's fine that "Structured programming" is about the need to use structured control flow, not the much later idea of structured concurrency even though taken today you might say they both have equal claim to this word "structured".

In contrast it is weird that people decided somehow "Object oriented" means the features Java has, rather than most of what OO was actually about when it was invented. I instinctively want to blame Bjarne Stroustrup but can't think of any evidence.

That is correct. Strings and I/O both have a bunch of work to be done. Printing currently requires workarounds like https://godbolt.org/z/MP4164f7s

`fn partition[T: ...]` uses `[]` to define T. `s: Slice(T)` uses `(T)` to invoke the type constructor `Slice` with the type argument T. So you could say that's fine because these are different operations.

But then defining a type constructor itself still uses `()`, like `class UnsafeAllowDelete(T:! Concrete) { ... }`. It does seem somewhat inconsistent.

The nightly release of the Carbon compiler can be used via https://carbon.compiler-explorer.com/ . Note that it is definitely a work in progress, it hasn't even reached our v0.1 goals yet, but a good chunk of important functionality is working.

Why not just write it as fun, that way you are having fun while writing a function just as (God intended,[pun intended]) :P

Then wait for Google to adopt it at large?

If it (purportedly?) exists so that Google can move multi-million line code bases from C++ to something better bit-by-bit, because it's otherwise infeasible to do so, why would Google drop it after they have ported the first million?

You can simply wait to see if Chrome adopts it.

fun is the best, as it makes the function name align with the code block indented 4 characters :D

    fun main() {
        println("Hello, world!")
    }
        ^ aligned here! \o/

It is kind of ironic how people still get stuck discussing syntax to save keystrokes and then write a whole book on the AI chat window.

Array iteration got checked into the prelude so this is now shorter: https://godbolt.org/z/YYheo19ea

How is it inconsistent? The square brackets always mean "this was deduced" and the parens always indicate "this was passed in explicitly"

I saw organizations in the past do that with Java and .NET, moving away from C++.

It is perfectly feasable for companies that are full commited into Apple ecosystem.

I need to learn more about that. I know that the Ladybird folks want to use it inside their C++ project.

of course. There will absolutely need to be a way to specify intent in certain cases or override the judgement of the checker. That may come in the form of external annotation, or possibly internal annotation, which in principle is achievable using the same technique as you see in the "unitful" demo, though that's not ideal.

as for zig being specified, well, it's pre 1.0, and the authors have I believe, specifically called out specification as being "the first priority after 1.0".

The information is scattered around the Wiki, LLVM and C++ related conferences.

Basically there should be a 1.0 somehow towards the end of 2026.

https://github.com/carbon-language/carbon-lang/blob/trunk/do...

This is a talk from last year CppNorth, there should be one this year as well,

https://youtu.be/8SGMy9ENGz8?si=reukeBjxAOivX6qI

I can't speak to what libraries you used, but both techniques have been broadly used in common practice since the 1950s. According to the "History" subsection in Knuth TAOCP v3 at the very end of 6.4 (whose very first edition written in 1972 covered OA with various probe/collision strategy ideas), both open addressing & separate chaining were co-invented at IBM in 1953/54 by Luhn & Amdahl. You may be confusing the Celis 1985 Robin Hood hashing work with just the open addressing part? Anyway, as you say, it may be a strained example/analogy. "OO" & "concurrency" both have a lot going on, too.

Anyway, like the "major" modes of hash collision resolution, reference counted GC has also been around concurrently (haha) with ref tracing GC since the dawn of modern computing. Unix hard-links (& other things) codify ref counting into filesystems.. Python has always had ref-counted GC, older Lisp more focused on tracing GC, etc., etc. Popularity measures are notoriously difficult.

Mostly people like to abbreviate { like having a search $PATH instead of using /bin/foo everywhere }. The whole point of abstraction is to neglect details. Neglect naturally leads to forgetting (or never learning/knowing). Ignorance leads people to cross-talk (or worse willfully misinterpret/project). Cross-talk leads to suffering. Yoda out. ;-)

EDIT: Also, speaking of abbreviation & clarity, in Nim "arc" has, at least until this writing, always stood for Automatic Reference Counting, not Atomic Ref Counting as seems the more rusty terminology and is vaguely suggested by @miguel_martin, to whom I originally replied with an "arc/atomicArc", though it seems like, in Nim 3, it may become both Automatic & Atomic, but probably not changing its abbreviation to "AARC".

> But Safe C++ and Circle are different languages, right?

Eh, bit of a mixed bag, I think, depending on the context in which the words are used. "Circle" can refer to the compiler/toolchain or the set of C++ extensions the compiler implements, whereas Safe C++ is either the proposal or the extensions the proposal describe. As a result, you can say that you can compile Safe C++ using Circle, and you can also describe Safe C++ as a subset of the Circle extensions. I wouldn't exactly describe the lines as well-defined, for what it's worth.

> There are presumably differences between them, and I do not know what those differences are, and I do not know if those differences were documented somewhere.

They're sort of documented indirectly, as far as I can tell. Compare the features in the Safe C++ proposal and the features described in the Circle readme [0]. That'll get you an approximation at least, albeit somewhat shaded by the old docs (understandable given the one-man show).

> I cannot find any occurrences of "reference implementation" in the Safe C++ draft.

The exact words "reference implementation" may not show up, but I think this bit qualifies (emphasis added):

> Everything in this proposal took about 18 months to design and implement in Circle.

[0]: https://github.com/seanbaxter/circle/blob/master/new-circle/...

Curious, what keywords were those? I think Chris Lattner was not involved with Swift after version 3

you would end up with llvm-ir-like code that was only technically rust/d insofar as the compilers could handle it. it would not be human-readable or maintainable at all; indeed, it would be harder to convert that to idiomatic rust/d than hand-translating the c++ code. and really, all you would gain would be getting rid of the c++ compiler and ending up with worse code.

the point of carbon is that you can incrementally migrate your c++ program to it in place, and the migrated code will end up easier to maintain than the original c++.

I'd say Dart/Flutter is as well

We've been watching closely since before the name change. =D Had lots of conversations with several of the folks involved.

In increasing order of volume of material:

- Our newsletter / announcements via GitHub Discussions[1] email[2] or RSS[3]

- The "Last Week in Carbon" posts via GitHub[4] or RSS[5]

- The Discord server: https://discord.gg/ZjVdShJDAs

[1]: https://github.com/carbon-language/carbon-lang/discussions/c...

[2]: https://groups.google.com/a/carbon-lang.dev/g/announce

[3]: https://github.com/carbon-language/carbon-lang/discussions/c...

[4]: https://github.com/carbon-language/carbon-lang/discussions/c...

[5]: https://github.com/carbon-language/carbon-lang/discussions/c...

None of the schemes I was aware of pre-date Celis in 1985 but it's apparent upon actually reading Celis [which I hadn't done previously] that he's only improving on an existing state of the art, so I was entirely wrong about that. That state of the art was pretty dire by my reckoning, but it's clear that it would have worked so I was entirely wrong and I apologise for being so assertive when in fact I clearly didn't know what I was talking about.

I think Apple is largely doing this for themselves.

I think that might be true of the language committee, but there's presumably a huge crowd of people with existing c++ code bases that would like to have a different path forward than just hoping that the committee changes priorities.

By definition all the C++ Undefined Behaviour is unbounded. You may believe, and even you may have practical evidence for the compilers which happen to exist today, that in some cases the behaviour in fact bounded, but that's not what the language definition says and optimisers have a funny way of making fools of people who mistake Undefined for "Eh, it'll probably do what I meant".

It might seem as though incrementing a signed integer past its maximum can't be as problematic as a use after free even though both are Undefined Behaviour, but nah, in practice in real C++ compilers today they can both result in remote code execution.

There is a place for Unspecified results, for example having it be unspecified whether a particular arithmetic operation rounds up or down may loosen things up enough that much faster machine code is generated and well, the numbers are broadly correct still. But that's not what Undefined behaviour does.

If they're the same language, then I think it's a fair objection that it's closed-source, as some people might find using a closed-source compiler to be unsuitable as a replacement for the existing open source C++ ones. If it's not the same language, then it's not clear that Safe C++ actually exists today, so it also seems fair that people might be interested in alternatives that they expect might be available sooner.

Maybe not, but an Objective-C++ codebase might be a good candidate.

That is what many of us have done moving into managed languages, with native libraries when required to do so.

The remaining people driving where the language goes have other priorities in mind like reflection.

The profiles that were supposed to be so much better than the Safe C++ proposal, none of them made it into C++26, and it remains to be seen if we ever will see a sensible preview implementation for C++29.

Yes, that's what UB means - the program loses all meaning and any effect is possible - but the importance of a bug is much more than just its blast radius. We ultimately care not about the language semantics of a bug but its expected loss of value. This is also dependent on how frequently the bug appears and how easy it is to prevent or find and fix. Not all UBs are equal on that front.

Furthermore, an unbounded blast radius isn't itself the direct problem. A bug that with some probability casues your program to crash and your disk to be deleted is far less dangerous than a bug that allows a remote attacker to relatively easily steal all your secrets. UBs also differ on that front.

And again, virtually all programs are not provably without UB. For example, a Java program still interacts with an OS or with some native library that might suffer from a UB. So clearly we do tolerate some probability of UB, and we clearly do not think that eliminating any possibility of UB is worth any price.

When a program is just code on the screen, it's just a mathematical object, and then it's easy to describe a UB - the loss of all program meaning - as the most catastrophic outcome. But software correctness goes beyond the relatively simple world of programming language semantics, and has to consider what happens when a program is running, at which point it is no longer a mathematical object but a physical one. If a remote attacker steals all our secrets, we don't care if it's a result of some bug in the program itself (due to UB or otherwise), in other software the program interacts with, some fault or weakness in the hardware, or human operator error. The probability of any of these things is never zero, and we have to balance the cost of addressing each of these possibilities.

To give an example in the context of Carbon, we know that old code tends to suffer from fewer severe bugs than new code. So, if we want to reduce the probability of bugs, it is possible that it may be more worthwhile to invest - say, in terms of language complexity budget - in interop with C++ code than in eliminating every possible kind of UB, including those that are less likely to appear, sneak past testing, and cause an easily exploitable vulnerability.

I don't think the objection in the first sentence makes sense because I don't think replacing the existing C++ compilers was ever in the cards. If anything, the fact that the Safe C++ proposal has a section titled "Implementation Guidance" seems to point to precisely the opposite - that the intent was for existing C++ compilers to be updated to add the new features, not that Circle was to replace them.

I'm not sure about the second sentence either? Circle (supposedly?) implements everything in the Safe C++ proposal, so in that respect Safe C++ exists. Alternatively, you can say Safe C++ doesn't exist because major compilers don't implement it, but that's kind of the point of the Safe C++ proposal (and many (most?) other C++ language proposals, for that matter) - it's describing new features that don't currently exist but might be worth adding to the standard.

> people might be interested in alternatives that they expect might be available sooner.

This is also a bit funny because this was one of the more contentious points of debate in the Safe C++ vs. profiles discussion, and the impression I got is that between the two Safe C++ was generally considered to be closer to "might be available sooner" than profiles.

I'd say the C++ community is torn.

Some part of it want C++ to be Rust, with a focus on compile-time safety. Others take "C++" literally as "C with extra stuff" and value performance over safety.

Companies like Google are likely to be in the former camp, as for what they are doing, security is critical. Unsurprisingly, Carbon is a Google project.

Video game companies on the other hand are likely to be in the latter camp. Most of the times, security is not as critical, especially for offline games, and memory corruption usually don't go further than a game crash. Tight memory management however is critical, and it often involves raw pointers and custom allocation schemes.

Do you have projects with huge code bases of Obj-C++ in mind?

I guess, some Mac apps? In that case I think most platform independent "guts" would be in C or C++, and the Obj-C++ part is tied to the frameworks, so the devs would have to rewrite it anyway.

C++ 26 doesn't have the technology, but it wouldn't matter anyway because what's crucial about Rust isn't the technology it's the culture.

If WG21 were handling Rust instead f64 would implement Ord, and people would just write unsafe blocks with no explanation in the implementation of supposedly "safe" functions. Rust's technology doesn't care but their culture does.

Beyond that though, the profiles idea is dead in the water because it doesn't deliver composition. Rust's safety composes. Jim's safe Activity crate, Sarah's safe Animals crate and Dave's safe Networking crate compose to let me work with a safe IPv6-capable juggling donkey even though Jim, Sarah and Save have never met and had no idea I would try that.

A hypothetical C++ 29 type safe Activity module, combined with a thread safe Animals module, and a resource leak safe Networking module doesn't even get you something that will definitely work, let alone deliver any particular safety.

> the most catastrophic outcome

Nah, this is in the context of C++ so UB isn't the most catastrophic situation. Undefined Behaviour is a behaviour, which means we might well be able to avoid invoking the behaviour and then it's fine. For example if your C++ program has a use-after-free in the code invoked only by the "Add file" feature but otherwise works fine, we can just ensure operators never use "Add file" and the UB, no matter what it might be, won't happen.

C++ has IFNDR, clauses which say this is "Ill-Formed, No Diagnostic Required". The program itself wasn't actually a valid C++ program, it has absolutely no defined meaning, there may be no indication of a problem from your compiler but alas it's entirely meaningless. This isn't behavioural, it's an invisible status of the entire program.

Facebook iOS

Yeah, that sums it all quite nicely, see contracts proposal as a good example of that.

> If WG21 were handling Rust instead f64 would implement Ord, and people would just write unsafe blocks with no explanation in the implementation of supposedly "safe" functions. Rust's technology doesn't care but their culture does.

But Rust allows pattern matching on floats.

https://play.rust-lang.org/?version=stable&mode=debug&editio...

Rust Zulip is C++ WG21 confirmed?

As far as Safe C++ vs. profiles specifically, I don't think the conversation really ever got to the point of serious discussions of how soon the features could be implemented. My understanding is that there were bigger hangups about what direction to go in the first place as well as what "profiles" even meant.

> and I think it would be fair to consider alternatives at this point

I would assume those who could consider alternatives already have, and that those (still) interested in safe(r) C++ do so because the alternatives are insufficient for one reason or another.

As I said, UB means that a program has no meaning in the source language. That doesn't change anything I wrote above about the impact of UB. A hardware fault may also make a program meaningless, BTW, yet we all accept that every program written in any language is currently susceptible to UB or to a hardware fault.

If you want, you can think of UB like a mathematical singularity in some physical theory. The theory of the language has nothing to say about what happens in such a program. But that doesn't mean that we can't reasonably talk about what happens not using that theory [1]. Indeed, one of the reasons that UB are of concern is that some of them are frequent causes of security exploits - and that's the thing we ultimately care about, not that the program loses its semantics. But again, not all of them are equally common causes of such outcomes, and not all of them are equally hard to avoid in the first place.

[1]: In fact, this is easy to explain in software: the programming language can say nothing about the meaning of a program with UB - indeed, it has no meaning in that language - but because we do have an executable, the program still has a well-defined meaning in the machine language it compiled to (machine language has no UB, or, even if some machine architecture does declare that some instruction stream is UB, most programs with UB in some programming language still do not compile to a program with UB in machine code). So the program that has no meaning in C++ still has meaning in machine code, and as that is the program we ultimately run and care about, we can talk about which UBs are more or less likely to result in which machine code behaviour.

I'm sure you think this was somehow succinctly making your point, but I can't see any connection at all, so if you did have an actual point you're going to need to explain it.

This seems like it missed the point entirely?

UB is a behaviour, it's unbounded, so it's an immediate disaster, and "time travel" UB can make this harder to reason about, because the as-if rule can mean that although it didn't in some sense "happen" yet the behaviour has consequences earlier. But if we avert the behaviour it won't happen. It is not correct to say that UB means the entire program had no meaning.

You give the "mathematical singularity" analogy, consider division. We doubtless agree than 6 divided by 3 is 2. And 6 divided by 2 is 3. But how about 6 divided by 0? This is not defined, we cannot perform such an operation. But division is not as a result somehow entirely without meaning, it just has this well understood limitation. Likewise for software with UB that we can avert.

IFNDR is a catastrophe because it truly does render the entire software without meaning.

Float matching in Rust is not supported due to correctness concerns, but due to historical accidents and backwards compatibility.

https://github.com/rust-lang/rust/issues/41620#issuecomment-...

https://github.com/rust-lang/rust/pull/84045#issuecomment-82...

> IFNDR is a catastrophe because it truly does render the entire software without meaning.

In the language. I.e. the language assigns no meaning to source the program, which is, indeed, the "catastrophic" impact of UB (or IFNDR) within the theory of the language. But since a running program takes the form of an executable, and the executable always has a defined meaning in another language (machine code), while C++ has nothing to say about what such programs do (i.e. that's the end of the helpfulness of that theory) that doesn't mean we can't talk about or care about the meaning of the executable.

An executable that crashes and an executable that leaks all your secrets have very different consequences, and while the C++ spec says absolutely nothing about the relationship between different UBs and these behaviours, that doesn't mean that these relationships don't exist.

A mathematical singularity in a physical theory means that that particular theory has nothing to say about the physics of that situation, not that there's no actual physics going on, and the physics that is actually going on could be more or less "catastrophic" depending on what we mean by that.

OK? I don't see how that's connected? It's not controversial that f32 and f64 are partially ordered, the problem in C++ is that the difference between "Partially Ordered" and "Totally Ordered" is semantic not syntactic in their language and all semantic mistakes are just IFNDR so it's a footgun.

To be more concrete, event though two programs can both be meaningless in C++, i.e. C++ says nothing about what they actually do once compiled and run, we can sometimes say that one of them is much more likely to lead to a security exploit than the other. This is even used in practice in techniques such as this one: https://www.cl.cam.ac.uk/~tmj32/papers/docs/ainsworth20-sp.p...

I blame the "we won't recompile anything ever" stance from the financial organisations for the breakdown. It means C++ cannot fix mistakes, even when they harm performance, under the general name of "abi stability".

Thus there is an opening for a faster language. And still for a safer one. And for an easier one to use. So all C++ has going for it is inertia. It's moribund unless the committee reconsider their stance on intentionally losing the performance competition.

Will Carbon improve the ABI situation? Will Carbon be easier to interface with from other languages?

A major role that C plays today is being the common protocol all languages speak[0]. C++ can't fill this role, and neither can Rust.

There is a huge opportunity for some language to become the next common protocol, the common ABI, that all languages share in common.

(Maybe Rust could do this, but they haven't stabilized their ABI yet, and I don't the details.)

[0]: https://faultlore.com/blah/c-isnt-a-language/

Well it's not really C that fills that role it's the C ABI which any language can use without an ounce of C. Rust can use the C ABI.

It would be nice if there was a somewhat higher level ABI that languages could use though. The C ABI is very low level and tedious.

Carbon is performance-first, so ABI instability is the default. We plan to have opt-in ABI stability, but that story is not well developed yet. Replacing C as the lingua franca is not a goal, at least not yet.

I remember reading that google tried to impress on WG21 and 14 the need to update the ABI and they were utterly opposed. The result is google is no longer interested in C++. Apple I think is also no longer interested in C++. I think also Swift now has a stable ABI.

A good write up of that is at https://cor3ntin.github.io/posts/abi/

It's implied if you know, but Corentin's post doesn't actually link Titus's C++ proposal P1863 "ABI: Now or Never" which is what we're most concretely talking about here.

Titus correctly predicts the committee's actual response and highlights its danger, summarised in the title. You can pick now, as Corentin desires. You can pick never, which Corentin despairs at - not unreasonably because it means you're giving up performance. But Titus highlights the third option, the committee can instead dither forever never having the courage to announce an ABI break but also lacking courage to declare absolute stability with the encouragement that brings for legacy systems.

ABI Now is - at least in performance - competing with Rust. An ABI swap can make some C++ have the same performance as the analogous Rust which wasn't possible with the old ABI and that matters for outfits like Google.

ABI Never is a different niche. Guaranteed ABI stability gives C++ certainty. It makes C++ a stronger contender for some applications where today it can't go and nor can Rust because people don't think "Just recompile" is a reasonable choice, whether they are correct or not.

ABI Dither is neither of these things. There is no certainty, just because the committee is dithering today doesn't mean they won't make a decision tomorrow, or next year. But meanwhile you're not competitive with the best in class alternatives