karanlyons

A naïve hash of the data you’re encrypting stuffed into the nonce leaks whether two plaintexts are the same (or…collided). A hash of the key and plaintext leaks whether the two plaintexts are the same under the same key. Using a proper keyed MAC prevents any rainbow table style attack in either case.

Generally speaking leaking that two plaintexts are the same is better than leaking two plaintexts XORed together. If you’re in a use case where that’s liable to happen (i.e., you don’t rekey “frequently”) I’d happily take the former leaked bit over the latter leaked messages.

There are also a handful of existing constructions you can just take off the shelf rather than rolling your own thing and getting it wrong.

There’re also SIV constructions if you’re the more cautious type, which isn’t a bad type to be in cryptography.

A lot of these look like children. Nowhere in the article is it mentioned that a lot of these look like children. No one in the comments has brought up that a lot of these look like children. A lot of these look like children.

Because `const` is a js level keyword that has different semantics: it applies only to the reference binding being immutable, not the value as being so. `const a = "hello"` does have the shape `"hello"` as you’d expect, since strings are immutable in js and the `const` keyword makes the binding immutable as well. But objects are mutable, so TS can’t be a superset of javascript and change the semantics of that behavior. Hence `as const`.

This is different to the widening of value types within objects, which is a tradeoff made towards unsoundness with the belief that it would otherwise make interoperability with existing js too difficult, for which `as const` now serves as a way to explicitly opt into sounder behavior.

`as const` is useful there as well, as TypeScript’s type inference only narrows as far as the type and not the literal value. `let z = {text: "hello"}` has the shape `{text: string}`, with `as const` it has the shape `{text: "hello"}`.

I'm not arguing that one should write things from scratch. I think I may have poorly articulated my position, but that you and I actually share the same opinion here.

I don't think you should reinvent the wheel unless for some reason all available wheels are insufficient for your case. But knowing this requires that you have some understanding of how wheels work, how to compare them, and how to hew your own out of raw materials if the need arises.

I would say JS is partially a wild west due to title inflation and the relative numbers of lesser experienced developers in the space relative to, say, your pool of Erlang engineers.

There's absolutely nothing wrong with using black boxes, and I'm not arguing that it should be totally avoided. I'm arguing that a lack of understanding of how to solve your problem leads to only gluing black boxes together as you lack the understanding with which to make more nuanced decisions, and to solve any part of the problems you have yourself.

It's also not necessarily required that you understand all of what you're doing down to the logic gates, but if you don't (to crib your example) understand some of what docx parsing may entail, or can't actually write any sort function (nor understand how to compare them), you're stuck with black boxes at even the highest levels, and then you're very likely to be exposed to the article's defined fatigue as you continually jump to whatever looks shiniest, lacking the understanding with which to properly compare your options.

> Many JavaScript developers are scared (by scared I am paralyzed in the face of death catatonic scared to the most possible irrational extreme) to write original code when often times original code takes less time and is a better fit to the immediate problem. This is called Invented Here Syndrome and is internally coddled when developers are appeased by writing configurations opposed to logic.

I think this is true of a much larger category of developers than JS developers (though one could argue that defining yourself by a specific language is indicative of belonging to this category), that is developers who can't do more than plumbing, i.e. developers who can't actually solve problems properly on their own.

The flighty attraction to the new shiny is somewhat driven by a lack of understanding of how either the new or the old shiny actually work. If you understand the job you're setting out to do you're in a much better position to decide upon tools, frameworks, what to do in house, etc. If you don't you're stuck gluing black boxes together, because any actual code you write will be far worse.

JS being an "accessible" language and a mandatory part of practically all software companies with a front facing website makes this the most apparent in both the constant flow of new tools and libraries and the view that the new tools and libraries must be adopted. But any novice developer can fall prey to this behavior regardless of their choice of language, JS just makes it easier.

You can hack that in with a decorator if you’d like, at some cost to performance.

Not everyone speaks English as a first language and “payed” is a completely reasonable assumption given how a bulk of words are conjugated.

Yes, and it is...not great. It's generally fine as far as the language goes (considering it's a retrofit), but the builtin asyncio library is not the way to go in my opinion. trio is far better for just aping a lot of the Erlang way of things.

But even then it's hard to debug, or work out ideas in the REPL, testing is a bit more complex than it should have to be, etc. There are probably better languages to reach for (I'd love to see rust firm up a one true way of async).

Can you network multiple boards together to drive larger LED arrays in sync?