Can see the rest of that file and the adjacent `raw_hashtable.h` for the rest of the SwissTable-like implementation and `hashing.h` for the hash function.
FWIW, it consistently out-performs SwissTable in some respects, but uses a weaker but faster hash function that is good enough for the hash table, but not good for other use cases.
> 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.
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.
But it isn't that we're directly using this, but that definition checked generics are fairly similar to the ideas in that series of proposals, and that led to the generics in Swift. Also closely related to the generics in Rust, etc.
A big goal was being short and easily pronounced, including by non-native English speakers, in a recognizable way from reading the text. That made the overwhelming majority of "fun" spellings not work well.
On one hand, I feel like we're just not as good at naming as Rust and Zig. Both of those names are :chefskiss:
On the other hand, Carbon does have a bunch of awesome puns waiting for us... So we've got that going for us. =D
I think you're missing the point of the example in a major way...
Personally, I care about finding ways to support a bunch of these other use cases where we can and in good ways. Especially things like build times, dynamically loaded plugins, and vendored libraries. I think we can and _need_ to find reasonable solutions to those.
The specific example is the only one called out because it's the only one that is fundamentally a non-goal.
The other use cases I think we can find good ways to support, but they may not look like a stable ABI for the entire language. Maybe a designated subset or surface which is designed to have long-term link compatibility in some way, etc. Removing that specific use case is important because it opens up more candidate solutions in the space.
And to be clear, this isn't a straw-person use case. This specific wording and use case was a response to that use case being actively supported by the C++ committee on several occasions.
We tried other names, but we found collisions with essentially all of them. =/ We ended up picking a "least bad", and actually talked to a couple of folks familiar with the old usage to see if it was a worse collision than we realized. They weren't delighted but generally shrugged. So here we are. =/
It's definitely not perfect, but I think it's much more searchable than "C" or some other choices. Ultimately, I think its at least not bad enough to matter compared to the actual project.
"Chandler has explicitly said that he doesn't see a reason to solve data races."
Er, the slide title says that solving this is highly desirable, just not a strict requirement for security purposes.
Not sure how that's the same as "doesn't see a reason to solve data races". I see lots of reasons. I just think it is possible to achieve the security goals without it.
FWIW, I'm hopeful we'll end up including this in whatever model we end up with for Safe Carbon. It's just a degree of freedom we also shouldn't ignore when designing it.
If you're going to create a dichotomy between two languages, I think we're dramatically closer to TypeScript.
The whole point of Carbon is to integrate into and re-use an existing ecosystem of software written in C++. It's as far from the Dart approach as it can get without literally being a TypeScript style approach.
Ultimately, this dichotomy doesn't help discuss Carbon. I think it is useful for looking at Rust (until/unless Crubit or something similar radically changes its interop story), Go, and many other languages. But not Carbon IMO. It loses all of the important nuance. And there are important and meaningful differences from TypeScript's approach that we've talked about since announcing Carbon, but they don't make it anything like Dart's strategy.
FWIW, I disagree about Carbon following the Dart plan (Carbon lead here).
Carbon is following a plan much more analogous to Kotlin -- we even say that on our site very explicitly.
The "subset" of C++ APIs you emphasize is only about there existing some long-tail esoteric parts of C++ that may be used rarely enough to not worry about. Everything that people use we'll need to support here. We think about interop constantly and are designing it into every aspect of the language.
Success for the Carbon Language requires it to successfully be an independent and community driven project. We may not succeed (this really is an experiment), but we're working hard to engage broadly and early in large part because of this being such an important goal and priority for us.
Projects like this have to start somewhere, but can grow and become community endeavors. We are also already seeing strong interest from other companies and organizations in participating in this experiment.
A bunch of comments seem to be comparing and contrasting CMake+Ninja vs. Bazel. Just my two cents, but I think that's missing the real point of this work.
It isn't about whether Bazel is a better build system for LLVM. At least, that isn't my motivation.
There are users of LLVM's libraries that use Bazel. Whether for good or bad reasons, it is extremely useful to enable them to use LLVM's libraries with a fully native Bazel build. That is my motivation: enabling the users of LLVM libraries that need to use Bazel for whatever reason to have the best possible experience.
Can see the rest of that file and the adjacent `raw_hashtable.h` for the rest of the SwissTable-like implementation and `hashing.h` for the hash function.
FWIW, it consistently out-performs SwissTable in some respects, but uses a weaker but faster hash function that is good enough for the hash table, but not good for other use cases.