codys

OpenBSD does start X. And subsequently OpenBSD apparently hangs (or did so previously) when OpenBSD was running under Qemu.

The subject in the parent comment changed to OpenBSD when they mentioned it, and it appears you may have overlooked the subject change.

Possibly a better comparison (though a bit dated now) would be AT&T (or whatever telephone monopoly one had/has in their locality) charging an additional fee to use a telephone that isn't sold/rented to them by AT&T.

> I am assuming the message durability guarantees lean towards YOLO rather than ACID?

"Core" nats doesn't have durability. Nats jetstream is the api built on top of nats that in the main nats-server impl provides durability. Jepsen tested Nats Jetstream.

Also from your link:

> Regular NATS streams offer only best-effort delivery, but a subsystem, called JetStream, guarantees messages are delivered at least once.

The project linked here does not implement the nats jetstream api, just normal nats.

So yes, it seems its same (documented, understood) "yolo" as normal nats.

It seems it's just a part of a doc on style in tigerbeatle, in a similar way to the various "Google Style Guide" for code. These rarely have something new, but document what a particular project or organization does with respect to code style.

You've linked to a bug that was unintentional and was fixed.

Go allowing torn writes for their slices and interfaces (their fat pointer types) is intentional behavior in the go implementation and has no sign of being fixed.

Some one getting unsafe code unintentionally wrong is not an indication that any language lacks memory safety.

Here's an example where a bug could exist in go due torn writes in a real program.

I found this by searching for places where folks reload there config at runtime, as they are generally a place where people forget to synchronize correctly in go.

1. A viper.OnConfigChange callback is set up to call readConfig(): https://github.com/OdyseeTeam/chainquery/blob/48c092515dea5c...

2. Inside readConfig(), we assign to a slice `twillio.RecipientList` (https://github.com/OdyseeTeam/chainquery/blob/48c092515dea5c...

3. Note that in Go, slices are objects composed of 3 words (https://go.dev/blog/slices-intro#slice-internals) And there isn't syncronization built-in over updating them. As a result, if something reads the slice while it's being updated we will mix together a data pointer & length & capacity that correspond to different real slice objects. If the length we read is from a slice that has real length 10, but the data pointer we read is from a slice with real length 1, when iterating we'll read memory out of bounds.

4. in the context of this particular program, we may send SMSs to recipients who were never in the configured list if a config change occurs at the right time. Or a segfault. Entirely unclear if reading the memory will result in reasonable behavior.

Note: I'm not familiar with this repo otherwise. This is from a quick search.

In that case, I can just refer back to my original comment: https://news.ycombinator.com/item?id=46388948

And then note that memorysafety.org says this (in case folks haven't read it):

> Memory safety is a property of some programming languages that prevents programmers from introducing certain types of bugs related to how memory is used.

They then provide an examine of out-of-bounds read/write. Which is the exact example I noted in my linked comment.

(Note: memorysafety.org does not provide a concrete definition of memory safety, but we get enough from what it says in this case)

The site does not require the known existence of an exploit in popular software (and does not require that _any_ exploit be possible, a bug is sufficient), merely that the language fails to block "certain types of bugs".

"at the moment" implies that Go would need to change for that statement to change, but instead we're waiting on a programer to make a mistake (A mistake that memory safe languages prevent).

Which does get us to why defining the properties of a language based on what people have written in that language _so far_ is weird. It's not really a property of the language that no one has screwed up yet. It's perhaps an indication that it might be less likely that folks will screw up, which is where the "probabilistic" comes in. It assumes that given the lack of a counter example (a screw up) so far, and given the time that Go has existed, it _appears_ that it's low-likelyhood to screw up go programs in that particular way.

Agreed that the word is non-targeted in one way, but it's better than the alternate (implying go would have to change to become memory unsafe), if one wants to talk about how-memory-safe-is-go.

Interesting interpretation of that phrase. I think saying "probabilistically memory safe" would be more accurate (and more clearly communicate that idea), because we're betting on when a known case of memory unsafety in the language will show up in some piece of software.

It sounds like you have a definition of memory safety you aren't disclosing.

Please fully provide your definition of memory safety. Not interested in trying to figure out what it is in a 20-questions-over-hn way.

One can evaluate Go using the extent of the definition from the site itself, which uses out of bounds reads and writes as a sign of memory unsafety.

Go's implementation allows torn writes for interfaces (which are 2 words in size). These torn writes allow arbitrary memory reads/writes (a superset of out of bounds reads/writes)

Go can have memory unsafety leading to arbitrary memory reads and writes by having an interface replaced by another thread (go interfaces use 2 words, one for the vtable and another for the data. It does not replace these in a thread safe way, so one can use a vtable to work with an unexpected data pointer.

Folks have shown this allows the kinds of arbitrary memory reads/writes that folks normally ban in their definition of memory safe (and this post's website has a definition does as well):

https://research.swtch.com/gorace

https://blog.stalkr.net/2015/04/golang-data-races-to-break-m...

https://www.ralfj.de/blog/2025/07/24/memory-safety.html

This site is curious in that in incorrectly categorizes go as memory safe.

Perhaps in part because the sponsors are invested in using go and benefit from its inclusion in a list of memory safe languages.

The chart does not describe speed (either in general or in any particular case). Speed/performance/latency is a thing users care about that is not included in the feature list.

Ya, UUID v7 has been standard for a few years now. Perhaps the author is not familiar with the terminology of RFCs and so is misinterpreting the terminology used by IETF: "Request for Comments" and "Proposed Standard" can sound like they're not complete to folks not familiar with the IETF's process. Even then though, I would think they'd notice all the software that has UUID v7 support.

Allocators in rust are objects that implement the allocator trait. One (generally) passes the allocator object to functions that use the allocator. For example, `Vec` has `Vec::new_in(alloc: A) where A: Allocator`.

And so if in your example every request can have the same Allocator type, and then have distinct instances of that type . For example, you could say "I want an Arena" and pick the Arena type that impls Allocator, and then create a new instance of Arena for each `Vec::new_in(alloc)` call.

Alternately, if you want every request to have a distinct Allocator type as well as instance, one can use `Box<dyn Allocator>` as the allocators type (or use any other dispatch pattern), and provide whatever instance of the allocator is appropriate.

One would still use `?` in rust regardless of adding context, so it would be strange for someone with rust experience to mention it.

As for the example you gave:

    File::create("foo.txt")?;

If one added context, it would be

    File::create("foo.txt").context("failed to create file")?;

This is using eyre or anyhow (common choices for adding free-form context).

If rolling your own error type, then

    File::create("foo.txt").map_err(|e| format!("failed to create file: {e}"))?;

would match the Go code behavior. This would not be preferred though, as using eyre or anyhow or other error context libraries build convenient error context backtraces without needing to format things oneself. Here's what the example I gave above prints if the file is a directory:

    Error: 
       0: failed to create file
       1: Is a directory (os error 21)

    Location:
       src/main.rs:7

Rust has an RFC about some of the conventions for the Fd conversions. https://rust-lang.github.io/rfcs/3128-io-safety.html

It's unfortunate they did not extend marking the OwnedFd conversions as unsafe due to the focus in the RFC on a single class of unsafety in Fds instead of having a recognition that there are other issues with arbitrary Fd conversions.

I can't speak to http/3 (I haven't tried to impl it), but I can say that a bare-bones http/2 is very easy to implement because it doesn't try to pretend to be prose.

Ya, something like "table stakes" would be closer to what they mean.

The article in CACM that presents Knuth's solution [1] also includes some criticism of Knuth's approach, and provides an alternate that uses a shell pipeline:

    tr -cs A-Za-z $'\n' |
    tr A-Z a-z |
    sort |
    uniq -c |
    sort -rn |
    sed ${1}q

(I converted a newline to `$'\n'` for readability, but the original pipeline from the article works fine on a current MacOS system)

1: https://dl.acm.org/doi/pdf/10.1145/5948.315654

There's also an article on another game by the same folks that's similar (but earlier) which describes some details on building it

https://www.awwwards.com/summer-afternoon.html

It seems surprising to me that this kind of basic thing (does the update work on the hardware we've released) wasn't validated by Apple prior to releasing this software update. Perhaps a sign of issues in the QA process at Apple around MacOS?

It is strange how folks are refusing to admit they can even _evaluate things_ in a bunch of cases. We're seeing that here, but I've also noticed it in other posts on HN: a disagreement with the position of the article is framed not as a distinct examination which comes to different conclusions, but instead commenters claim the post author was foolish in even attempting to evaluate the thing the post is about.

To some degree it feels like bits and pieces of anti-intellectualism getting into folks brains: rejecting the idea that folks can think about things at all.

Nothing prevents using O_DIRECT as an open-flag for a fd used in other io_uring operations.

But I'm not sure I'd necessarily think of O_DIRECT as a way of improving "confidence in a write". It's a way to get a specific behavior.

Unless the lack of real time (or consistent time to) results drives down interest in the cloud version, or instead of driving down interest makes it appear as if people want something different than what they would want if the time to results was consistent/faster.

Still could be worth doing a bit of manual work like this, but it's worth being cautious about drawing conclusions from it.

Btech markets devices that are GMRS type accepted, it's actually one of their main businesses these days to take Chinese developed radios and modify them slightly and get them GMRS approved in the US.

FFMpeg does have an API. It ships a few libraries (libavcodec, libavformat, and others) which expose a C api that is used in the ffmpeg command line tool.

They publish doxygen generated documentation for the APIs, available here: https://ffmpeg.org/doxygen/trunk/

When you say "modern GC", which particular implementation(s) of GC are you referring to?

That's a very good point on the timing. Thanks for adding that extra info.