https://9to5google.com/2022/07/19/carbon-programming-language-google-cpp/
Carbon, a new programming language from Google, aims to be C++ successor.
I personally am not convinced that Carbon will be my C++ substitute/successor. But I’m always interested to hear about programming languages which I don’t know yet. So thanks for mentioning and giving a link. 
Greetings
Peter
I do not know if Carbon will succeed, D was declared a better C++ successor years ago, but is not used much nowadays despite it’s good set of tooling so I am a bit sceptical with all these new languages.
Going off topic: methink Haiku needs more a flattened API on top of the C++ API (just like what was done with QT for Python and all) instead of a new language to interface with it. Once flattened, interfacing with existing languages will be much easier. Could that be a scope for a summer project (like Google CodeIn or Summer of Code)? Personally I am not good enough with API design not with C++.
1 Like
If you desire always welcome to create a PR for it at haikuports
Haiku should have its own simple but powerful programming language called Poetry.
2 Likes
I don’t think that for a desktop OS like Haiku this is really needed (or practical). Yet another hurdle for new developers (not to speak of the developer time needed to design and implement the language). I’d rather see python fully supported for application development with the Be API (not for the OS itself).
OT: for an experimental OS like Serenity it is of course a cool thing to have it`s own language like they are developing now.
Wasn’t Go supposed to be exactly that ?
I would prefer Haiku API bindings to multiple languages that would include Python, Ruby, Swift and so on.
It is not that simple. The API is full of assumptions related to the “not flattened” nature of C++. We really need the inheritance. We need a way for a BWindow to destroy all BView inside it when it is closed. We rely a lot on C++ destructors being called when a function exits.
The work for a flattened API was already done a few years ago for example with Bethon. No one uses or maintains it. There was another attempt later, trying to support more languages, called libcharlemagne. Then there were attempts with SWIG. And again. And more recently there are bindings for Rust.
So, please do not start yet another project for bindings 
and contribute to one of these instead?
4 Likes
From the article: “For example, Golang (or simply Go) was created for the purpose of improving the development of servers and distributed systems and has since been adopted by the public.”
YAB is plenty flat and Haiku-specific besides! I see that Yann64 has already got his own fork of the haiku-swig-api package and has had it for several years. I do like Rust though and there are wrappers for multiple GUIs also.
Re:Flattening
Dynamic dispatch is expensive and inheritance uses dynamic dispatch heavily. Interface inheritance, on the other hand, is implementation specific. In Java, interfaces were slower than generics and relied on double-indirection internally. Rust uses interfaces semantically and because the function pointers are all constants, they get constant-folded all the time for zero-cost abstraction. In short, your mileage may vary.
Re:Carbon and AmigaE
It’s too soon to say whether this takes off. Single-inheritance only reminds me of AmigaE which I did like back in the day. I started writing an object-oriented framework for AmigaE at one point but it was too late. AmigaE is doomed to the bitbucket because its E-List datatype is 32-bit only and cannot be made 64-bit friendly without rewriting the entire language.
Google is awash in money right now and can come out with all the new languages they want. That doesn’t mean I’ll use any of them. I don’t use Go yet because its garbage collector is still the subject of much tweaking and it is supposed to be a server language. If I wanted to have a binary language on the server, I’d use WASI from Wasmer which has a nice sandbox based on WebAssembly.
This one is coupled quite nicely to C++ ABI and can consume C++ classes directly, where as Go was more a “better C”. Go doesn’t really have OO for example.
2 Likes
It is not possible to do it cleanly as @PulkoMandy said. I know, I tried. In the early 2000’s I started making a flat API wrapper so that Free Pascal could write BeOS apps. It never got much past a prototype phase, but there were stumbling blocks even dong that because the BeAPI assumes that you are creating the controls in a certain way and as part of a certain thread. I remember that one of the controls (BTextView maybe?) had to have a hack to allow it to be made… if you want to look, the code is on GitHub.
2 Likes
As long as you lock the looper of whatever window you are modifying, you can create controls on any thread you want, so that shouldn’t be a problem. Xlibe, the X11 compatibility layer I wrote, does this all over the place.
5 Likes
To me they may have made things more consistent and added more syntactic sugar, but I don’t see much simplification. Just different syntax. They didn’t remove the ; at end of every line, they change uint64 i = 1; to var i: i64 = -1; they didn’t remove if () to if …
So while it might be a good language, there are a lot of other good languages as well… And can we please just stop needing semicolons at the end of every line…
1 Like
Honestly, that is still like 50% of compile errors I get when working on Haiku code, the only other language I really use, lua, doesn’t have that.
1 Like
Although it does have optional semicolons, which I think are a good idea.
Carbon is by its nature an experiment. Chandler says Google also have people looking at whether they can just Rewrite-it-in-Rust more often because that’s another way to get to somewhere better. There will be at least some pressure induced on WG21 (the committee for the C++ standard) by the existence of another language in this space, if it starts to get some traction, even if it doesn’t ultimately come to much. It’s probably more newsworthy because it’s Google (well, a handful of Google employees, partly on company time) than something like Jon Blow’s Jai language.
All the new languages in this space exploit a major weakness of C++, the defaults are wrong. There are a bunch of places in C++ where a competent C++ programmer has to always explicitly override the default language behaviour because it’s wrong. They can, but why should they have to? In other languages it just works. So people have tried arguing that WG21 should fix this by changing the defaults. Making that more practical was the purpose of “Epochs” (like Rust’s Editions, but for C++) which was rejected for C++ 20. But the broader sweep of such problems as summarised in P2137 is in some measure why Carbon happened. P2137 is a paper written for WG21 by some of the same people, titled “Goals and priorities for C++” and the committee’s response was very negative. These are not its goals or priorities. If they’re yours then C++ is the wrong choice for you.
1 Like
LUA sucks in other regards though. This language drove me nuts a couple of years ago. I would not touch it again 
. C++ is hard but at last “i know what I get”.
What defaults are wrong? Granted I work only with c++11 at most since all the new fangled stuff adds more confusion than it helps. I prefer less constructs and variations so I know what I get and what I can do without causing troubles. High level languages simply hide tricky stuff under the hood and then it surfaces even uglier as memory leaks or (in the case of Swift) nasty to debug crashes somewhere deep inside since you don’t know what gory magic is played under the hood.
2 Likes