I'm jumping into this a few hours late, but nobody has actually straight up asked the real question: Why try to compete with Rust while not really being a better Rust? The linked article generally defines a language that is more of the same, while Google is throwing Go under the bus to make it happen. The number of current and former Google employees that transitioned from being Gophers to being Rustaceans that I kno…
Google Launches Carbon, an Experimental Replacement for C++
71–80 of 243 posts
Re: Google Launches Carbon, an Experimental Replacement for C++
#72I thought Linux was C only and Linus is actively hostile against cpp for some good reasons.
Re: Google Launches Carbon, an Experimental Replacement for C++
#73I'm jumping into this a few hours late, but nobody has actually straight up asked the real question: Why try to compete with Rust while not really being a better Rust? The linked article generally defines a language that is more of the same, while Google is throwing Go under the bus to make it happen. The number of current and former Google employees that transitioned from being Gophers to being Rustaceans that I kno…
What's wrong with Swift? It's a replacement for Objective-C, that nobody besides macOS/iOS devs used anyway, therefore it's no big deal if nobody uses it outside of macOS/iOS development, as it's not a regression
Re: Google Launches Carbon, an Experimental Replacement for C++
#74It’s clear that the value promise of Carbon is to make it attractive to port existing C++ applications to it. But how this is accomplished, article does not go into detail in this. Is there going to be ABI compatibility with C++? What are the features that make Carbon a better porting target than Rust?
I think Carbon will be a much better choice for extending a C++ project.
Rust might be a good choice if you are able to start from scratch or the project has C bindings.
Re: Google Launches Carbon, an Experimental Replacement for C++
#75Re: Google Launches Carbon, an Experimental Replacement for C++
#76How to make your replacement for a C language Google-able: name it after an API for a C language: Carbon was one of two primary C-based application programming interfaces (APIs) developed by Apple for the macOS (formerly Mac OS X and OS X) operating system. Compare also keywords or key terms: Carbon will be built on a foundation on modern programming principles, including a generics system, that would remove the need…
You have to google explicitely for "Carbon API" for it to show up.
Whether even now, "carbon programming" or "carbon code" give results for Carbon language - and some other non-c++ libs named Carbon.
Even "carbon" by itself gives me some Carbon language links.
Re: Google Launches Carbon, an Experimental Replacement for C++
#77Earlier quoted context omitted.
Nim also uses 'var' and 'let' for mutability. I like it as well.
knowing neither of these languages i’d rather it be labeled something more clear as neither one of those screams immutable to me. the immutable variant should use the ‘const’ keyword instead.
Re: Google Launches Carbon, an Experimental Replacement for C++
#78- https://chromium.googlesource.com/chromium/src/+/refs/heads/...
- https://security.googleblog.com/2021/09/an-update-on-memory-...
Would carbon be a variation of "making C++ safer" mentioned in that blog post?
Re: Google Launches Carbon, an Experimental Replacement for C++
#79Re: Google Launches Carbon, an Experimental Replacement for C++
#80Does anyone know what the move / copy semantics are in Carbon? I can't figure it out from the docs (admittedly I have not looked hard at all). I would say the number one weakness of C++ is its model of copy by default and often by surprise. For example: f(std::move(x)) will copy x if x is const or f takes its value by const ref - rather than a compiler error as you might reasonably expect (if you don't know the C++ r…
The move situation would be less confusing to newcomers if they had called it what it really does, std::become_rvalue_reference or something.
template T std::move(T&& t) {
return T(static_cast::type&&>(t));
}
But it would have had performance implications.