"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?
the docs were clearly not written by a human, so proceeding from the expectation of global coherence, or that of adherence to principles that would be implied to a human being reading this in a certain context, is likely to end up being a waste of time
"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.
From my personal judgment: definitely using AI for the code & commits, probably for the documentation, no idea about the design. For instance, no human would write this commit message, with the preformatted-code-block:
I believe it’s slightly different in that I can declare a value (or parameter) of type T and know that it can’t be null/invalid.
Consider this Java method:
void frobnicate(bar Bar)
{
// is bar null? Who knows?
}
To get the same behavior in Helix, one would have to declare the parameter type as “Bar?”. If the parameter type is plain “Bar”, callers can still pass you a “Bar?”, but presumably you’d get an NPE at the call site and not somewhere further down the stack.
I’ve never heard of this language before today and don’t have an opinion on it, but I do find the Questionable Types interesting: sort of collapsing Option and Result into one very concise notation.
Oh hey you're the guy who made the crafting interpreters book, that was really helpful when I went through my wanting to make a langauge phase, thanks for making a great book.
Also yeah seems like they reinvented null pointer crashes but with extra steps.
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 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.
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/
fwiw (and I am not an expert) in my understanding, Swift also has guaranteed memory safety without a GC (using automatic reference counting). not sure how it compares to Rust in that aspect
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."
It's the shopping list of dreams. As fast as it gets. Borrow checker, but friendlier than "other languages' borrow checkers" (I wonder which other ones they mean). Readable. What's not to like. I look forward to v0.1
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.
Once I check if an Option/optional/Maybe is none, I can extract the value and just pass around the value, so other functions I call know that the value cannot be null.
This does not work well for FILE in C, for instance.
I know that there's no such thing as a unique name, but the fact that https://helix-editor.com/ is a living project, first released in May 2021, might mean that using "Helix" for this project, first released in November 2024, isn't the best choice of name. Or at least it might be worth a disclaimer in the readme!
I always say this, but my opinion when it comes to bootstrapping a compiler is that it's generally a waste of time unless your language is meant for writing compilers.
While dogfooding your language is a great to stress test it, you want to make sure you're testing the right stresses -- the ones your target users will encounter. A compiler may be that thing, but chances are it is not; most people do not write nor do they aspire to write compilers. So showing off that you've written a compiler in your language doesn't attract users, because they're still left with the question "Okay, well what does it do for me?"
Another reason is that there is an infinite amount of work that goes into writing a compiler. It's really endless, especially for a small team or solo dev. If you try bootstrapping, it means essentially maintaining two compilers until you can fully bootstrap, which may never come. One compiler is really enough work.
The final reason I will say is it takes forever, and puts a total brake on new features, which can really kills project momentum. Writing the first bits of a language can really fly. But when you sit down to bootstrap, it means you're not releasing new features, but redoing everything you've already done. This leads to unfortunate messages like "We’ve now started work on the self-hosted compiler, using the current rudimentary C++-based implementation as a bootstrap.", which followers take to mean "the project is currently in hiatus for the foreseeable future until this background work on the bootstrap compiler is done". This is a critical point in language projects where the bootstrap might never be completed.
When I look at a new language project I always check out the "contributors" section. Whenever I see an initial flurry of activity from one or a few devs, followed by a taper off into nothing, I know the project is in trouble. It seems like maybe this author has hit a wall, and I would be highly suspicious of the bootstrap endeavor causing it.
Sorry for the petty comment, but if you design your language syntax with `x if cond else y` with the condition in the middle like in the Python if-expression syntax, I cannot trust your judgment and we cannot be friends. (from one of the images of code)
I will take an actual look into it later though, seems interesting.
I don't understand how the docs say:
"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?
the docs were clearly not written by a human, so proceeding from the expectation of global coherence, or that of adherence to principles that would be implied to a human being reading this in a certain context, is likely to end up being a waste of time
"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???
From my personal judgment: definitely using AI for the code & commits, probably for the documentation, no idea about the design. For instance, no human would write this commit message, with the preformatted-code-block:
https://github.com/helixlang/helix-lang/commit/4d949efd42b8d...
I believe it’s slightly different in that I can declare a value (or parameter) of type T and know that it can’t be null/invalid.
Consider this Java method:
To get the same behavior in Helix, one would have to declare the parameter type as “Bar?”. If the parameter type is plain “Bar”, callers can still pass you a “Bar?”, but presumably you’d get an NPE at the call site and not somewhere further down the stack.I’ve never heard of this language before today and don’t have an opinion on it, but I do find the Questionable Types interesting: sort of collapsing Option and Result into one very concise notation.
It’s a NPE, but it passed through vibe coding.
Not obvious what is novel either. Languages like Haskell have had alternatives like the Maybe monad for a long time.
Oh hey you're the guy who made the crafting interpreters book, that was really helpful when I went through my wanting to make a langauge phase, thanks for making a great book.
Also yeah seems like they reinvented null pointer crashes but with extra steps.
This is cool, I think the most novel/unique aspect is the advanced memory tracking: https://github.com/helixlang/helix-lang?tab=readme-ov-file#a...
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.
What happened to Carbon? I completely forgot about it.
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.
*million rather than billions https://rustfoundation.org/media/google-contributes-1m-to-ru... but sound analysis as far as I can tell.
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/
It seems to be in active development though? And Google also made go which very much alive.
fwiw (and I am not an expert) in my understanding, Swift also has guaranteed memory safety without a GC (using automatic reference counting). not sure how it compares to Rust in that aspect
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."
It's the shopping list of dreams. As fast as it gets. Borrow checker, but friendlier than "other languages' borrow checkers" (I wonder which other ones they mean). Readable. What's not to like. I look forward to v0.1
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.
> Non-Nullable Types by Default
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.
C has non-nullable types too. Only one type can be null in C, and in that event it signifies an absence of a value of that type.
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*…
Right, so check if it's null. In practice, you do it just as often in C as you check for std::nullopt in C++ or std::option::ok in Rust etc.
Once I check if an Option/optional/Maybe is none, I can extract the value and just pass around the value, so other functions I call know that the value cannot be null.
This does not work well for FILE in C, for instance.
Really cool to see that LSPs are no longer an afterthought, but rather a core part of the compiler. (evidence: https://github.com/helixlang/helix-lang/blob/21ac6a24ba34ca2...)
Bold to announce without finishing the documentation.
They didn't announce it, I posted it here out of curiosity to see what other people think about it. I hope they're not very upset about that ':)
I think I saw them sharing it on Reddit earlier
Oh yeah, in fact that's where I saw it and what made me think to post it here. Oops.
> Linux is not yet tested, Most development is done on MacOS or Windows, if any issues arise with building on Linux, please open an issue.
That is good to know.
> Lack of OOP Support: Both Rust and Zig lack comprehensive OOP support
To some of us that is a major feature of Rust and Zig, but good luck.
I'd love to learn more about how AMT works. How would a doubly linked list work in this language for example?
Does the conversion happen during run-time? Isn't that going to be super expensive?
HOW MANY THINGS ARE WE GOING TO NAME "HELIX" ERMAIGERHD. STOP. STOP IT.
I know that there's no such thing as a unique name, but the fact that https://helix-editor.com/ is a living project, first released in May 2021, might mean that using "Helix" for this project, first released in November 2024, isn't the best choice of name. Or at least it might be worth a disclaimer in the readme!
I thought the team behind the Helix editor came up with a programming language. Even the logo is so similar. A disclaimer would be wise.
If one uses Helix editor to code in Helix lang does that make it Double Helix? Asking for a friend.
Best of both worlds of Rust and Zig? C/C++ ABI compatibility? No runtime? Borrow checking with less strictness? Seems too good to be true.
> Best of both worlds of Rust and Zig
Seems more like something between Swift and unsafe Rust.
> Both Rust and Zig lack comprehensive OOP support, which is essential for certain domains like AI or game development.
Just curious, what benefit OOP offers over other paradigms in AI dev?
I always say this, but my opinion when it comes to bootstrapping a compiler is that it's generally a waste of time unless your language is meant for writing compilers.
While dogfooding your language is a great to stress test it, you want to make sure you're testing the right stresses -- the ones your target users will encounter. A compiler may be that thing, but chances are it is not; most people do not write nor do they aspire to write compilers. So showing off that you've written a compiler in your language doesn't attract users, because they're still left with the question "Okay, well what does it do for me?"
Another reason is that there is an infinite amount of work that goes into writing a compiler. It's really endless, especially for a small team or solo dev. If you try bootstrapping, it means essentially maintaining two compilers until you can fully bootstrap, which may never come. One compiler is really enough work.
The final reason I will say is it takes forever, and puts a total brake on new features, which can really kills project momentum. Writing the first bits of a language can really fly. But when you sit down to bootstrap, it means you're not releasing new features, but redoing everything you've already done. This leads to unfortunate messages like "We’ve now started work on the self-hosted compiler, using the current rudimentary C++-based implementation as a bootstrap.", which followers take to mean "the project is currently in hiatus for the foreseeable future until this background work on the bootstrap compiler is done". This is a critical point in language projects where the bootstrap might never be completed.
When I look at a new language project I always check out the "contributors" section. Whenever I see an initial flurry of activity from one or a few devs, followed by a taper off into nothing, I know the project is in trouble. It seems like maybe this author has hit a wall, and I would be highly suspicious of the bootstrap endeavor causing it.
[dead]
Sorry for the petty comment, but if you design your language syntax with `x if cond else y` with the condition in the middle like in the Python if-expression syntax, I cannot trust your judgment and we cannot be friends. (from one of the images of code)
I will take an actual look into it later though, seems interesting.