chandlerc1024

FYI, we ended up implementing a _really_ nice SWAR version in the Carbon derivative of SwissTable that might be worth looking at for inspiration: https://github.com/carbon-language/carbon-lang/blob/trunk/co...

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.

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...

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

> 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.

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.

It was also called that.

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.

We played with some, but none stuck.

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

(Carbon lead for context)

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.

(Carbon lead here)

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.

+100 btw. =D

Yep, that's the plan.

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.

It was made public at CppNorth, a C++ conference, earlier today. The page you mention is a bit out of date though, you can find the update to our plans here: https://github.com/carbon-language/carbon-lang/commit/4aa462...

FWIW, our governance structure is here: https://github.com/carbon-language/carbon-lang/blob/trunk/do...

(one of the Carbon leads)

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.

At the very least, can check when the target isn't a basic block and thus it's a clear win. Will fix your case.

I'm dubious about the whole thing though. Seems like it may day from when branching "down" vs. "up" mattered to branch prediction.

(disclaimer: I'm one of the authors of this)

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.

Test suite, without a doubt.

Asking humans to be careful at scale (whether authoring or reviewing) just won't work.

Keep in mind that you need loooooots of test suites, not just one.

We're seeing the exploration of a new surface through speculative execution and related hardware techniques. There is basically a backlog of exploring this surface that researchers and security folks in industry are working to process. Eventually will settle into a more steady state, but takes a long while to push through the new territory.

Short version: it passes a pointer to the pointer forcing a double indirection rather than a single.

Simple attempts to fix don't really work. Not even sure an ABI break will be enough, but it would at least be a minimum requirement.

I think it's hard to predict what a community will be interested in deep-diving to understand. And I'm not sure that HN is super representative of its interests either. The email was aimed at LLVM folks, not HN.

I generally trust the LLVM community to ask for any details they need to reasonably evaluate a proposal like this, and I also trust the folks on my team to work to address those requests to the extent we can.

I don't think it makes sense to try and speculate about what option will make the most sense if LLVM says "nope". Generally, I plan to encourage the team to see if there is a good way for us to address concerns the LLVM community has while still getting the technical things we need. IMO, it would be somewhat surprising if there were no reasonable path where this could both be reasonable for the LLVM community and Google. Doesn't mean it is impossible, but having detailed and precise plans don't seem like a priority. IMO, the priority is finding a good way to work with the LLVM community here.

On a more meta level, I also think it would be good for lots of folks (HN, twitter, etc.) to be a bit less harsh in their criticism of initial posts proposing new efforts/projects. I've seen this several times recently (ranging from this to the V language stuff). I'd suggest folks maybe ask questions and give people a chance to flesh out their thoughts and provide missing context rather than hammering in feedback. In many cases, I think the feedback is actually good, but the method of delivery makes it much harder for people to learn from and respond to constructively.

Anyways, enough meta...

Just so we're completely clear, Google has been an incredibly long-term contributor to basically all parts of LLVM. So have sooooo many other companies. This is a really cool project IMO, but it doesn't represent a significant change in who or how much anyone is contributing to LLVM... It's a drop in the bucket.

And for the record, LLVM is doing fine with all these corporate contributors.

I'm not trying to say that this can't be a concern for OSS communities and projects, but LLVM seems to have a quite successful and sustainable model here.

Either one looks completely fantastic, I assure you.

I have helped people on my team write promotion packets in both forms. Both worked perfectly well.

(as stated elsewhere, this effort is in my team at Google)

FWIW, while I think libc is super important, and I'm really excited about this project and the opportunity it represents, I think the LLVM project and community is much larger than libc. =D I don't think you need to worry about this effort changing anything about how LLVM operates. And we're currently just asking if they're interested. =]

Hi, full disclosure, it's my team working on this at Google FWIW, and the technical lead for much of Google's contributions to LLVM.

When we asked the community if they were interested in us developing this in the open as part of LLVM, we meant as part of LLVM. We're very committed to the LLVM open source project, and think it would be great for this to be developed within that framework (technical, project, community, the whole works). I'm hopeful that the community is in fact interested.

But we also were asking -- we have some specific technical goals that we'd like to make sure we can accomplish. It really is the community's decision whether this makes sense. =]

Working closely with Intel and others on these issues I have seen zero evidence that anyone realized the security implications and shipped anyways. Zero evidence.

The intent is definitely to handle this as well. (Not really going to try and dig into legal reasoning here.)