This is doomed to fail b/c it uses semicolons. Why would you use semicolons in 2022?
Google Launches Carbon, an Experimental Replacement for C++
151–160 of 243 posts
Re: Google Launches Carbon, an Experimental Replacement for C++
#152Earlier quoted context omitted.
> Rust isn't any more complex, but it's not radically simpler either. Safe Rust doesn't have classes, inheritance, copy constructors, move constructors, header files, preprocessor, textual substitution macros, code executing before main(), exceptions, global variables, pointer arithmetic... Looks radically simpler to me.
Instead Rust has a borrow checker, procedural macros of different types, half a parallel language when using unsafe, etc... And by the way, Rust does have pointer arithmetic. It's not clear to me that either is simpler or easier. The big point of Rust is really memory safety, not ease of use or simplicity.
Rust doesn't have pointer arithmetic in the same way that C and C++ do. All you can do with pointers in rust is offset them.
Re: Google Launches Carbon, an Experimental Replacement for C++
#153"The keepers of C++ prioritize backward compatibility, in order to continue to support widely-used projects such as Linux" I thought Linux was C only and Linus is actively hostile against cpp for some good reasons.
No post body was provided.
Re: Google Launches Carbon, an Experimental Replacement for C++
#154I'm probably just biased, but to me the problem with modern C++ is its complexity. The mental model of the language, its syntax, and the amount of history / number of interfaces a programmer needs to be familiar with to be productive are all too large. Rust isn't any more complex, but it's not radically simpler either. Carbon doesn't look like it solves this problem. It would seem that creating a language that is exp…
It is difficult to tell sometimes due to its religious backward compatibility, but C++ has been becoming significantly less complex over time. I have a large C++ code base (originally hundreds of thousands LoC) that I aggressively modernize, essentially rewriting it idiomatically in new versions of C++. It was originally written in C++0x/C++11, rewritten in C++17, and is currently being rewritten in C++20. You can barely tell the code bases are related beyond being functionally similar.
It is also important to separate C++ the language from its standard library.
As C++ the language has modernized, it has dramatically reduced the lines of code to express a given thing. And the more modern way of expressing the thing has stronger type safety, more flexibility, and better composability. Things that used to require a lot of template metaprogramming magic to pull off are now clean one-liners. Particularly in C++20, which is probably the biggest step-change since C++11, metaprogramming is simultaneously much more powerful and much more readable. A lot of code that used to be written is now metaprogrammed. Previous use cases that required C macros largely have native C++ equivalents at this point.
The major issue that makes C++ seem complex is the standard library, which was largely designed and written for legacy versions of C++. If you use the standard library heavily, it tends to want to be used in the style of C++ for which it was originally written. If you built a standard library for C++20 from first principles, it would look quite different from the one we have. Hence the proliferation of non-standard "standard" libraries for C++.
Re: Google Launches Carbon, an Experimental Replacement for C++
#155Earlier quoted context omitted.
to me that's the greatest benefit of C++ and hence why it's so successful. it's kitchen sink language. choose what features you want. choose your own style. you wanna do OOP | DOP suit yourself. that versatility is why C++ is unmatched in terms of where it's deployed.
Isn't the 'kitchen sink' approach what ended up causing Perl to fade from relevance? I am only casually aware of this, and I may be totally misremembering things, but Perl used to be seen as a swiss army chainsaw but people eventually came to realize that maintenance was a nightmare.
Perl faded away because there was an alternative (Python) and it was not a kitchen sink. For C++, there's no alternative at all. People have to bear with it.
Re: Google Launches Carbon, an Experimental Replacement for C++
#156Earlier quoted context omitted.
You don't need a full-on borrow-checker to make move-by-default safe. If you can track whether or not a variable has been (definitely) initialized, you can track whether or not a variable has been moved from. It's the same basic logic. And there are languages without full borrow checkers that can do that--Java is the first one that comes to mind.
Don't you need to know when all borrows end? E.g. here: fn main() { let x = [1, 2, 3]; println!("{:?}", x); let y = x.map(|x| x % 2 == 0); println!("{:?}", y); } x is borrowed by println (or rather by code that println expands to) and then it is moved by array::map. The compiler needs to know that before x.map(), x is not borrowed anymore. Otherwise it could be that println actually stored a reference to x somewhere…
Sure but that is already a risk in C++ at the moment.
void foo() {
if (true) {
Foo f;
stores_a_reference_to_foo(&f);
}
uses_stored_reference_to_foo();
}
Re: Google Launches Carbon, an Experimental Replacement for C++
#157I'm probably just biased, but to me the problem with modern C++ is its complexity. The mental model of the language, its syntax, and the amount of history / number of interfaces a programmer needs to be familiar with to be productive are all too large. Rust isn't any more complex, but it's not radically simpler either. Carbon doesn't look like it solves this problem. It would seem that creating a language that is exp…
This seems to be a very hard idea to convey to people. Zig is on the opposite extreme-- the mantra being "There must only be one way to do something". Ergonomics and simplicity seem to be overlooked aspects of programming language design
Re: Google Launches Carbon, an Experimental Replacement for C++
#158Earlier quoted context omitted.
The official webisite ( https://github.com/carbon-language/carbon-lang ) goes into better detail, but the gist is that you can basically #include C++ libraries and use their APIs as-is, without needing to resort to unsafe blocks or having to write more idiomatic wrappers.
Does this mean that Carbon needs to include a whole C++ compiler as a part of Carbon compiler?
Carbon uses LLVM as a backend, so I imagine they just call into Clang for such things.
Re: Google Launches Carbon, an Experimental Replacement for C++
#159Why does Google keep choosing un-googleable programming language names (go and now carbon)?
How else are they going to enable pedant conversations about how "the language name is carbon not carbon-lang"?
Re: Google Launches Carbon, an Experimental Replacement for C++
#160Earlier quoted context omitted.
You don't need a full-on borrow-checker to make move-by-default safe. If you can track whether or not a variable has been (definitely) initialized, you can track whether or not a variable has been moved from. It's the same basic logic. And there are languages without full borrow checkers that can do that--Java is the first one that comes to mind.
Don't you need to know when all borrows end? E.g. here: fn main() { let x = [1, 2, 3]; println!("{:?}", x); let y = x.map(|x| x % 2 == 0); println!("{:?}", y); } x is borrowed by println (or rather by code that println expands to) and then it is moved by array::map. The compiler needs to know that before x.map(), x is not borrowed anymore. Otherwise it could be that println actually stored a reference to x somewhere…
Without a borrow checker, you won't be able to eliminate dangling reference issues. But that's an orthogonal issue to move safety.