Carbon Coding Language: Google’s Experimental Successor to C++

On July 19th 2022, Google introduced Carbon Language. What exactly is Carbon, and what does it aim to achieve? Note that the Carbon coding language is experimental.

To understand Carbon, we first need to take a look at the language it’s attempting to augment. That is, C++. It remains the dominant programming language for performance critical software, and has been a stable foundation for massive codebases. However, improving C++ is extremely difficult. This is due to a few reasons:

  • Decades of technical debt
  • Prioritizing backwards compatibility over new features
  • C++, ideally, is about standardization rather than design

Carbon, as Google puts it, is okay with “exploring significant backwards incompatible changes”. This has pros for those wanting to work with a language developing with the mindset of “move fast and break things”.

Carbon promises a few things in their readme:

Carbon is fundamentally a successor language approach, rather than an attempt to incrementally evolve C++. It is designed around interoperability with C++ as well as large-scale adoption and migration for existing C++ codebases and developers. A successor language for C++ requires:

  • Performance matching C++, an essential property for our developers.
  • Seamless, bidirectional interoperability with C++, such that a library anywhere in an existing C++ stack can adopt Carbon without porting the rest.
  • A gentle learning curve with reasonable familiarity for C++ developers.
  • Comparable expressivity and support for existing software’s design and architecture.
  • Scalable migration, with some level of source-to-source translation for idiomatic C++ code.

Google wants Carbon to fill an analogous role for C++ in the future, much like TypeScript or Kotlin does for their respective languages.

JavaScript โ†’ TypeScript
Java โ†’ Kotlin
C++ โ†’ Carbon?

Talk is cheap, show me the code

Okay, so what does Carbon look like then?

First, let’s see how to calculate the area of a circle in C++.

// C++ Code
#include <math.h>
#include <iostream>
#include <span>
#include <vector>

struct Circle {
  float r;
};

void PrintTotalArea(std::span<Circle> circles){
  float area = 0;
  for (const Circle& c : circles) {
    area += M_PI * c.r * c.r;
  }
}

auto main(int argc, char** argv) -> {
  std::vector<Circle> circles = {{1.0}, {2.0}};
  // Converts 'vector' to 'span' implicitly
  PrintTotalArea(circles);
  return 0;
}
C++ coding example

Compared to Carbon:

// Carbon Code
package Geometry api;
import Math;

class Circle {
  var r: f32;
};

fn PrintTotalArea(circles: Slice(Circle)) {
  var area: f32 = 0;
  for (c: Circle in circles) {
    area += Math.Pi * c.r * c.r;
  }
}

fn Main() -> i32 {
  // Array like vector
  var circles: Array(Circle) = ({.r = 1.0}, {.r = 2.0});
  
  // Array to slice implicitly 
  PrintTotalArea(circles);
  return 0;
}
Carbon coding example

My initial thoughts are that the syntax looks mixed between C#, JavaScript, and C++. Prepending “var” before each variable seems redundant. Why not a type name followed by a declaration? One might argue that it leads to easy variable identification without memorization of variable types but that makes little sense as you put the type anyway. The way variables are initialized with “:” instead of =, reminds me of Javascript. Not sure if that’s a good thing, it looks less like C++ than I expected. Oddly, they chose “import” for the system packages it seems which is also shared with Python. I do like the shortening of function to fn. You could argue shorthand is the point because it’s cleaner and smaller, but again why is it defined as a function and then an ‘i32’? Seems redundant. unless they decided fn FunctionName() -> i32 is shorter than int FunctionName(). It could be their goal is simply to separate the syntax from other known languages enough to recognize at a glance. Maybe I’m missing something.

One neat feature they’ve shown is the interoperability between Carbon and C++. You can call C++ from Carbon and vice versa. You can rewrite or replace as little or as much of your libraries as you want without fear of breaking anything. Well, at least without breaking anything more than normal when dealing with C++.

// C++ code used in both Carbon and C++;
struct Circle ( float r; ); 
// Carbon exposing a function for C++:
package Geometry api; 
import Cpp library "circle.h";
import Math; 
fn PrintTotalArea(circles: Slice(Cpp.Circ/e)) {
    var area: f32 = 0;
    for (c: Cpp.Circle in circles) { 
        area += Math.Pi * c.r * c.r;
    } 
    Print("Total area: {0}", area); 
}
// C++ calling Carbon:
#include <vector>
auto main(int argc, char** argv) -> int { 
    std::vector<Circle> circles = {{1.0), (2.8)}}; 
    Geometry::PrintTotalArea(circles);
    return 0; 
}
C++ code used in both Carbon and C++

And better memory safety is also promised

Safety, and especially memory safety, remains a key challenge for C++ and something a successor language needs to address. Our initial priority and focus is on immediately addressing important, low-hanging fruit in the safety space:

  • Tracking uninitialized states better, increased enforcement of initialization, and systematically providing hardening against initialization bugs when desired.
  • Designing fundamental APIs and idioms to support dynamic bounds checks in debug and hardened builds.
  • Having a default debug build mode that is both cheaper and more comprehensive than existing C++ build modes even when combined with Address Sanitizer.

Time will tell if the language develops into a developer favorite or fades into obscurity like Dlang. What, you haven’t heard of D?


It helps me if you share this post with anyone who might be interested.
Quick Links to My Stuff

Published 2022-08-03 00:19:33

Google’s Privacy Policies Policy

Google unpublished a couple of my apps the other day for having out of date privacy policies. Fair, those URLs went dead. However, upon updating the URLs, one app was still not accepted.

Wall Ball. That’s because it doesn’t collect data on you. And what I mean by that is that when my privacy policy looked like this, Google rejected the app.

But, it’s true. Wall Ball doesn’t actually contain any ads or collect any data about anyone or anything. It simply runs as a small free game.

Removed notices from Play Console…

However, I’ve updated the privacy policy URL to:

https://gmr.dev/privacy/wallball2.html

Which basically just says I have ads in the game even though I don’t…

Whereas the link on the main privacy policy page goes to the “real” one:

https://gmr.dev/privacy/wallball.html

So we’ll see if Google accepts it this time. ๐Ÿ˜Š

But hey, maybe it’s just their idea of an April Fools joke. ๐Ÿ˜›

*EDIT* GUESS WHOSE APP IS BACK ON THE STORE! ๐Ÿ˜€


It helps me if you share this post with anyone who might be interested.
Quick Links to My Stuff

Published 2021-04-01 13:59:10

Be careful with app signing keys

Recently, I received an email from Google Play services. “Your app has been removed from the Google Play Store for a policy violation”, or something like that. How odd, I thought. I don’t remember doing anything against their terms of service. The email revealed that I didn’t have a valid privacy policy inside the app or on the store listing.

Oh. Right. The whole GDPR thing. It was time to write some privacy policies. After doing so, I began the process of digging up old files to old apps to make the necessary changes to the code. After about 2 hours of reinstalling Android Studio (my hard drive was wiped as some readers may remember), I began the process of exporting the app from Unity to an .APK.

Eventually, I was able to upload the finished .APK to Google’s servers. However, the Play Console threw an error at me; “The signatures do not match”. Wait, what? It’d been too long since I’d actually done this process. I googled the error to remind myself and broke out into a cold sweat.

Apparently, you generate a .keystore file upon first creating an Android app to sign the application with. It prevents people from uploading versions that aren’t originally from you, in the event that a developer’s account got hacked or something. There was no way to recover said .keystore file if you didn’t have it anymore, meaning there was no way to update my app. Ever. A full, in-depth system scan revealed no .keystore files. Luckily, with the two brain cells that were still functioning, I managed to remember that the other day I had deleted the app-which-I-was-updating’s Android version off my hard drive, because there was no real difference between the iOS and Android version, and I thought it was redundant. Perhaps it was in there?

I checked my Recycle Bin and breathed a sigh of relief. I hadn’t emptied it. It was still there. Opening the folder, the first thing I saw was a “user.keystore” file at the very bottom of the file list. A quick test confirmed that was the one. Phew.

Apparently those things are important. Don’t lose ’em, kids.


HEY, LISTEN! It’d be really cool if you checked out the app here on the play store, since it just got updated. ๐Ÿ˜‰


It helps me if you share this post with anyone who might be interested.
Quick Links to My Stuff

Published 2018-09-19 15:02:16