Is anything known about the key developers? I would imagine such a project needs firepower. Rust had Mozilla's heft from the get-go. Most successful languages have another big sponsor.
Still, I don't really see this going anywhere. There are already so many "slightly better C++" languages out there, e.g. D, cppfront/cpp2, Carbon, Zig and they pretty much all don't see wider adoption for the same reason. No matter how simple or ergonomic the interop with C++ is, the switching cost is still high and the benefit tends to be marginal. Almost all of them either include garbage collection or don't fully guarantee memory safety. Choosing a restricted subset of C++ and an opinionated, enforced linter & static analyzer goes a long way and gets you most of the benefits of these new languages, so organizations tend to just do that.
The exception is Rust, because in spite of all its downsides it has the killer feature of guaranteed memory safety without garbage collection, so that's the one seeing constantly increasing institutional support.
Their second milestone should show memory safety features, and AFAIK it comes up a year or two later.
These milestones will produce technology demonstrators - so there's no expectations people would be using Carbon for anything beyond small demos and maybe check if it can be integrated with their existing C++ codebases.
Then they will try to package up the language and tooling around it with these two flagship features. This is where they expect some people to use the language for real. The language will only support a subset of C++ (they haven't decided what exactly it should include), and they mentioned Rust-like subdivision into "unsafe" and "safe" Carbon. To me this all looks like even after those milestones it may take a while.
Also, while Google folks are hopeful they also donated billions to Rust to improve C++ interoperability there, too. They don't bet on one language only but rather see multiple of them develop and spread.
So, tldr: it's years and years away.
I will take an actual look into it later though, seems interesting.
"Non-Nullable Types by Default: In Helix, all types are non-nullable by default, significantly reducing the risk of null-pointer errors. Helix uses a novel approach to nullable types - Questionable Types, which allows for more explicit handling of null or panicking values."
But then when you look at questionable types, it says:
"You can use a questionable type like a regular variable. If you use it in a context where a non-questionable type is required, Helix implicitly checks its validity: If the value is valid, it proceeds. If the value is null or an error, the program stops with a crash."
Is that not exactly the same behavior that Java has?
Also yeah seems like they reinvented null pointer crashes but with extra steps.
https://github.com/helixlang/helix-lang/commit/4d949efd42b8d...
So glad to hear this. I now consider this the single most important requirement when am evaluating a new programming language.
Error handling looks well thought out as well.
Very interested in how the borrow checker logic would shape up.
If this delivers on the promises made, it would pretty much be my dream programming language.
Does the conversion happen during run-time? Isn't that going to be super expensive?
To some of us that is a major feature of Rust and Zig, but good luck.
Just curious, what benefit OOP offers over other paradigms in AI dev?
johnisgood•1h ago
That is good to know.