181–190 of 433 posts
Earlier quoted context omitted.
At this point maybe it's time to let them solve the problem they've created for themselves by insisting on a closed C compiler in 2025.
[flagged]
Earlier quoted context omitted.
As a user, you may not be aware that C makes it relatively easy to create https://en.m.wikipedia.org/wiki/Buffer_overflow which are a major source of security vulnerabilities. This is one of the best reasons to rewrite software in Rust or any other more safe by default language.
Everyone on hackernews is well aware that C makes it relatively easy to create buffer overflows, and what buffer overflows are. You're still not responding to GP question.
Earlier quoted context omitted.
Actually, the Rust toolchain makes cross-compiling way easier than any other fully-compiled language I've ever used. There are like 100 different platforms you can target by just setting the `--target` flag, and they all pretty much just work on any host platform. Sounds like the real issue is that some Git developers have ancient, rigid requirements for their own development machines.
Others have said Rust does not support NonStop. But, my point is you shouldn't even have to cross-compile Git to a platform like NonStop in order to develop NonStop apps. So the portability of Rust shouldn't even matter here. The app developer should be able to run their Git commands on a supported platform and cross-compile their own app to NonStop.
Earlier quoted context omitted.
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 h…
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.
That's a very unkind assumption of my argument.
I ask that you read https://news.ycombinator.com/item?id=45314707 to hopefully better understand my actual argument. It doesn't involve calling anybody stupid or lazy.
Earlier quoted context omitted.
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 perfo…
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 h…
Sure its not impossible for C to get that, but at the same time, they are trying to write git not fix C.
* My point is, that hash maps and data structures like that are clearly not the priority of C or they would **exist by now.
** by exist I mean either in C standard, or a at least a community consensus about which one you pick, unless you need something specific.
Earlier quoted context omitted.
"You have to backport security fixes for your own tiny platform because your build environment doesn't support our codebase or make your build environment support our codebase" seems like a 100% reasonable stance to me
> your build environment doesn't support our codebase If that is due to the build environment deviating from the standard, then I agree with you. However, when its due to the codebase deviating from the standard, then why blame the build environment developers for expecting codebases to adhere to standards. That's the whole point of standards.
According to git docs they seem to try to make a best effort to stick to POSIX but without any strong guarantees, which this change seems to be entirely in line with: https://github.com/git/git/blob/master/Documentation/CodingG...
Earlier quoted context omitted.
Do you think any new, Git-relevant platform is going to gain C compiler support via anything other than Clang/LLVM?
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…
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.
what's a 'test balloon'?
From wiki it's "information sent out to the media in order to observe the reaction of an audience. It is used by companies sending out press releases to judge customer reaction, and by politicians who deliberately leak information on a policy change."
Yup I have no doubt that there's a Rust 'evangelist' group somewhere aiming for inorganic growth of the language.
For these reasons I believe it is not a good idea. The kernel also sort of rejected Rust. The kernel is complex enough without adding a Haskell type system and a lisp-level macro system capable of obfuscating what code calls what code. serde code is so hard to spelunk for this reason. Contrast this with Go's Unmarshall, much easier to follow.