joshkel

Yes. I don't remember Murderbot using the Rin disguise / persona later on.

Why do you say that?

I don't have access to the books right now, but from what I remember, Rin is referred to as she/her, and random Reddit comments (https://www.reddit.com/r/murderbot/comments/118s7on/comment/...) back that up.

For what it's worth, Murderbot's "Security Consultant Rin" human disguise is apparently female.

Interesting.

The way I was taught Python, you really, really don't want to use bare `except:`, because it catches _everything_: Ctrl-C interruptions, system exit, etc. Instead, you really ought to use `except Exception:` (where `Exception` is the base class for any "normal" runtime error).

So I definitely understand the rationale, but it's hard to say it's worth the pain of backward incompatibility - we have linters, style guides, etc. that can catch this.

The FTC rule banning noncompetes was blocked by the courts: https://www.npr.org/2024/08/21/g-s1-18376/federal-judge-toss...

As explained by the FTC, "A district court issued an order stopping the FTC from enforcing the rule on September 4. The FTC is considering an appeal. The decision does not prevent the FTC from addressing noncompetes through case-by-case enforcement actions." (https://www.ftc.gov/news-events/features/noncompetes)

As I understand it:

Meltdown lets a process read from kernel memory.

There are several variations of Spectre. The first variant ("Spectre V1") lets a process read its own memory; the second variant ("Spectre V2") lets a process read another process's memory.

Web browser manufacturers seem to be focused on preventing Spectre V1, although I'm unclear on whether that's because V2 is too hard to exploit from JavaScript, is mitigated in other ways (e.g., CPU updates), etc.

Further reading: https://stackoverflow.com/q/53042230/25507, https://stackoverflow.com/q/48200753/25507, https://security.googleblog.com/2018/07/mitigating-spectre-w..., https://webkit.org/blog/8048/what-spectre-and-meltdown-mean-..., https://en.wikipedia.org/wiki/Spectre_(security_vulnerabilit...

Yes; you can see a collection of the high-pressure comments at https://research.swtch.com/xz-timeline. (E.g., "Submitting patches here has no purpose these days… It is sad to see for a repo like this." "You ignore the many patches bit rotting away on this mailing list. Right now you choke your repo.")

There's a good write-up of the shortcomings that the new config file is trying to address here: https://eslint.org/blog/2022/08/new-config-system-part-2/

E.g., faster and simpler file access from removing tree-walking for multiple `.eslintrc.*`; better defaults in line with modern JavaScript; better compatibility with modules and Node.js's own file loading.

(And I suspect there's an element of "As long as we're having to introduce a breaking change, let's make it explicitly breaking by also changing the filename.")

Carbon and Cpp2 are both "C++ successors," broadly speaking. However, they take different approaches in their design:

Carbon is a brand-new language that's designed to have seamless interoperability to C++.

Cpp2 is C++, just with a different syntax. (The goal is to even be able to mix Cpp2 and C++ syntax in the same source file. The initial implementation transpiles Cpp2 to C++ source code, similar to how the original C++ implementation transpiled C++ to C, rather than implementing a full compiler.)

Their overall goals appear to be different, too: The Carbon README states, "Existing modern languages already provide an excellent developer experience: Go, Swift, Kotlin, Rust, and many more. Developers that can use one of these existing languages should." With that mindset, it sounds like more of a stopgap for projects already invested in C++. In contrast, I believe that Sutter would argue that C++ still has the potential to be a viable choice for many tasks, and Cpp2 is a way to realize that.

According to https://www.open-std.org/jtc1/sc22/wg21/docs/papers/2021/p23..., it's an "unadopted feature being explored."

There's more information about the proposal at https://gustedt.wordpress.com/2022/01/15/a-defer-feature-usi...

As someone who uses Jest and alternatively enjoys and is frustrated by it, this isn't all Jest's fault. Node is just now releasing fixes for [significant memory leaks](https://github.com/jestjs/jest/issues/11956#issuecomment-180...) around ESM support within the [VM APIs](https://nodejs.org/api/vm.html) that Jest depends on.

In addition to the other comments -

TypeScript deliberately takes a "good enough" approach to improving JavaScript, instead of designing an ideal but incompatible approach. For example, its handling of function parameter bivariance (https://www.typescriptlang.org/docs/handbook/type-compatibil...) is unsound but works much better with the existing JavaScript ecosystem. By contrast, a more academic functional programming language would guarantee a sound type system but would be a huge shift from JavaScript.

By analogy, Herb Sutter is arguing that something like the C++ Core Guidelines (https://isocpp.github.io/CppCoreGuidelines/CppCoreGuidelines), with tooling help in this new Cpp2 syntax, can bring real improvements to safety. Something like Rust's borrow checker would bring much stricter guarantees, backed by academic research and careful design, but would be incompatible and a huge adjustment.

A small addition: Structural typing means that TypeScript normally allows extra properties, but in contexts where you're immediately declaring and using a type, TypeScript will complain.

For example: `const user = { name: 'Bob', city: 'Reykjavík' }; saveUser(user)` is allowed because of structural typing. But `const user: User = { name: 'Bob', city: 'Reykjavík' }` throws a compile error; you're telling that you're specifying a `User`, but the value you give is not (just) a `User`.