And maybe we'll get web bluetooth too.

I was unable to load it initially (got an error from firefox) and had to re-attempt. Still slow if one forces a reload (shift-r, etc, to not use local cache).

It's a mechanism to try to make the 900Mhz band more useful to uncoordinated users.

Don't forget Ford deciding to protect his political allies (by pardoning Nixon). And George HW Bush doing similar (preventing Iran-Contra scandal investigation by pardoning participants who could have fingered Bush or Reagan)

    WITH
     o AS (
      SELECT FROM orders
      WHERE orders.id = $1
     ),
     os AS (
      SELECT FROM orderStatuses
      WHERE orderStatuses.orderId = $1
      ORDER BY DESC orderStatuses.createdAt
      LIMIT 1
     )
     INSERT INTO orderStatuses ...
     WHERE EXISTS (SELECT 1 FROM os WHERE os.code != $2)
     RETURNING ...something including the status differ check...

Languages that have garbage collection are not all memory safe.

Folks should be careful of people using the "messenger" title to attempt to obtain the appearance of impartiality.

I believe google, who maintain chrome and are on the CAB, are an entity well known for hosting various websites (iirc, it's their primary source of income), and those websites do use https

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

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

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.

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.

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

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.