On Monday, 25 July 2022 at 05:24:54 UTC, Paulo Pinto wrote:

I'm still struggling to understand why would Google goes to the effort of creating a new language (that they seemingly don't want to manage alone in the long-run) instead of forking Calypso. AFAIK Carbon is similar to Calypso. It all just seems really expensive.

On Tuesday, 26 July 2022 at 11:12:15 UTC, Guillaume Piolat wrote:

They build a compiler so that they can change and extend C++ semantics with full freedom, including improved semantic analysis. Calypso would be a drop in the ocean and even more limiting than evolving Clang (they are not evolving clang as such).

I don't know if they mind maintaining the compiler themselves. Most likely they need a proof of concept and industry backing to get management approval for a bigger budget. Also, you get better tooling such as dedicated IDEs by being open.

In the end I assume they will fork clang and maintain their own C++ parser/semantic analysis in addition to maintaining a Carbon compiler written from scratch. I assume they have millions of lines of C++ code and the Carbon repo will pass 10 times the number of likes that is on the DMD repo in another week (they are close to 20K likes after only a week). Despite the syntax…

Or… maybe they will drop it after a year and take their design-artifacts as improvments to ISO C++. Either way, the Carbon team doesn't have much to loose from this approach. (The risk is on the early adopters.)

On Tuesday, 26 July 2022 at 11:44:19 UTC, Ola Fosheim Grøstad wrote:

It is Google...

On Monday, 25 July 2022 at 08:05:52 UTC, Ola Fosheim Grøstad wrote:

Throwing C is the worst one can do

Throwing C++ too is not the right way to go

The proper way to do is following Kotlin's success, embracing it to then do your own thing

The problem is most languages can't get past "embracing C", and they are stuck with it

Carbon already on a poor start by having to predeclare everything

It's 0.1, so they have long way to go, but reading what their goals are and roadmap makes it clear that it's something with huge potential, for people with C++ codebases

I feel you guys put too much emotions in your analysis, same with Go

On Tuesday, 26 July 2022 at 13:09:03 UTC, ryuukk_ wrote:

It is easy to see where this goes if their business unit funding doesn't run out.

Most of the team are ex-clang contributors that have moved on from clang and ISO related work, since Google lost the ABI break vote at ISO C++.

Carbon primary customer base is Google itself.

On Tuesday, 26 July 2022 at 13:09:03 UTC, ryuukk_ wrote:

Because? There is nothing particularly interesting about C, except very poor typing.

Besides, they already did this, you cannot increment pointers for instance.

Well, they did this too. They interop with it, but they do it in such a way that they have the option to phase it out in a later version, if my reading between the lines is correct.

Kotlin's success is Android, but the JVM environment is a completely different setting.

I guess you could say this is like Objective-C/Swift, but I suspect that Apple will phase out Objective-C eventually.

C is a big bleeding wound in your type system.

In what way? I observe what they do, what they say and how the wider programming community responds… There are no emotions involved.

What they have said is that Google has one team looking at integrating C++ with Rust. Then they have the Carbon team going the other way, from C++ towards something closer to Rust, and this is experimental.

At this stage, this probably is tagged as research and not development, that is my guess. They put a lot of emphasis on experimental, they would not do that if they had been allocated 40+ developers. So I guess they have to prove that this is a project that should move from research to development by showing industry interest or something like that? It isn't obvious that this is an initiative from high level managers, probably the other way around, don't you think?

On Tuesday, 26 July 2022 at 13:31:00 UTC, Ola Fosheim Grøstad wrote:

Because there is code still written in C, and rewriting it is not worth it, languages able to play nice with C gets ahead (C++, GO with cgo for example, they were able to kickstart a lot of their projects, and our beloved D too ;))

That's the thing i mention, being able to consume it to then eat it and get rid of it, most languages are stuck at the consume it part, Go managed to get past it

Kotlin is also phasing out Java/JVM by focusing on Kotlin Native for sharing code between Android/iOS and they are working on their WebAssembly compiler; completly phasing out JVM, notice the pattern ;)

Maybe emotions wasn't the proper word, skepticism maybe, i don't know, it's an impression i have, Go have merits and i feel we downplay its success a little, we should learn from it

Exactly, i agree with you

On Tuesday, 26 July 2022 at 14:35:21 UTC, ryuukk_ wrote:

Sure, they will be able to call C, I thought you meant that the language would retain C semantics at the bottom layer.

True, it makes no sense for Carbon to stay at C++17 compatibility when C++ hits C++29 :-)

Interesting, I didn't know this.

Yes, having a coherent memory management story is important. Go had a coherent memory management and concurrency solution from V1.0. That makes a biiig difference. It doesn't even have to be excellent, just something you can rely on.

Carbon does not have this yet, though… so maybe their success depends on how many years it takes for them to get there.

On Tuesday, 26 July 2022 at 15:36:10 UTC, Ola Fosheim Grøstad wrote:

They should be careful and determine roughly what kind of memory management they want as early as possible. If they don't they risk ending up like D which is painted into a corner with tracing GC and there is also a risk with too much annotation like Rust. Nim did this right as they have a good compromise between easy of use and GC versatility.

V language is currently using a tracing GC as a back drop until their "auto free" engine is complete, we will see how they succeed. Nim is similar that sometimes their ORC GC fails and you need to use Bohem. In general the strategy should be keep it simple and stupid in the beginning at the same time you do not prevent any advancement of new GC methods which D totally failed at.

That they mentioned that they want to a have lifetime annotation like Rust makes me suspicious that they will fail their goal, which is a simpler C++. Rust is not simpler than C++ as long you don't trench too far into meta programming and templates.

On Tuesday, 26 July 2022 at 16:00:38 UTC, IGotD- wrote:

Carbon will not have a GC. It will also not have Rust semantics as the checker would be too slow, at least that is what has been said.

Carbon will have more limited generics than C++, so that the "template" can be selected based on the signature constraints without instantiating it. In that sense it is simpler than C++.

I think they actually aim for faster than C++. I assume faster compilation and perhaps more clever optimizations, but I don't know if it is realistic to expect any significant speedups for performance oriented code. Perhaps for naive code?

I would hope that it would be possible to use ARC, but I don't think this will come from Google. I suspect ARC is "too slow" for their use cases?

I would hope that they make the compiler modular so that things like ARC can be "plugged" in by a third party.