__ryan__

Simple async JavaScript is still single threaded with an event loop. In other words, your async code is just a task deferred for later and only one task runs at a time, only moving onto another task when complete or explicitly yielding via “await”.

Service workers are threads. They’re basically separate JavaScript processes you communicate with with IPC, with other special privileges and capabilities allotted to them.

What is it about it that makes you feel this way?

It was 5 billion calls to 500 million numbers over a 3 month period.

I report nearly all auto-generated unsolicited emails as spam. I also report nearly all follow ups to ignored cold emails. I will protect my inbox.

Accessing a users data is not the only reason for hacking their account. Performing actions on behalf of a user is just as much of a threat.

Edit: also, if an attacker dumps all the data today then loses access to the data tomorrow, having access to my password hashes means they can access my account and data later.

This isn’t the attack vector to be concerned about. More concerning is when there’s a data breach and an attacker gains access to hashed passwords. At that point, you attack the hash not the API.

This comment is an example of why I wouldn’t want any given website to choose my password.

You are correct that the period doesn’t count. Both email addresses belong to the same account. A possible explanation is that they have entered your email as a mistake.

Not sure if this was their motivation, but hardware acceleration also enables increased opportunity for fingerprinting, to my knowledge.

When does the standard library lie in this case?

The lie is when your code uses* the “any” value where a concrete type is expected.

I was misunderstanding your point with the deserialize.

Edit: “using” -> “uses”

Yes, “any” is a wart. And it’s a bad one.

The correct type for values you don’t know the type of (like the response of an API call) is “unknown”.

TypeScript does not provide the facilities you describe because there is not a one-size-fits-all solution to the cases that are possible and common in JavaScript.

It is left to the developer to decide how to validate unknown data at the boundaries of the API.

There are third party libraries that facilitate this in different ways with different trade-offs.

  The compiler actively lies to you about the types you’ll have at runtime.

I find this to be rare if you are using strict mode with proper TypeScript definition files for your platform and dependencies. Usually the lie is in your own code or bad dependencies when an “unknown” type (including “any”) is cast to a concrete type without being validated.

  In nearly any other typed language I have some deserialization mechanism.

Could you provide examples? I either don’t understand or I disagree.

I don’t think I’m following well enough to provide a meaningful response.

This is not meant as an argument against what you’re saying, because I know you were just giving an example, but I found this and thought you may find it interesting: https://www.hacklewayne.com/a-truly-strongly-typed-printf-in...

They’re suggesting outputting runtime type information by emitting different code based on the type of the value passed to their hypothetical “Type.keys()” function.

  You're forced to emulate exactness by always destructuring objects - not great.

It’s almost like using objects as enumerable maps is an anti-pattern.

Runtime type information is against the goals of TypeScript.

https://github.com/Microsoft/TypeScript/wiki/TypeScript-Desi...

Edit:

  Non-goals:
  …
  5. Add or rely on run-time type information in programs, or emit different code based on the results of the type system. Instead, encourage programming patterns that do not require run-time metadata.

    Also you should fill your database with houses - use AI or some sort of random data generator to generate them and just make sure there's a small but clear note on the listing saying this is AI data. It's not ideal but it is better than an empty database. Give people something to look at.

This genuinely made my stomach turn. If this is the future… I don’t know if I want in.

“Inception” is frequently misunderstood to mean entering other people’s dreams or having multiple layers of dreams.

In the movie, they of course have the technology to do these things, but it’s usually used for “extraction”: stealing information and ideas from one’s subconscious by infiltrating their dreams.

“Inception”, as used in the movie, is just the opposite of “extraction”: to plant an idea in someone’s subconscious by infiltrating their dreams.

So while I think it’s a stretch, it’s not as bad as suggesting that people can commingle in dreams.

If I know that an entity goes to great lengths to conceal secrets, why would I ever believe I know of their most secret secret?

Interestingly, “highlights” is not there.

“More quinoa”

A commuter typically takes a free public bus ride to work. The bus broke down this morning. The commuter had to go out of their way to take a different bus to get to work. Wouldn’t it have been better if they stayed and fixed the first bus?

It’s exhausting because: _____

If you find yourself struggling to articulate it, seriously and honestly consider whether you’re simply choosing to be stressed about it.

I’m speaking from experience here.

Do you have any HN-related extensions installed?

Edit: I truly did not believe you, but it appears to maybe be the “delay” feature [0]. Users with a delay set might show the asterisks until the delay passes.

My apologies.

0: https://news.ycombinator.com/item?id=231024

I’m sure they could, I imagine they’re appealing to those who prefer JSX’s syntax.

This is definitely solely an HN Replies thing.

I’ll criticize it.

I recognize this is a preview and I desperately hope this implementation isn’t kept around and treated as a quirk.

This implementation is extremely unintuitive given their explanation of the expected behavior of CSS Nesting and the & symbol.

To quote:

    The & signals to the browser “this is where I want the selector from outside this nest to go”.

Their explanation and the actual implementation result in a majorly different CSS selector.

The implemented functionality, however useful, makes no sense as a default if one can explicitly use :is to achieve this behavior like below.

    .foo .bar {
        .baz :is(&) {
        }
    }

The default should behave like they claim it does; simply replace & with the “outside” selector.

I’m specifically saying that prose/text and code are different contexts that don’t necessarily benefit from the same styles of writing.

What I was saying is that just because spaces in prose naturally improves visibility does not _necessarily_ mean that underscores and dashes improve overall readability across many contexts _in real code_, because code and prose are different. It could be the case, but it’s not the obvious innate property people are suggesting it is.

If it such an obvious innate improvement in readability, then why don’t we replace spaces with underscores in prose and handwriting? It would remove any ambiguity between intentional separation and awkward unintentional spacing or kerning. But we don’t and haven’t done that for some reason, so there must be something else at play.

Your examples (and many examples in this thread) of long sentences in these formats are not what code actually look like.

Real code has meaningful symbols and syntax that occur between identifiers that carry semantic meaning. Maybe the lack of symbols in identifiers in camel and pascal case make it easier to identify these other symbols and syntactic elements, so you end up with better overall readability. Maybe adding to that the flexibility of using camel and pascal and upper snake case for different "types" of identifiers improves mental mapping of code concepts that you'd lose if you always used snake case.

Again, I'm only making the argument that readability in code and readability in prose are two totally different things, and the effects of different casing and different identifier naming schemes are likely more subtle than what is better clearly separating words in the identifier.

There’s plenty of things that are done in code that we don’t adopt in prose and vice versa. You could just as easily make the case for adopting underscores in place of spaces in prose to increase readability, but we haven’t done that.

In code, you have to balance readability in many contexts.

Snake case and kebab case look more readable in isolation, but do they look better when used as part of a larger expression, for example part of a chain of member access and method calls and argument passing? I don’t think the answer is obvious, and it probably depends on other formatting affordances (e.g. breaking the expression up on multiple lines).

I’m on mobile and I don’t trust HN’s formatting to do any justice with examples, but it might be worth trying it out in your code editor.

  Why can't the style simply imply how much scope and importance an identifier has? 

Because lack of underscores doesn’t unanimously imply lack of importance or scope.

An alternative is to make the pipe operator a simple function application and provide syntax for creating simple pipeline functions.

For example:

    left |> right

Would semantically translate to:

    right(left)

And you could define a pipeline function like so, where the following:

    const myPipeline = @[
        one(@),
        @.two(),
        @ + three,
        `${@} four`
    ]

Would translate to:

    const myPipeline = (value) => {
        const _1 = one(value);
        const _2 = _1.two();
        const _3 = _2 + three;
        const _4 = `${_3} four`;
        return _4
    }

Or:

    const myPipeline = (value) => `${one(value).two() + three} four`;

And you could define the placeholder value name (which would allow nesting):

    const myPipeline = @it [
        one(@it),
        @it.two(),
        @it + three,
        `${@it} four`,
    ]

You'd combine the two syntaxes to get immediately-invoked pipeline functions:

    // Using a modified example from the proposal:
    envars |> @ [
        Object.keys(@),
        @.map(envar => `${envar}=${envars[envar]}`),
        @.join(' '),
        `$ ${@}`,
        chalk.dim(@, 'node', args.join(' ')),
        console.log(@),
    ]

This is better, in my opinion, than building the '%' placeholder syntax into the pipe operator.