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?

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.

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?

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

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

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

...

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?

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

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

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

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

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

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.

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

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

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

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.

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.

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?