cakoose

it avoids ambiguity by using ordered choice (the first matching rule wins)

PEG parsing tool authors often say that ordered choice solves the problem of ambiguity, that's very misleading.

Yes, ordered choice is occasionally useful as a way to resolve grammatic overlap. But as a grammar author, it's more common for me to want to express unordered choice between two sub-grammars. A tool that supports unordered choice will then let you know when you have an unexpected ambiguity.

PEG-based tools force you to use ordered choice for everything. You may be surprised later to find out that your grammar was actually ambiguous, and the ambiguity was "resolved" somewhat arbitrarily by picking the first sub-grammar.

This makes working with Ohm/PEGs less painful in the initial phase of a project.

I do agree with this. But then what happens in the later phases? Do you switch to a tool that supports unordered choice to see if you have any ambiguities? And potentially have to change your grammar to fix them?

Now I'm curious -- is that here a way to do this that avoids downloading any more than strictly necessary?

The command above downloads the whole repo history. You could do a depth=1 to skip the history, but it still downloads the he latest version of the entire repo tree.

Why will TypeScript 7 make Node.js irrelevant?

In TypeScript 7, the compiler will be written in Go instead of TS. But the compiler will still produce JS code as its output and so Node.js is still relevant for running that JS code.

Or is there something else about TypeScript 7 that will make Node.js irrelevant?

When we started 8 years ago, SQL databases were “old fashioned.” NoSQL was the future. Hadoop, MongoDB, Cassandra, InfluxDB – these were the new, exciting NoSQL databases. PostgreSQL was old and boring.

In 2017? I thought the NoSQL hype had subsided by then and everyone was excited about distributed transactions -- Spanner, Cockroach, Fauna, Foundation, etc.

Yup, the example doesn't make sense for the reason you pointed out.

You could water down the example a bit to make it work:

1. Assume there's some other authentication mechanism for client-server communication, e.g. TLS.

2. The client sends the user ID unencrypted (within TLS) so the server can route, but encrypts the message contents so the server can't read it.

3. The final recipient can validate the message and the user ID.

This saves the client from having to send the user ID twice, once in the ciphertext and once in the clear.

But another more interesting use case is when you don't even send the associated data: https://news.ycombinator.com/item?id=43827342

Offload only makes sense if there are other advantages, e.g. speed, power.

Without those, wouldn't it be better to use the NPUs silicon budget on more CPU?

What happens if we gradually transition to memory-safe languages for new features, while leaving existing code mostly untouched except for bug fixes?

...

In the final year of our simulation, despite the growth in memory-unsafe code, the number of memory safety vulnerabilities drops significantly, a seemingly counterintuitive result [...]

Why would this be counterintuitive? If you're only touching the memory-unsafe code to fix bugs, it seems obviously that the number of memory-safety bugs will go down.

Am I missing something?

A few years ago I was considering Heroku for something new. But then I learned that Heroku Postgres's HA offering used async replication, meaning you could lose minutes of writes in the event that the primary instance failed. That was a dealbreaker.

That was very surprising to me. Most businesses that are willing to pay 2x for an HA database are probably NOT likely to be ok with that kind of data loss risk.

(AWS and GCP's HA database offerings use synchronous replication.)

But the article claims it applies to SQL databases as well.

Are these rules specific to a particular database? > No. These rules apply to almost any SQL or NoSQL database. The rules even apply to the so-called "schemaless" databases.

Cargo-cult thinking means only looking for, and only accepting, confirming evidence.

This article's definition of cargo-cult thinking seems incorrect. The definition I'm familiar with: when you lack a true understanding of some idea and end up just mimicking the superficial qualities. It's a great metaphor that comes up all the time in software engineering.

For example, seeing a successful system that uses microservices and thinking that switching your system to microservices will make it successful. If you don't understand exactly what the tradeoffs are and why those tradeoffs worked well for the successful system, you're not going to get the result you want.

Maybe the author confused "cargo-cult thinking" with just plain "cult-like thinking"?

I'm not the person you're responding to, but I interpreted their comment as, "doesn't the argument against having protobuf check for required fields also apply to all of protobuf's other checks?"

From the linked article the post: "The right answer is for applications to do validation as-needed in application-level code. If you want to detect when a client fails to set a particular field, give the field an invalid default value and then check for that value on the server. Low-level infrastructure that doesn’t care about message content should not validate it at all."

(I agree that "static typing" isn't exactly the right term here. But protobuf dynamic validation allows the programmer to then rely on static types, vs having to dynamically check those properties with hand-written code, so I can see why someone might use that term.)

One core Lua thing that I think is an ugly mistake: trying to represent maps (dictionaries) and arrays using a single logical data type.

Most languages use different data types but with some API overlap, e.g. maps and arrays are both "iterable". Lua goes too far, I think, and tries to make them the exact same, a data type they call "table".

One side-effect is that you have some operations that only really make sense for maps or lists, but since they work on all tables, they're defined awkwardly, e.g:

The length of a table t is defined to be any integer index n such that t[n] is not nil and t[n+1] is nil; moreover, if t[1] is nil, n can be zero. For a regular array, with non-nil values from 1 to a given n, its length is exactly that n, the index of its last value. If the array has "holes" (that is, nil values between other non-nil values), then #t can be any of the indices that directly precedes a nil value (that is, it may consider any such nil value as the end of the array).

It is also possible for a link-time optimizer to observe that a non-static global variable is never modified and optimize that away too.

But the Postgres mailing list is talking about 2000 global variables being a hurdle to multi-threading. I doubt they just didn't realize that most of them can be optimized into constants.

I think there might be a terminology mix-up here. In C, a global variable with the `static` keyword is is still mutable. So it typically can't be constant-folded/inlined.

The `static` modifier in that context just means that the symbol is not exported, so other ".c" files can't access it.

I think as a straightforward, easily correct transition from 2000 globals, a giant structure isn't an awful idea.

Agree.

It's not like the globals were organized before!

Using a struct with 2000 fields loses some encapsulation.

When a global is defined in a ".c" file (and not exported via a ".h" file), it can only be accessed in that one ".c" file, sort of like a "private" field in a class.

Switching to a single struct would mean that all globals can be accessed by all code.

There's probably a way to define things that allows you to regain some encapsulation, though. For example, some spin on the opaque type pattern: https://stackoverflow.com/a/29121847/163832

We migrated Netflix’s mobile apps to GraphQL with zero downtime

Is "zero downtime" relevant here?

For example, when migrating a database that is the source-of-truth for data, then yeah, downtime is something you have to contend with. But for a client-server API change, isn't it trivial? Companies do this all the time -- expose a new version of an API then gradually migrate clients over.

(It's definitely not a trivial task overall! For example, you need thorough testing to make sure you don't break existing functionality and the article does talk about that.)

Having it be evenly divisible by all those bases is neat!

But I wouldn't say "no wasted bits" unless 120 bits is also exactly the right length for a particular use case. For example, if my use case would be served better by 64 bits, I'd prefer losing some bits to padding than extending it to 120 bits.

Offering a bounty like this has value, but probably only for finding shallow bugs.

Thoroughly evaluating security/cryptography takes deep expertise and a lot of time. You're not going to elicit that without more money, impact/fame, or technical excellence.

- Money: The original bounty was $400. An expert can probably earn $400 an hour just to investigate something, without needing to completely break it.

- Impact/fame: Barely anyone uses this project. There are tons of other tools and services that are more widely used.

- Technical excellence: There's no evidence of anything clever or interesting.

For example, researchers around the world spend tons of effort analyzing the algorithms in the various NIST cryptography competitions. There's significant impact/fame and clear evidence of technical excellence. But if some rando offers a $10k bounty for their encryption algorithm, it's not going to get the required level of scrutiny.

Plus, the bounty is just for the encryption mechanism. With security, it's usually the other moving parts that cause issues, especially in how they interact with human behavior. Phishing works without needing to break TLS, DKIM/SPF, browser sandboxing, etc.

(I read an article ~5-10 years ago by a security/crypto researcher that said basically this, but sadly I can't find it anymore.)

I still think it's great when people build things like this and when they offer any kind of bounty. I just worry that the presence of an unclaimed bounty might mislead people into overestimating the level of security.

"git undo" tool: https://github.com/arxanas/git-branchless/wiki/Command:-git-...

It's therefor also fine if you're writing in a monospace/fixed-width font.

This is the standard explanation I see everywhere, but I don't get it.

With two spaces, the gap after a period is longer than a gap after a comma. Why is that "obviously fine" in fixed-width but not in variable-width?

There are analogies that make this seem bad (fake construction worker) and analogies that make this seem good (ethical security researcher).

We need to go past the analogy and make a deeper assessment of the factors that matter. For example, what does the bad actor stand to gain? How much harm can they cause? How often is this happening?

For example, if the fake construction worker scheme was used to rob people and it was happening regularly, it might be worth doing something about it.

And "doing something about it" doesn't necessarily mean throwing away trust. There are a bunch of other interventions when you look at the problem holistically, e.g. can we reduce the benefit, reduce the prevalence, reduce the net harm?

I see this more like a security researcher identifying a vulnerability in a system, executing a proof of concept, and then disclosing it.

This vulnerability is being exploited by worse actors. Exposing the vulnerability publicly may bring about change to make the system less vulnerable.

I wasn't saying langcc was not powerful, just that the shape of the argument doesn't make sense.

That part of the README goes something like this:

1. It can parse Python and Go efficiently.

2. In fact it's so expressive that it can even parse itself, which is a "language of languages".

If you had first shown some hard-to-parse langcc syntax, then sure, _that_ would be evidence of expressiveness. But there's nothing impressive about being able to parse a "language of languages", since a language of languages can be LR(0).

That claim is sort misleading. The complexity of the specification's own grammar is largely unrelated to it's expressiveness.

I'd expect most parser generators in this category to be able to parse their own grammars.

Imagine a very weak parser that can only handle LR0. But if it uses a Lisp-like grammar language, it too is self-hosting.

3. Don't allow cross-platform requests in the first place; have your API consumers go through a server-side proxy on the same domain instead, or host it on the same domain in the first place.

That works for first-party JS. Doesn't work for a public API used by others.

Edit: Specifically purely client-side apps. For someone hosting a static HTML+JS app, it's annoying to have to set up and run a server-side route just to circumvent CORS.

(Maybe not so bad with something like Next.js, where it's easy to add a backend route to your primarily static website.)

And it adds an extra hop of latency to every request.

No, I left Dropbox 5 years ago.

But it might be easy to add? https://github.com/dropbox/dropbox-sdk-js/blob/main/src/drop...

Make sure to always set the URL parameter "reject_cors_preflight=true", which will make sure you're not inadvertently triggering pre-flight requests.

Unfortunately this caching is still per-path. For example:

    GET /v1/document/{document-id}/comments/{comment-id}

Alternative hacks: Offer a variant of your API format that either

1. Moves the resource path to the request body (or to a header that is included in "Vary"). Though the rest of your stack (load balancing, observability, redaction) might not be ok with this, e.g. do your WAF rules support matching on the request body? You also will no longer get automatic path-based caching for GET requests.

2. Conforms to the rules of a CORS "simple" request [1], which won't trigger a pre-flight request. This is what we did on the Dropbox API [2]. You'll need to move the auth information from the Authorization header to a query parameter or the body, which can be dangerous wrt redaction, e.g. many tools automatically redact the Authorization header but not query parameters.

[1] https://developer.mozilla.org/en-US/docs/Web/HTTP/CORS#simpl...

[2] https://www.dropbox.com/developers/documentation/http/docume... (see "Browser-based JavaScript and CORS pre-flight requests")

What does "distributed" mean in this context?

Each queue is implemented using a Redis list.

That seems to imply that queue itself is not distributed.

But maybe "distributed" refers to the fact that workers are running on multiple machines? (Though that is a bit confusing to me; sort of like calling Postgres a distributed database because the clients are on multiple machines.)

When you run a type checker, it's proving that a program conforms to the type, right? That's why it seems like the incompleteness theorem applies. (Though as I mentioned before, I'm playing a bit loose with the logic.)

Yeah, but the phrasing seems likely to mislead. It sort of implies that a Turing-complete type system can express all truths.