sapiogram

That's a weak correlation at best. What about when it's still weather in winter? It's not unusual at all.

Fair, but that's a property of for loops. Variable in closures are still always captured by reference.

No, that's a mistake in the article. The variable is still captured by reference, but `let` is causing it to be re-declared on every iteration of the loop, not mutated.

The following code prints 1, 2, 3. It wouldn't do that if the variable was captured by value.

    for (let i = 0; i < 3;) {
        setTimeout(() => console.log(i));
        i++;
    }

Thanks for the links, that adds a lot of important context.

I don't think it's fair to call Go and Javascript's behavior "implicit", they just always capture variables by reference.

Rust variable capture is implicit though, but it can't cause the problems described in the article, since mutable references are required to be unique.

If you actually opened the article, I think you would find it interesting. I agree that a well-configured eslint catches 99% of the weirdness, but this article tries to be about the remaining 1%.

The author's explanation seems perfectly correct to me. Where does he "misunderstand block scoping vs lexical scoping"? By the Wikipedia definition:

> lexical scope is "the portion of source code in which a binding of a name with an entity applies".

...both `let` and `var` are lexically scoped, the scopes are just different.

> You never programmed in Go, I assume?

You might want to step off that extremely high horse for a second, buddy. It's extremely reasonable to expect a type-safe pool that only holds a single type, since that's the most common use case.

Thank you so much for this comment. I think Russ Cox (along with many others) is way too quick to declare that removing one source of UB is worth a (purportedly) minuscule performance reduction. While I'm sure that's sometimes true, he hasn't measured it, and even a 1% slowdown of all C/C++ would have huge costs globally.

> I'm not aware of any JS runtime outside a browser that supports concurrency (other than concurrently awaiting IO), so you can't do parallel compilation in a single process.

You haven't looked very hard then, NodeJS has supported worker threads for years. However, to uphold Javascript's safety guarantees, they can only communicate via message passing, or sharing a special `SharedArrayBuffer` datatype, neither of which are well suited to sharing large immutable data structures.

So, a go enthusiast who does exclusively backend work? Seems likely enough, given that community's overall disdain for Javascript.

They're not "definitely" an AI. Sounds like a normal Go enthusiast to me.

> I mean, I can't think of a time a high profile project written in a lower level representation got ported to a higher level language.

Software never gets rewritten in a higher level language, but software is constantly replaced by alternatives. First example that comes to mind is Discord, an Electron app that immediately and permanently killed every other voice client on the market when it launched.

Rust loses a lot of its nice properties without borrow checking and lifetimes, though. For example, resources no longer get cleaned up automatically, and the compiler no longer protects you against data races. Which in turn makes the entire language memory unsafe.

It's definitely a tool that must be used carefully, and why informal rules like "features should be strictly additive" exist. I'd say they are very commonly used by large libraries, for example, here's the list of features for Axum, (arguably) Rust's most popular http server: https://docs.rs/axum/latest/axum/#feature-flags

> In practice you can't combine no_std and std within a single project anyway

You can with Rust features. It allows a library to conditionally compile certain parts of the code, and users of the library can decide which features to enable.

If a library only uses stdlib in code gated by #[feature(std)], users can disable that flag, and use the library in no_std contexts.

In Rust it's literally impossible to use a returned value without checking the error. This bug also cannot happen with Java, C# or Javascript exceptions. This particular failure mode is unique to Go.

errcheck will not catch everything. For example, it will not stop you from using a value before checking the error, as long as you check the error later. I've personally broken things in production because of that corner case, despite (usually) being very careful about error handling.

The go standard library also recovers from panics internally in some places, for example for gradient descent parsers.

I don't think Jevon's Paradox applies here. People won't buy healthier food, they'll buy less food.

> If Bob is floating in space in a capsule, and a very heavy asteroid floats past, the amount that Bob's capsule is moved is dependent on the speed of the asteroid?

Yes

> Does that sort of thing have to be considered when planning the orbits of probes etc?

Yes, it's a primary concern when sending probes to other planets

> Is Earth traveling fast enough, from the viewpoint of Alice floating near the sun, to have a gravity "tail" or "wake" trailing after it?

If I understand you correctly, then classically (i.e. ignoring relativity), no. Your gravitational acceleration towards the earth depends only your distance to it. If you consider general relativity? It's... complicated.

No, the formula for the power of a black hole's Hawking Radiation is very straightforward, and it only depends on the black hole's mass.

What if it passed through you at hyperbolic velocity (with respect to earth)?

> and the cost to charge was $0.68/kWh.

What in the world. In December, southern Norway had similar electricity prices for two hours, and caused enough of an uproar that the government is still trying to live it down.

I think you need to specify what you mean by "without a runtime". Do you mean "without a garbage collector"? "Without memory allocation"? Even C has a runtime, just a very small one.

`std::variant` is a clever piece of template hackery, but it doesn't come close to Rust enums. `std::variant` has no named variants, no pattern matching, no exhaustiveness checking. In Rust, it's not unusual to have an enum with dozens of variants, good luck doing that with std::variant.

I'm sure you could technically emulate all this in C++ is you keep throwing template metaprogramming at it, but at that point anything is a C++ subset and the statement loses all pratical meaning.

> Rust is a subset of C++ with extra static checks.

While this may work as a rough heuristic, it's not true in theory nor in practice. First example that comes to mind: Rust has proper sum types (Called enums), which are used everywhere, and C++ doesn't have anything like it.

Nothing about that implies re-writing legacy code.

Because of what?

Definitely agree. My theory is that Rob Pike was mentally stuck in the 90s, when C++ was still a common choice for non-performance-critical entreprise code.