nikeee
String body = ... REST response body, which is a JSON document ... ;
JsonValue json = Json.parse(body);
json.get("properties").get("periods").asList().stream()
.mapToInt(j -> j.get("temperature").asInt())
.average()
.ifPresent(IO::println);
Why am I able to call `.get(string)` or `.get(int)` on a JsonValue? Shouldn't these be on the JsonObject and JsonArray instead?> If the JsonValue instance is of the wrong type, or if the requested member or element does not exist, the access methods throw a JsonValueException.
So if I get an exception, I can't tell whether the value was of the wrong type or the object didn't have the requested key? This looks like a footgun to me.
They just brought pattern matching to Java. Why not move those .get to JsonArray and JsonObject? That would solve this confusions. So we could just use something like `if (json instanceof JsonObject o) o.get("properties")`
Most ai generated messages or docs are unnecessarily verbose and just reading the prompt would suffice. I don't really get why some people seem to think that it's somehow better to have their bullet point prompt as a huge text.
It just wastes my time. And probably only makes it look like it took more effort than it actually did (it may be the exact opposite).
Rust on the other hand is pretty established by now and has less breaking changes. It also has more compile-time safety-guarantees that makes vibe-coding a bit more confident.
In top of that, Zig has rejected their upstream contributions. So they'd have to maintain their own compiler in the long run, which is probably just technical debt to maintain.
That test matrix uncovered that post policies were only checked for exsitence and a valid signature, not if the request actually conforms to the signed policy. That was an arbitrary object write resulting in CVE-2026-27607 [2].
In the very first issue for this bug [3], it seemed that the authors of the S3 implementation didn't know the difference between the content-length of GetObject and content-length-range of a PostObject. That was kind of a bummer and leads me to advise all my friends not to use rustfs, though I like what they are doing in principal (building a Minio alternative).
[1]: https://github.com/nikeee/lean-s3 [2]: https://github.com/rustfs/rustfs/security/advisories/GHSA-w5... [3]: https://github.com/rustfs/rustfs/issues/984
I tried using it for crypto, but WASM does not have instructions for crypto. So it basically falls back to be non-hw-accelerated. Tried to find out why and the explanation seems to be that it's not needed because JS has a `crypto` API which uses hw intrinsics.
Having trusted dependencies at least drastically reduces the risk that 'git clone && npm install' takes over the entire system.
Cooling down dependencies would certainly help, also.
Would probably be hard to guess since the process may not have opened any file once it started.
https://github.com/foriequal0/git-trim
Readme also explains why it's better than a bash-oneliner in some cases.
I find the never type in TS actually being a proper bottom type + having control-flow based types vastly superior to what rust offers.
[1]: https://github.com/kellerben/dudle [2]: https://github.com/fsinfuhh/BitPoll
Also in Germany, a train that did not even arrive does not count as too late.
There is also a concept of the "Pofalla-Wende", which is when a train is so late that it just does a 180 and drives back, to mitigate that the delay doesn't carry over to the train's next route. Of course, that means that it skips the stations at the end of the route.
The author doesn't ask for _no_ icons at all. So I really don't get this critique.
Intentionally omitting some icons is a really powerful tool to draw attention to the actions that the user wants to do most of the time. I think that pattern went away in some places because it looks more consistent (that doesn't mean that usability is better) and some designers have some kind of OCD. At least that's what I have experienced in that exact case.
#include <stddef.h>
void foo(size_t n, int b[static n]);
https://godbolt.org/z/c4o7hGaG1It is not limited to compile-time constants. Doesn't work in clang, sadly.
I'd take a look at garage (didn't try seaweed yet).
IANAL, of course
This is not only due to implementation complexity, but also to keep TS to be able to change. Or even to build an entire different JS superset. With that proposal, even flow could be natively executed.
At least it's like that since Windows 7. In windows XP, it actually used the localized names on disk.
Please don't use AI-generated commit messages blindly. Instead, use AI later when reading commit messages. It will have more context (following commits) to see what was actually happening. Having to guess whether a message was hallucinated by an AI won't help. If the message conflicts in its intention with what it isactually doing, you can spot the bug. You won't get that with AI messages.
Also, using AI commit messages will freeze it's capabilities in time, when creating the commit. When using AI at reading commit messages, you'll always get the latest options for analyzing the commits.
Just because it has more text doesn't make it a better message.
An f32-NaN has 22 bits that can have any value, originally intended to encode error information or other user data. Also, there are two kinds of NaNs: queit NaN (qNaN) and signalling NaNs (sNaN) which behave differently when used in calculations (sNaNs may throw exceptions).
Without looking at the bits, all you can see is NaN, so it makes sense to not equal them in general. Otherwise, some NaN === NaN and some NaN !== NaN, which would be even more confusing.