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 3 days ago | parent [-]

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.

▲ unionpivo 3 days ago | parent | next [-]

C is 50 years old or something like that, and it still doesn't have a standard hash map.

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.

	▲	1718627440 a day ago \| parent [-]
		> or they would *exist by now. See: https://news.ycombinator.com/item?id=45120171 Nobody needs to change a language standard for 9 lines of code. When you really want to use a hash map, its likely that you care about performance, so you don't want to use a generic implementation anyway. > or a at least a community consensus about which one you pick There is a hash table API in POSIX: `GNU libc: https://sourceware.org/glibc/manual/latest/html_node/Hash-Search-Function.html Linux hsearch(3): https://man7.org/linux/man-pages/man3/hsearch.3.html hsearch(3posix): https://www.man7.org/linux/man-pages/man3/hcreate.3p.html`

▲ kstrauser 3 days ago | parent | prev [-]

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 3 days ago | parent [-]

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

	▲	kstrauser 3 days ago \| parent [-]
		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.