in the react-server package used by React Server Components (RSC).

Definitely a high usefulness-to-complexity ratio. But IMO the core advantage of Make is that most people already know it and have it installed (except on Windows).

By the time you need something complex enough that Make can't handle it (e.g. if you get into recursive Make) then you're better off using something like Bazel or Buck2 which also solves a bunch of other builds system problems (missing dependencies, early cut-off, remote builds, etc.).

However this does sound very useful for wrangling lots of other broken build systems - I can totally see why Buildroot are looking at it.

I recently tried to create a basic Linux system from scratch (OpenSBI + Linux + Busybox + ...) which is basically what Buildroot does, and it's a right pain because there are dependencies between different build systems, some of them don't actually rebuild properly when dependencies change (cough OpenSBI)... This feels like it could cajole them into something that actually works.

Yeah just encode the files locally and rsync them to the server. You could even use a Makefile to do the conversation.

Yeah I agree. It's often easier to start from something that's wrong than a blank page.

Normally when I merge a PR I put the long PR message (if there is one) in the merge commit (again if there is one), rather than shitty Merge PR from patch1 that people seem to use.

You can actually change the behaviour on GitHub to be sane: https://blog.mergify.com/how-to-change-the-default-commit-message-on-github/amp/

If I'm not keeping the branch (usually PRs are not big enough to make preserving multiple commits useful) then I squash & merge which gives you the chance to edit the commit message and copy details from the PR message in.

Based on my experience of AI coding I think this will only work for simple/common tasks, like writing a Python script download a CSV file and convert it to JSON.

As soon as you get anywhere that isn't all over the internet it starts to bullshit.

But if you're working in a domain it's decent at, why not? I found in those cases fixing the AI's mistakes can be faster than writing it myself. Actually often I find it useful for helping me decide how I want to write code because the AI does something dumb, and I go "no I obviously don't want it like that"...

No, the alternative solutions definitely wouldn't work with existing Rust code. You need a new language.

Aside from the better solution with iterators that Flipper mentioned, you can also:

• Omit the type annotation for is_palindrome - it will be inferred as bool anyway
• break; after setting is_palindrome = false
• Use the (0..input.len()/2).all(|i| ...) iterator method instead.

It's cloud based though... Not ideal. I get why they had to do that (they didn't want to expose people to the Python infra shit show) but it's still kind of a shame.

Would be better if they added Typescript support IMO.

Very cool but I hope they give it proper GUI integration, not just a webview or VNC, which is how the alternatives work.

True but it'll have to be like 10% and I don't see that happening ever really. Unless Microsoft really screws up, which to be fair they are doing their best.

You can leave comments on a commit message. What do you mean exactly?