Hacker News Reader

Comment by heyts | Hacker News Reader

I'd be really interested in the opposite, just for the sake of experimentation since that's what these projects mostly are. They all seem to be rewrites for the sake of "performance", because the cost is now lower bc of AI. I'd be interested to see something like a port of Quake III in Python or Kubernetes in Perl, even Rails in Python would be goofy and really fun to see

View on HN

> Quake III in Python

Probably doable - I remember most of Natural Selection 2 was Lua and it's more than a decade old at this point.

For Natural Selection 2, it was mainly the gameplay logic that was Lua, all running on their bespoke C++ game engine called Spark. But yeah, modern Python and Lua can be pushed to high performance.

Link: https://unknownworlds.com/en/news/spark-engine-questions-and...

Ah my mistake - I know they ditched Source to pursue their own engine and thought they were going all in on Lua, but doing the whole engine in Lua would have been a struggle I think.

> They all seem to be rewrites for the sake of "performance".

And yet this performs dramatically worse.

A slower, untested, incomplete git implementation, all for the low low price of $10-$15,000.

And don’t forget it wasted a bunch of human time in the process.

So if someone mentioned somewhere else there is already a Rust port a group is doing somewhere. How much could they have accomplished with this much money and time in software development resources?

Ok. AI can seemingly port stuff if you don’t test it thoroughly. I think that’s already been proven. At this point I’m seeing less and less value from these kind of things. I’m sure it was fun for the author, but how does it help other people?

But... it's memory safe. Not that git has any important memory issue, but now people with skill issues in C can contribute to it without breaking stuff.

They can still break stuff memory safely.

It's not for performance, it's for Rust.

If the first stereotype of Rust programmers is announcing that a project is in Rust before any other desirable software property (e.g. stable, performant, etc), the second stereotype is that Rust programmers love rewriting stuff in Rust, just for the sake of Rust.

(The 2.a. corollary is that they love rewriting GPL projects specifically and downgrading them to MIT/Apache)

It's not for Rust, it's for Library.

Well, it's sort of for Rust. GitButler is written in Rust and Jujutsu is written in Rust and we're both depending on fork/exec'ing to an unknown Git binary with no linkable library and no control over the subprocess to do a range of networking stuff. Neither Gitoxide or libgit2 are capable of this either, as much as I love and support those projects.

This project is entirely about providing a feature complete (even if sloppy) library implementation of Git, which does not otherwise exist.

> It's not for Rust, it's for Library.

Prove it - put it under GPL, like the original sources you ingested were.

But there is already gitoxide, an established git reimplementation in git. It even provides a library

gitoxide was started in 2018, back when we were all writing code by hand, and has some reasonable adoption in the rust ecosystem. It's not feature complete, but if that was the issue then surely fixing that would be better than starting from scratch

> A slower, untested, incomplete git implementation, all for the low low price of $10-$15,000.

That $15k is indeed a very low low subsidized AI price. It will be $150k next year.

> They all seem to be rewrites for the sake of "performance", because the cost is now lower bc of AI.

If that was true they'd use the original license. They are not. The whole RiiR movement is very obviously switching away from a pro-user license (GPL).

Reply on news.ycombinator.com