6 ms·

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#amt-advanced-memo

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#amt-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.

koakuma-chan 1y ago
What happened to Carbon? I completely forgot about it.
- 90s_dev 1y ago
  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/ https://killedbygoogle.com/
  - ioasuncvinvaer 1y ago
    It seems to be in active development though? And Google also made go which very much alive.
- andrewl-hn 1y ago
  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.
  - mlinksva 1y ago
    *million rather than billions https://rustfoundation.org/media/google-contributes-1m-to-rust-foundation-to-support-c-rust-interop-initiative/ https://rustfoundation.org/media/google-contributes-1m-to-ru... but sound analysis as far as I can tell.
rmorey 1y ago
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
- corank 1y ago
  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.
  - steveklabnik 1y ago
    The thing is, Swift has automatic reference counting, and Rust has an atomic reference counted type. Their “ARC”s are related but different.
    - corank 1y ago
      I was actually talking about automatic reference counting. I think both Rc and Arc count as automatic reference counting? It's just that the term (which was apparently coined by Apple?) is not commonly used outside Apple's languages. I'm not familiar with Swift though so my understanding could be incorrect.
      - steveklabnik 1y ago
        You're a little off. To put it in Rust terms, the "automatic" means that Swift will insert the equivalent of calls to ".clone()" for you, whereas this is manual in Rust.
        corank 1y ago
        I see. My understanding is that Rust doesn't have _automatic_ reference counting as in Swift only because it has an alternative (move), which requires the programmer to specify their intent. The principle is nevertheless the same: ensure every time a reference is copied the ref count is incremented, free only when ref count is zero, and we get temporal memory safety.

koakuma-chan 1y ago

What happened to Carbon? I completely forgot about it.

90s_dev 1y ago
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/ https://killedbygoogle.com/
- ioasuncvinvaer 1y ago
  It seems to be in active development though? And Google also made go which very much alive.
andrewl-hn 1y ago
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.
- mlinksva 1y ago
  *million rather than billions https://rustfoundation.org/media/google-contributes-1m-to-rust-foundation-to-support-c-rust-interop-initiative/ https://rustfoundation.org/media/google-contributes-1m-to-ru... but sound analysis as far as I can tell.

rmorey 1y ago

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

corank 1y ago
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.
- steveklabnik 1y ago
  The thing is, Swift has automatic reference counting, and Rust has an atomic reference counted type. Their “ARC”s are related but different.
  - corank 1y ago
    I was actually talking about automatic reference counting. I think both Rc and Arc count as automatic reference counting? It's just that the term (which was apparently coined by Apple?) is not commonly used outside Apple's languages. I'm not familiar with Swift though so my understanding could be incorrect.
    - steveklabnik 1y ago
      You're a little off. To put it in Rust terms, the "automatic" means that Swift will insert the equivalent of calls to ".clone()" for you, whereas this is manual in Rust.
      - corank 1y ago
        I see. My understanding is that Rust doesn't have _automatic_ reference counting as in Swift only because it has an alternative (move), which requires the programmer to specify their intent. The principle is nevertheless the same: ensure every time a reference is copied the ref count is incremented, free only when ref count is zero, and we get temporal memory safety.