4 ms·

> but I think most C programmers won't be willing to take a 4× performance hit. At a 4x performance hit, you might as well use C# or Go. > Fil-C's target au

by Ygg2 1y ago

> but I think most C programmers won't be willing to take a 4× performance hit. At a 4x performance hit, you might as well use C# or Go. > Fil-C's target audience is users of C programs, not authors of C programs. Sure, but then they don't get it for free. There is a perf penalty from GC. Plus you need all the original sources, right? > we lose access to that intellectual heritage. Declining usage of C is going to make you lose intellectual heritage[1]. A language no one can read or write is a dead language, regardless if you can translate it to English or not. [1] And that is outside Rust's or Zig's influence. It's an old language from when people thought you can trust the programmer. Which may well be the case if only people using it were Bell Labs engineers. It's got UB up the wazoo, no safety, and no sane package manager.

mbrock 1y ago
> you might as well use C# or Go Except, uh, you can't use C# or Go to run a program written in C/C++. Oh, you mean we can solve all our problems by simply rewriting all legacy software? Right, I forgot!
- einsteinx2 1y ago
  > Oh, you mean we can solve all our problems by simply rewriting all legacy software? Isn’t that Rust’s raison d'être? (Just kidding…mostly)
  - Ygg2 1y ago
    Pretty sure that's a programmer's raison d'être. Not invented here (NIH) syndrom predates Rust.
    - einsteinx2 1y ago
      Fair point, though it does seem to be more common in the Rust community to the point that it’s become a bit of a meme. Related funny anecdote, I recently saw a Show HN post title that made sure to mention the thing was written in Rust, but forgot to mention what it actually did. Priorities lol. I’m sure it sounds like I’m a Rust hater or something, but I’m really not. I like a lot of the new Rust tools being created and use a few myself (ripgrep, fd, and bat immediately come to mind but I’m sure there are more I’m using). I just find the almost religious fervor of the Rust community amusing.
      - vacuity 1y ago
        Please don't assume the entire Rust community, or most of it, is intent on rewriting all legacy software. Frankly, I think the more familiar one is with Rust, the less one is inclined to blindly advocate for rewriting things in Rust, and the Rust language developers are among those most familiar.
- coderedart 1y ago
  You absolutely can just transpile any language into any language. You just need to be willing to give up on performance, and fil-c is more or less doing just that.
  - mbrock 1y ago
    Let me know when the full "C++ to Go" toolchain is up and running, I'd love to try it and compare!
- Ygg2 1y ago
  If you can convert Cobol to Java, you can convert C++ to a GC language as well. If you are so inclined.
kragen 1y ago
UB was added to C when it was 15 years old, and the current understanding of UB is from about 10 years after that. It isn't essential to C; an implementation that defines all the undefined behavior would still be compliant and capable of running nearly all existing C. > There is a perf penalty from GC. Not really, no. There's a perf penalty from bounds checking and runtime type checking. GC takes a little time but saves you time on free(), although it only becomes a real performance win when you remove the other, less efficient ways of tracking lifetimes, such as reference counting. > Plus you need all the original sources, right? Yes, but from my point of view, loss of sources is not a significant problem. I know it happened historically, especially last millennium, but really only for proprietary software running on a single platform such as MS-DOS. Unix software, free software, and software using source control systems have suffered almost no source code loss, except for particular old versions. > Declining usage of C is going to make you lose intellectual heritage I think there are more C programmers today than there have ever been, and I doubt that that number will ever fall to zero while there are still humans.
- zozbot234 1y ago
  Tracing GC involves either a big performance penalty or a big memory footprint penalty compared to the ownership-based memory management in a language like Rust. The pervasive use of reference counting that you find in languages like Swift is worse on throughput than typical GC, but can often avoid the memory overhead of GC due to deterministic destruction and typically gives you better worst-case latency, so there isn't a single winner between ARC and GC.
  - kragen 1y ago
    I think that Fil-C, unlike normal C allocators, could use a copying GC instead of a tracing GC, because it isn't exposing the machine pointers to user code. But I don't know if it does. Copying GCs often suffer from high memory overhead, but for example OCaml's GC is pretty frugal with memory, and RC by itself doesn't guarantee good worst-case latency—decrementing a reference to the root of an arbitrarily large tree can have arbitrarily bad latency in RC. You probably already know all of this, but someone else reading the thread may not. So I'm not sure there isn't a single winner between ARC and GC, but you could be right.

by Ygg2 1y ago

mbrock 1y ago

> you might as well use C# or Go Except, uh, you can't use C# or Go to run a program written in C/C++. Oh, you mean we can solve all our problems by simply rewriting all legacy software? Right, I forgot!

einsteinx2 1y ago
> Oh, you mean we can solve all our problems by simply rewriting all legacy software? Isn’t that Rust’s raison d'être? (Just kidding…mostly)
- Ygg2 1y ago
  Pretty sure that's a programmer's raison d'être. Not invented here (NIH) syndrom predates Rust.
  - einsteinx2 1y ago
    Fair point, though it does seem to be more common in the Rust community to the point that it’s become a bit of a meme. Related funny anecdote, I recently saw a Show HN post title that made sure to mention the thing was written in Rust, but forgot to mention what it actually did. Priorities lol. I’m sure it sounds like I’m a Rust hater or something, but I’m really not. I like a lot of the new Rust tools being created and use a few myself (ripgrep, fd, and bat immediately come to mind but I’m sure there are more I’m using). I just find the almost religious fervor of the Rust community amusing.
    - vacuity 1y ago
      Please don't assume the entire Rust community, or most of it, is intent on rewriting all legacy software. Frankly, I think the more familiar one is with Rust, the less one is inclined to blindly advocate for rewriting things in Rust, and the Rust language developers are among those most familiar.
coderedart 1y ago
You absolutely can just transpile any language into any language. You just need to be willing to give up on performance, and fil-c is more or less doing just that.
- mbrock 1y ago
  Let me know when the full "C++ to Go" toolchain is up and running, I'd love to try it and compare!
Ygg2 1y ago
If you can convert Cobol to Java, you can convert C++ to a GC language as well. If you are so inclined.

kragen 1y ago

UB was added to C when it was 15 years old, and the current understanding of UB is from about 10 years after that. It isn't essential to C; an implementation that defines all the undefined behavior would still be compliant and capable of running nearly all existing C. > There is a perf penalty from GC. Not really, no. There's a perf penalty from bounds checking and runtime type checking. GC takes a little time but saves you time on free(), although it only becomes a real performance win when you remove the other, less efficient ways of tracking lifetimes, such as reference counting. > Plus you need all the original sources, right? Yes, but from my point of view, loss of sources is not a significant problem. I know it happened historically, especially last millennium, but really only for proprietary software running on a single platform such as MS-DOS. Unix software, free software, and software using source control systems have suffered almost no source code loss, except for particular old versions. > Declining usage of C is going to make you lose intellectual heritage I think there are more C programmers today than there have ever been, and I doubt that that number will ever fall to zero while there are still humans.

zozbot234 1y ago
Tracing GC involves either a big performance penalty or a big memory footprint penalty compared to the ownership-based memory management in a language like Rust. The pervasive use of reference counting that you find in languages like Swift is worse on throughput than typical GC, but can often avoid the memory overhead of GC due to deterministic destruction and typically gives you better worst-case latency, so there isn't a single winner between ARC and GC.
- kragen 1y ago
  I think that Fil-C, unlike normal C allocators, could use a copying GC instead of a tracing GC, because it isn't exposing the machine pointers to user code. But I don't know if it does. Copying GCs often suffer from high memory overhead, but for example OCaml's GC is pretty frugal with memory, and RC by itself doesn't guarantee good worst-case latency—decrementing a reference to the root of an arbitrarily large tree can have arbitrarily bad latency in RC. You probably already know all of this, but someone else reading the thread may not. So I'm not sure there isn't a single winner between ARC and GC, but you could be right.