What would a programming language designed from the ground-up for a multi-core world look like? | Lobsters
As I write this, I’m using just 6% of my 16-core CPU attempting to run Microsoft’s new Application Inspector on the Chromium source tree, which clocks in at 6 GB. This got me thinking about my previous experience with multi-threaded programming, and how difficult it was to write compared to single-threaded applications. If a language/compiler was designed from the ground-up for multi-core programming, what would it look like? In theory, could a compiler default to multi-threading where possible? I imagine since we as developers can look at something and see that it can be multi-threaded, shouldn’t a compiler be able to do the same? I imagine the compiler could detect parts of the code that can be distributed across multiple cores, and detect when you’re attempting to perform an operation that might result in data corruption. Just as current languages can determine if a variable is in scope, this theoretical language could detect when a given piece of data can be safely accessed across multiple cores. One language that I think gets pretty close is Go, but it’s still single-threaded by default, and requires quite a bit of effort to translate something from single-threaded to multi-threaded. While my question is more theoretical, I’d also be interested in hearing about languages that have really great multi-threading support, especially if the implementation details are hidden from the developer.