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

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

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)

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

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.

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

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.

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

I’m probably going to be downvoted for this but this thread doesn’t really reflect well on the promises of Generative AI and particularly the constantly reiterated assurance that we’re on the verge of a new industrial Revolution.

Agreed. Many of the suggestions are pretty much code it yourself, but without actually tapping the individual keys.

Furthermore, and more generally, one of the great things about (traditional) coding is that it allows 'thinking through making' - by building something you learn more about the problem and thus how best to solve it. Code generation just leaves you with reviewing, which is less powerful in this way I believe. See also 'thinking through writing [prose]'.

I said it since the very first video of somebody who built a login page with it. They kept adding more and more constraints and at some point it's just coding but with extra steps.

It doesn't mean those tools do not have value though but they're not capable of "coding ", in the sense we mean in the industry, and generating code isn't coding.

I'm feeling the same way. It's quite the contrast from all the hype posts that make it sound like you give the AI a rough idea of what you're looking for and then it will build it from start to finish on its own.

Yes. I’m trying it, it’s too early for me to state a conclusion, but it’s not clear what the point is of an interface that requires magic touch best described as je ne sais quoi.

The alternative to this isn’t even necessarily no AI, just not using it this way.

I don't think the OP gave enough information for us to really have any honest conversation about this one way or the other.

That said: I suspect that OP is providing low-detail prompts.

These tools cannot read your mind. If you provide an under-specified prompt, they will fill in all the details for things that are necessary to complete the task, but that you didn't provide. This is how you end up with slop.

This looks like a solution in search of a problem already solved by SQLite

I think the problems with sqlite:

- sqlite can't do concurrent writes, which is a performance bottleneck for certain workflows

- sqlite is synchronous, which isn't ideal in applications that are async

- while sqlite itself is open source, the test suite is proprietary, which means forking it and adding your own features or bug fixes isn't really practical. Of course, that is also a significant barrier to turso having sqlite compatibility.

Does turso really solve those problems? IDK. Does it introduce new problems? Almost certainly. But those are real problems that people have.

Proprietary? Are you referring to the test suite they created for avionics that last I checked they've never really sold? I think it's highly misleading to make that claim if so.

I thought most of the test cases were proprietary, but it looks like you are right and it actually is just the TH3 test suite, and the fuzzer.

I’m not entirely sure this is the silver lining you seem to think it is

I would be interested in hearing a plausible scenario of how a large scale voting machines hack could potentially happen

This looks super useful, but I was wondering if I'm the only one bothered by this recent trend of overloading completely unrelated operators (here the `/` operator) in the name of legibility.

I do agree overloading / is an odd choice in this instance, but it’s a shame “is” can’t be overloaded! Realistically wat(foo) would be fine though.

I had an adjacent idea a few weeks ago, but centered more around the idea that it may be difficult for new open-source contributors to find appropriate issues to work on. Suggesting and allowing to discover interesting issues across multiple repositories would allow the prospective user to get a nice view of what interesting issues are available to make a first / second / third contribution to a project, and possibly to also track contributions / pull requests etc.

Seems to have been layoffs at Mozilla today

This is such a great, simple, almost obvious idea. This type of ideas is getting more and more rare, so it is great to see one popping here and there.

Granted, this article is 15 years old but it is interesting to find that the landscape seems not to have changed much. I was wondering how much domain logic a modern application should put at the database layer.