July 27

On Tuesday, 26 July 2022 at 16:34:49 UTC, Ola Fosheim Grøstad wrote:

>

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

>

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.

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.

I don't think they can afford to provide any automatic memory management solutions, since everyone is basically looking for an excuse to hate on them

At best, I can imagine them enshrining C++'s make_shared, shared/unique_ptr, etc constructs for better optimisations/error reporting/airtight implementations, so that nobody can accuse them of introducing performance detrimental things like GC(notwithstanding the fact that RC is also a GC technique)

I genuinely think this thing might be successful, people disliked Go so much, yet look where it is today: the entire foundation of the cloud is built on it; Dart had nothing to it's name, now it's fighting JavaScript for supremacy as the most cross-platform friendly language; I feel Carbon will be a similar success as well, if they really get C++ interop, tooling, and job opportunities right

July 27

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

>

Nim is similar that sometimes their ORC GC fails and you need to use Bohem.

No, that's not how Nim's ORC works. It is precise and doesn't need Boehm. But nice try to conflate my decade of hard work with some vaporware clown language.

July 27

On Wednesday, 27 July 2022 at 03:51:28 UTC, Tejas wrote:

>

I don't think they can afford to provide any automatic memory management solutions, since everyone is basically looking for an excuse to hate on them

They have already scared away the most opinionated C++ users by using an unfamiliar syntax and removing things like constructors, multiple inheritance and exceptions...

>

At best, I can imagine them enshrining C++'s make_shared, shared/unique_ptr, etc constructs for better optimisations/error reporting/airtight implementations, so that

That would be great, as make_shared provides the same as you would get from ARC in Swift!

>

I genuinely think this thing might be successful, people disliked Go so much, yet look where it is today: the entire foundation of the cloud is built on it;

Yeah, that is the scary part, isn't it? Carbon currently uses «CapitalizedFunctionNames()» just like public Go functions. Which is somewhat annoying as it creates a rather noisy picture in the editor. I prefer everything in a standard-lib being lower case as my own types should be more visible than the standard ones. (Phobos…).

>

I feel Carbon will be a similar success as well, if they really get C++ interop, tooling, and job opportunities right

I don't think they will start implementing the compiler itself until late 2023, so I guess we have to wait and see. Maybe ready for adoption in 5 years? So they effectively compete with what people expect from C++29?

I would feel better about Carbon if they had to compete with C++, as then they would listen more to the community, but maybe they only "compete" with their own management? In which case it will end up with whatever Chandler Carruth fancies.

Anyway, they are open for breaking changes for another year, and that is a breath of fresh air :-)

July 27

On Wednesday, 27 July 2022 at 05:08:24 UTC, Araq wrote:

>

No, that's not how Nim's ORC works. It is precise and doesn't need Boehm. But nice try to conflate my decade of hard work with some vaporware clown language.

That was because of bugs in ORC where it was necessary to revert to an earlier GC type, for example Bohem. Will ORC be production ready?

July 31

Btw, looks like Carbon might end up with the same parameter passing as -preview=in ?

https://www.foonathan.net/2022/07/carbon-calling-convention/

1 2 3 4 5 6 7 8 9
Next ›   Last »