Helix: A Modern, High-Performance Language

"Comprehensive Error Handling: Helix's error handling system is novel to helix, it allows for either complete error handling or a more pythonic approach to error handling, this allows for more control over how errors are handled in Helix."

Wow, these really do seem to be LLM written, and I would guess ChatGPT. This long README has a bunch of generic, redundant statements over and over again.

Wait, was this language guided by AI???

Their first milestone is due later this year: to show the 2-way C++ interop.

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.

As I looked up Carbon over the past week, every comment on it was always that nobody uses it because it's going to be eventually https://killedbygoogle.com/

The point about Rust is to avoid any extra runtime cost by statically enforcing a set of rules (borrow checking) on reference use that are sufficient to guarantee memory safety. It also has ARC but it's reserved only for cases where those rules are too restrictive.

I'm a big fan of Rust and I also use Swift as part of my job. In terms of memory safety, Rust has a better story in that it will tell you of type problems pretty much upfront. The whole "Rust compile time takes forever" is only half true, because type checking happens pretty quickly. You're never left waiting for long to find out your types are wrong. The long compile happens at codegen phase, after type checking, so once it starts you know it'll finish successfully (unless there's a link error at the very end).

With Swift, that's not true. Sometimes you can wait for a while for the compiler to churn before it bails and tells you it can't fully infer types. As a Rust user, this is entirely unacceptable.

I would have to say, while I don't thoroughly dislike Swift, I do thoroughly dislike Xcode and the Apple ecosystem. The fact that Swift was tied so closely to iOS development for so long means it's not a language that people generally reach for. It feels more like ObjectiveC++ and a facet of the Apple ecosystem as a vehicle into iOS development.

People say that Rust's killer feature is the memory safety, but for me it's always been the ergonomics. Cargo and the painless dependency process is the real killer feature. Swift just doesn't have the same appeal, and that they are slowly getting there is a testament to Rust having already cracked the code; Swift only went fully cross platform (Windows+Linux+Mac) in 2020, so there's a lot of reputation as an Apple language to undo, as well as a lot of ground to catch up on. It's interesting to note that the ground they have to make up is pretty much the path that Rust blazed. So for a lot of the target audience of Swift, the question isn't "why Swift?", it's "why not Rust?". Really, they only good answer for Swift right now is "my target platform Apple."

Sure, but practically, that type is used so commonly that such a distinction is useless. Can I get a FILE? I guess I can get a FILE*…

I think I saw them sharing it on Reddit earlier