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.

You get safety for the non-questionable types. But it seems like if you're going to have questionable types, you're better off not letting users silently treat them as if they aren't questionable and then risk crashing at runtime.

But also yes passing a null value into a non-questionable would lead to NPE however if the type has a questionable operator then that function would be used (like for strings, a questionable null string type is just a blank string, in which case using it with or without questionable doesn't make a difference).

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.

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."

After reading though everything we've seen posted on here and reddit there's a couple things that keep coming up consistently: AMT - devs want to know more about it Vial - devs want to know more about it Helix the name - everyone thinks it overlaps with the Helix Editor Readme - Looks to generic, Afterall it was put through ChatGPT to make it have good English after a draft... Docs - Outdated and Missing Helix the logo - its too similar to the Helix Editor Our Feature set - devs think its too good to be true. Linux Support - devs think not testing Linux is a dealbreaker.

Addressing the issues: Linux - Issue is we need word and Microsoft apps for college, hence the use of Windows and MacOS, but starting now We will set up WSL to test for Linux as well. AMT - We will add a section in our docs explaining it much more in detail! Vial - Also add a section in the docs explaining it much more in detail! Helix the name - We've kept the name for over a year now, and yes Helix editor has been around longer; We will consider another name, but for the time being we will add a disclaimer. Helix the logo - We will redesign the logo to be truly unique, might take a few weeks but we will change it. Readme - We will rewrite the readme from scratch, would use AI after an initial draft but make the content not seem like trying to market the language instead show the raw technical aspects without buzz words and stuff like that. Docs - Started to rewrite the docs from scratch same thing as the Readme, will post a commit without any AI modifications first. Our Feature set - while it does seem far fetched, we have written down all of our features in MD files (internally) that outline the exact processes that we need to follow, along with the thesis and theory of them, Everything is planed out fully, we just have to implement, while saying this is easier said then done, our goal is to try to make all of the features happen, maybe a year or two down the line it should be complete (or at least a working alpha).

Thank you so much! for all the compliments and criticism, These comments do mean a, lot to us and our team we are all college students, trying really hard to get this working, our coding ability should allow us to make Helix a reality, we are trying to get better at the other aspects, such as marketing, communicating with other devs, listening to feedback, and continuously improving...

I actually like the Haskell syntax more because it's looks nicer when formatted in multiple lines:

  -- Haskell:
  -- single line
  if ... then ... else ...

  -- multiline
  if ...
      then ...
      else ...

  // Rust:
  let result = if ... {
      ...
  } else {
      ...
  };

  // or, 4 lines but less common:
  let result = match ... {
      true => ...,
      false => ...,
  };

  # Python:
  # you have to read "from the middle out" to read with the order of execution
  x = a() if b() else c()

I might also consider asking Chris Lattner (Mojo language). They did use that syntax in Mojo, because it is made to be a superset of Python. But I remember hearing him say he really disliked it.

On a more basic level, I just don't see any good reason to put the condition in the middle.

Lisp: `(if <cond> <then> <else>)` Haskell: `if <cond> then <then> else <else>` Rust: `if <cond> { <then> } else { <else> }`

All the above read fine and normal. In the python version the order of execution is different then the left-to-right reading order.

It's not like it's a fatal flaw for a language to do it like Python. But it is just silly IMO. My POV is that I actually really like if-expressions, but hate the condition-in-the-middle syntax, so I tend to avoid it unless it's really short. When code changes slightly and becomes longer I'd rather not have to always double take if this now should change to an if-statment or to an expression etc.