ascar

yea that's an odd example to pick. expecting type conversion to add meaning to strings is a programmer problem not a language problem. really comes down to developers not thinking about types and their meaning anymore.

there are plenty of javascript examples that are actually weird though, especiall when javascript DOES apply meaning to strings, e.g. when attempting implicit integer parsing.

And a `git remote add name url` and you are setup to use another remote server.

Even if that's a concern in a doomsday scenario, self-hosting gitlab is super easy and a good (some would argue better) alternative.

It has an export function that you can scan from an old phone. And I kept the setup keys in my keepass database.

On top of that now Google backs those up for you too.

Seems like a rather easy thing to go wrong in the client, no?

User sends message via client. Client fumbles the recipient id. Message ends up at the wrong recipient.

Examples: incorrect recipient ID attached to contact in list where users selects recipient. Buggy selection of multiple targets in the selection UI due to incorrect touch event handling. Incorrect deletion of previously selected and then deselected recipient from recipient array of multitarget message. Or if working low level even a good old off by one error and reading out of bounds data for the recipient list (though that one hopefully should trigger a faulty send request due to other stuff no longer matching). There is endless examples.

The server can't really safeguard against the client providing a legitimate send request even though the user intended to send it to another recipient.

I'm not sure if I missed a bit here, but I have some colleagues doing research on unikernels for HPC and the point is that this unikernel is running directly on the hardware or hypervisor and not inside another VM. The unikernel is effectively a minimal VM and the network stack is one of the things they struggle the most with due to sheer effort.

JSON for something that essentially mirrors a shell installation process? Feels like you are trying to reinvent things with a golden hammer, not like actually making it easier.

If you read closely I am not talking about the limitations of GPT, but about the limitations of the developer having to fix code of others (GPT essentially being another developer). I guess it depends on the complexity of the problem. A lot of stuff is very easy to review and for me other stuff needs more time to understand than it did to write.

You're working under the assumption that you will be able to find the errors. I personally found reviewing code always way harder than writing it and we already push tons of bugs to production in written+reviewed code.

It's more like not using semi-autonomuous driving features with the car entirely relying on your expertise to realise and correct when it's making a mistake. The main difference is risk. Your own life at stake versus bugs in some production system.

Due to the nature of my current work I haven't really used GPT for coding yet, but I keep wondering isn't it easier to write code than to read and truly understand it? So how much development time was really saved, if I still care about off-by-one errors or correct identity checks in hash maps or all those edge cases I probably should care about? Those are all things much harder to spot reading than writing the code.

So I keep wondering if we just save time by introducing more unknown bugs using GPT?

I guess this also has a lot to do with what code is written. I would be much more concerned with a system level C++ library than some JavaScript CRUD.

Fair enough. I lost track of the correct comment chain there.

According to the RFC's PUT can be used to create a resource as long as the request has a clear target. That doesn't necessarily mean an ID, but just some kind of identifier (composite key, hash of content, url, etc.). When a create instead of update happens the server should respond with a 201 CREATED, which should indicate the location or identifier of the created resource.

Aren't you basically describing that you want idempotency?

The RFC 9110 (and also the old 2616) clearly state PUT is idempotent while POST isn't.

9.3.4 PUT

"The fundamental difference between the POST and PUT methods is highlighted by the different intent for the enclosed representation. The target resource in a POST request is intended to handle the enclosed representation according to the resource's own semantics, whereas the enclosed representation in a PUT request is defined as replacing the state of the target resource. Hence, the intent of PUT is idempotent and visible to intermediaries, even though the exact effect is only known by the origin server."

9.2.2 Idempotent Methods

"Idempotent methods are distinguished because the request can be repeated automatically if a communication failure occurs before the client is able to read the server's response. For example, if a client sends a PUT request and the underlying connection is closed before any response is received, then the client can establish a new connection and retry the idempotent request. It knows that repeating the request will have the same intended effect, even if the original request succeeded, though the response might differ."