LLVM is the only target for native

[eeshvardasikcm]

Summary of issue:

How will Carbon Project have complete C++ interoperability if Carbon is so heavily dependent on LLVM SDK alone?

Details:

Variable build environments, native build options

Android Studio has LLVM already installed for game developers that use the NDK. Vulkan is one major industry option for accelerated graphics. Visual Studio has a wide range of optional applications for Windows and cross platform development.

Has the Carbon Project placed any other Native SDKs on the horizon of the Carbon roadmap aside from LLVM?

Is C++ interoperability a complete solution?

If the current plan of doing LLVM and then C++ interoperability the only necessary solution, because that allows easily pluging into all of these other SDKs at that time?

If yes, then maybe it would be smart to add all of these other popular native SDKs to the Carbon language feature list.

Any other information that you want to share?

Carbon Language has the potential to be the leading language plugin extension in every IDE.

GitHub search for these other native SDKs in Carbon Project issues has zero results from the mobile version of GitHub. I think the people should see the name Vulkan next to Carbon.

[jonmeow]

I've converted this to a discussion because I think you're mainly asking to understand the current plans. "Leads questions" are really to get their feedback or decisions on language design, rather than asking general questions about Carbon. Typically this is done by listing a few options with trade-offs. Leads questions need to offer a decision for leads to make.

First, I'm a little confused by your description of LLVM as an SDK. I think it's helpful to think of it as compiler infrastructure, rather than an SDK. For example, reading through Vulkan's development environment, you'll note comments like "You should have a compiler that supports C++17 (GCC 7+ or Clang 5+)." Here, GCC and Clang are compilers; Clang is an LLVM-based compiler. Thus, even with your example of Vulkan, you can see an example wherein they support compiling with Clang/LLVM. Similarly, you can look at Visual Studio's Clang/LLVM support. Clang is a way to compile C++ code, and LLVM is infrastructure supporting that.

Second, there may still be a question about Carbon's ability to support C++ SDKs. The answer is, it'll probably be mixed based on how Clang handles the SDK, but here are a couple pages where you can read through to understand plans:

• How will Carbon's bidirectional C++ interoperability work? in the FAQ gives a very high level overview.
• Interoperability philosophy and goals dives a bit deeper on plans, although we don't have an implementation to share at this time.
  • Support mixing Carbon and C++ toolchains talks about supporting interop when mixing toolchains. For example, if you have a pre-compiled C++ library that provides only a header, Carbon would use the C++ ABI.
  • The non-goal Full parity between a Carbon-only toolchain and mixing C++/Carbon toolchains describes the limitations of what can be achieved when mixing toolchains.
• Clang MSVC compatibility as an example of how Clang achieves compatibility when multiple toolchains are in use.

Third, regarding your note about IDEs, we do plan to offer some IDE support per the language tools and ecosystem goal. As noted under the "developer tooling" subheader, while there are many different IDEs, we hope to unify some support by providing a LSP implementation.

Finally, regarding your comment about "Vulkan next to Carbon", Carbon's interoperability philosophy is that people should be able to consume C++ SDKs without the SDK needing to migrate to Carbon. Similarly, a library should be able to migrate to Carbon without requiring their consumers to stop using C++ -- possibly not even noticing they're now calling Carbon code. While there should be advantages to providing an SDK in Carbon versus C++, the interoperability goal of Carbon is that it should be possible to use existing C++ libraries and SDKs without do anything other than making sure their C++ code compiles with Clang.

[eeshvardasikcm]

I've converted this to a discussion because I think you're mainly asking to understand the current plans.

Thank you for explaining Carbon in relative perspective to this concern I had.

Thats a good idea to put this to a discussion. I didn't expect such a thorough answer. I will take care to address these topics according to your response in the future and try my best to contribute according to your response and current docs.

If I get a chance, a thorough reply to your explanation could help to clarify my concerns, and also help to develop the topic.

[eeshvardasikcm]

I've converted this to a discussion because I think you're mainly asking to understand the current plans. "Leads questions" are really to get their feedback or decisions on language design, rather than asking general questions about Carbon. Typically this is done by listing a few options with trade-offs. Leads questions need to offer a decision for leads to make.

Thanks for converting to discussion quickly. That helps show that Carbon GitHub is active and well organized.

First, I'm a little confused by your description of LLVM as an SDK. I think it's helpful to think of it as compiler infrastructure, rather than an SDK. For example, reading through Vulkan's development environment, you'll note comments like "You should have a compiler that supports C++17 (GCC 7+ or Clang 5+)." Here, GCC and Clang are compilers; Clang is an LLVM-based compiler. Thus, even with your example of Vulkan, you can see an example wherein they support compiling with Clang/LLVM. Similarly, you can look at Visual Studio's Clang/LLVM support. Clang is a way to compile C++ code, and LLVM is infrastructure supporting that.

That was my mistake. I read the LLVM docs to an introductory point necessary for me to make some install decisions a little while ago. Since then, my memory has forgotten some details.

Second, there may still be a question about Carbon's ability to support C++ SDKs. The answer is, it'll probably be mixed based on how Clang handles the SDK, but here are a couple pages where you can read through to understand plans:

Yes, this is specifically where my concern is. If I get the time, I will rephrase my concerns in this area after studying these links. Maybe we will get a chance to discuss this topic again.

Third, regarding your note about IDEs, we do plan to offer some IDE support per the language tools and ecosystem goal. As noted under the "developer tooling" subheader, while there are many different IDEs, we hope to unify some support by providing a LSP implementation.

Great! That's exciting to know.

Finally, regarding your comment about "Vulkan next to Carbon", Carbon's interoperability philosophy is that people should be able to consume C++ SDKs without the SDK needing to migrate to Carbon. Similarly, a library should be able to migrate to Carbon without requiring their consumers to stop using C++ -- possibly not even noticing they're now calling Carbon code. While there should be advantages to providing an SDK in Carbon versus C++, the interoperability goal of Carbon is that it should be possible to use existing C++ libraries and SDKs without do anything other than making sure their C++ code compiles with Clang.

Maybe my post was written with some glimpse in mind about the vast potential of Carbon language. According to your explanation here, it appears Carbon is designed in a way that Carbon doesn't need to specifically market for, or target any specific use case.

Carbon language, after all, is a coding language and that truth is sometimes difficult to picture considering the developers first impulse to apply Carbon language to their own development goals. Carbon design appears to unlock access to the C++ world in a way that opens the imagination.