5 ms·

It seems unwise, to me, to tie the life of a project as fundamental, and conceptually simple, as git to a compiler and runtime as complicated as rust. The beau

It seems unwise, to me, to tie the life of a project as fundamental, and conceptually simple, as git to a compiler and runtime as complicated as rust. The beauty of the unsafety of C is partially that it's pretty easy to spin up a compiler on a new platform. The same cannot be said of Rust.

loeg 1y ago
Do you think any new, Git-relevant platform is going to gain C compiler support via anything other than Clang/LLVM?
- bArray 1y ago
  In theory you should be able to use TCC to build git currently [1] [2]. If you have a lightweight system or you're building something experimental, it's a lot easier to get TCC up and running over GCC. I note that it supports arm, arm64, i386, riscv64 and x86_64. [1] https://bellard.org/tcc/ https://bellard.org/tcc/ [2] https://github.com/TinyCC/tinycc https://github.com/TinyCC/tinycc
  - loeg 1y ago
    > I note that it supports arm, arm64, i386, riscv64 and x86_64. But like, so does LLVM.
- delusional 1y ago
  The nature considering the future is that our actions _now_ affect the answer _then_. If we tie our foundational tools to LLVM, then it's very unlikely a new platform can exists without support for it. If we don't tie ourselves to it, then it's more likely we can exist without it. It's not a matter of if LLVM will be supported. We ensure that by making it impossible not to be the case. It's a self fulfilling prophecy. I prefer to ask another question: "Is this useful". Would it be useful, if we were to spin up a different platform in the future, to be able to do so without LLVM. I think the answer to that is a resounding yes. That doesn't leave rust stranded. A _useful_ path for rust to pursue would be to defined a minimal subset of the compiler that you'd need to implement to compile all valid programs. The type checker, borrow checker, unused variable tracker, and all other safety features should be optional extensions to a core of a minimal portable compiler. This way, the rust compiler could feasibly be as simple as the simplest C compiler while still supporting all the complicated validation on platforms with deep support.
  - duckerude 1y ago
    rustc is only loosely tied to LLVM. Other code generation backends exist in various states of production-readiness. There are also two other compilers, mrustc and GCC-rs. mrustc is a bootstrap Rust compiler that doesn't implement a borrow checker but can compile valid programs, so it's similar to to your proposed subset. Rust minus verification is still a very large and complex language though, just like C++ is large and complex. A core language that's as simple to implement as C would have to be very different and many people (I suspect most) would like it less than the Rust that exists.
- 1718627440 1y ago
  Code doesn't need to "gain C compiler support", that's the point of having a language standard.
  - loeg 1y ago
    Someone has to write the platform-specific backend. A language standard doesn't help you if nothing implements it for your new platform.
  - MarsIronPI 1y ago
    Which Rust still does not have. If serious projects like Git and Linux are adopting Rust, the Rust team might want to consider writing a spec.
    - yencabulator 1y ago
      https://blog.rust-lang.org/2025/03/26/adopting-the-fls/ https://blog.rust-lang.org/2025/03/26/adopting-the-fls/
      - MarsIronPI 1y ago
        A specification is not a standard. It's a good first start, but what makes a standard more valuable is that it requires more than one entity to approve a change to it. This does look like a step in the right direction though.
kstrauser 1y ago
One argument from the git devs is that it’s very hard to implement smarter algorithms in C, though. For example, it uses arrays in places where a higher level language would use a hash, because the C version of that is harder to write, maintain, and debug. It’s also much easier to write correct threaded code in Rust than C. Between those 2 alone, using a more robust language could make it straightforward to add performance gains that benefit everyone.
- delusional 1y ago
  That's a one time gain though. There's no reason for every platform to check the validity of some hash table implementation when that implementation is identical on all of them. In my opinion, the verification of the implementation should be separate from the task of translating that implementation to bytecode. This leaves you with a simple compiler that is easy to implement but still with a strong verifier that is harder to implement, but optional.
  - kstrauser 1y ago
    And who’s volunteering for that verification using the existing toolchain? I don’t think that’s been overlooked just because the git devs are too dumb or lazy or unmotivated.
    - delusional 1y ago
      > just because the git devs are too dumb or lazy or unmotivated. That's a very unkind assumption of my argument. I ask that you read https://news.ycombinator.com/item?id=45314707 https://news.ycombinator.com/item?id=45314707 to hopefully better understand my actual argument. It doesn't involve calling anybody stupid or lazy.
      - kstrauser 1y ago
        That came across more harshly than I meant, but I stand by the gist of it: this stuff is too hard to do in C or someone would’ve done it. It can be done, clearly, but there’s not the return on investment in this specific use case. But with better tooling, and more ergonomic languages, those are achievable goals by a larger pool of devs — if not today, because Rust isn’t as common as C yet, then soon.
fuhsnn 1y ago
As a practical example, the latest Git version can be compiled by an extremely simple (8K lines of C) C compiler[1] without modification and pass the entire test suite. Gonna miss the ability to make this claim. [1] https://github.com/fuhsnn/widcc https://github.com/fuhsnn/widcc

loeg 1y ago

Do you think any new, Git-relevant platform is going to gain C compiler support via anything other than Clang/LLVM?

bArray 1y ago
In theory you should be able to use TCC to build git currently [1] [2]. If you have a lightweight system or you're building something experimental, it's a lot easier to get TCC up and running over GCC. I note that it supports arm, arm64, i386, riscv64 and x86_64. [1] https://bellard.org/tcc/ https://bellard.org/tcc/ [2] https://github.com/TinyCC/tinycc https://github.com/TinyCC/tinycc
- loeg 1y ago
  > I note that it supports arm, arm64, i386, riscv64 and x86_64. But like, so does LLVM.
delusional 1y ago
The nature considering the future is that our actions _now_ affect the answer _then_. If we tie our foundational tools to LLVM, then it's very unlikely a new platform can exists without support for it. If we don't tie ourselves to it, then it's more likely we can exist without it. It's not a matter of if LLVM will be supported. We ensure that by making it impossible not to be the case. It's a self fulfilling prophecy. I prefer to ask another question: "Is this useful". Would it be useful, if we were to spin up a different platform in the future, to be able to do so without LLVM. I think the answer to that is a resounding yes. That doesn't leave rust stranded. A _useful_ path for rust to pursue would be to defined a minimal subset of the compiler that you'd need to implement to compile all valid programs. The type checker, borrow checker, unused variable tracker, and all other safety features should be optional extensions to a core of a minimal portable compiler. This way, the rust compiler could feasibly be as simple as the simplest C compiler while still supporting all the complicated validation on platforms with deep support.
- duckerude 1y ago
  rustc is only loosely tied to LLVM. Other code generation backends exist in various states of production-readiness. There are also two other compilers, mrustc and GCC-rs. mrustc is a bootstrap Rust compiler that doesn't implement a borrow checker but can compile valid programs, so it's similar to to your proposed subset. Rust minus verification is still a very large and complex language though, just like C++ is large and complex. A core language that's as simple to implement as C would have to be very different and many people (I suspect most) would like it less than the Rust that exists.
1718627440 1y ago
Code doesn't need to "gain C compiler support", that's the point of having a language standard.
- loeg 1y ago
  Someone has to write the platform-specific backend. A language standard doesn't help you if nothing implements it for your new platform.
- MarsIronPI 1y ago
  Which Rust still does not have. If serious projects like Git and Linux are adopting Rust, the Rust team might want to consider writing a spec.
  - yencabulator 1y ago
    https://blog.rust-lang.org/2025/03/26/adopting-the-fls/ https://blog.rust-lang.org/2025/03/26/adopting-the-fls/
    - MarsIronPI 1y ago
      A specification is not a standard. It's a good first start, but what makes a standard more valuable is that it requires more than one entity to approve a change to it. This does look like a step in the right direction though.

kstrauser 1y ago

One argument from the git devs is that it’s very hard to implement smarter algorithms in C, though. For example, it uses arrays in places where a higher level language would use a hash, because the C version of that is harder to write, maintain, and debug. It’s also much easier to write correct threaded code in Rust than C. Between those 2 alone, using a more robust language could make it straightforward to add performance gains that benefit everyone.

delusional 1y ago
That's a one time gain though. There's no reason for every platform to check the validity of some hash table implementation when that implementation is identical on all of them. In my opinion, the verification of the implementation should be separate from the task of translating that implementation to bytecode. This leaves you with a simple compiler that is easy to implement but still with a strong verifier that is harder to implement, but optional.
- kstrauser 1y ago
  And who’s volunteering for that verification using the existing toolchain? I don’t think that’s been overlooked just because the git devs are too dumb or lazy or unmotivated.
  - delusional 1y ago
    > just because the git devs are too dumb or lazy or unmotivated. That's a very unkind assumption of my argument. I ask that you read https://news.ycombinator.com/item?id=45314707 https://news.ycombinator.com/item?id=45314707 to hopefully better understand my actual argument. It doesn't involve calling anybody stupid or lazy.
    - kstrauser 1y ago
      That came across more harshly than I meant, but I stand by the gist of it: this stuff is too hard to do in C or someone would’ve done it. It can be done, clearly, but there’s not the return on investment in this specific use case. But with better tooling, and more ergonomic languages, those are achievable goals by a larger pool of devs — if not today, because Rust isn’t as common as C yet, then soon.

fuhsnn 1y ago

As a practical example, the latest Git version can be compiled by an extremely simple (8K lines of C) C compiler[1] without modification and pass the entire test suite. Gonna miss the ability to make this claim. [1] https://github.com/fuhsnn/widcc https://github.com/fuhsnn/widcc