IMO, the text may be seen as a piece of advertising for a fictional "de-programming" (like they call it) treatment from a cult. However, it's written for an abstract general kind of cult, described only in terms of what is common about several cults. It's not specific about anything. Just like well done cold reading: it's right, but unspecific.

I believe the idea is that you identify some of the things you're doing in your life as a cult (guided by the general features given in the text) and pay more attention to them. The text, however, is vague enough to classify a lot of things as cults, even though you/I/we may believe these aren't.

In computer graphics, the situation is often different. Usually, you have small matrices (kxk for k=2,3,4); a huge number of vectors; and you want to apply your matrix to all of those vectors. Very often, these matrices have very well known forms and also known well behaved inverses. There isn't really a significant computational cost in computing the inverse (you'll very often write down its formula by hand), and conditioning is usually not an issue (consider a rotation matrix for example or undoing translations with homogeneous coordinates).

When people do have ways to go around this problem, they do use Newton's method for large scale problems.

https://github.com/helix-editor/helix/blob/master/screenshot...

Indirectly (a lot indirectly), sure. Maybe the software should perform better or maybe have fewer bugs because programming language X or Y is understood to help with those things. Maybe it showcases a more flexible architectural design, which leads to more potential features in future versions, etc.

> Google's reputation for not supporting things long term

I didn't know Google had such a reputation. I mostly use drive and gmail, so it was fine to me.

Does google really have such a reputation? Any place I can read more on this?

Not 0, but really not much, that is true.

I remember the shutdown of google reader. I tried it once, but let go of it before it was shut down.

But I really didn't know google had this kind of reputation.

I miss Google Reader and Google Wave the most.

Youtube Music is a huge step back. Spotify is far too playlist and recommendation happy, I want to listen to albums not curated lists. Tidal is decent, but similar to Spotify. Apple Music is the one I haven't tried for more than a couple of days and I don't recall what I didn't like about it.

Spotify is okay and does have some nice features in the way that casting works and multiple devices joined to one account, but it's certainly not as enjoyable to use.

I've concluded the price saving isn't enough to use a product who's UX I enjoy less, even if it works well for other users.

The point I was making about Spotify is that even if I solely listen to music as full albums, I only get recommendations for playlists. I rarely want to listen to a playlist. There are a number of other things I don't like about Spotify, but it works well enough.

That doesn't mean you shouldn't try to put it in a convenient place.

One way to think of the post is: where you want pi to come up?

With arc length parametrization f(r) = (cos(r), sin(r)), it comes up in the parameter space (one turn: 0 <= r <= 2 pi). If you had the whole thing in terms of turns, you'd instead have (as a primitive) some kind of function g(t); with one full round for 0 <= t <= 1. It'd then have to be true that

f(2 pi t) = g(t) = (cos(2 pi t), sin(2 pi t)).

Pi would come up in the velocity:

f'(r) = (-sin(r), cos(r)) = if

(i u means rotate the vector u by 90 degrees counter-clockwise)

g'(t) = 2 pi f'(2 pi t) = 2 pi (i f(2 pi t)) = 2 pi (i g(t))

Before, you had |f'| = 1. Now you have |g'| = 2 pi.

For classical physics (kinematics and dynamics) applications and classical geometrical applications (curvature, etc), it's really convenient to have that speed term (|f'|) being 1. This is one of the major motivations for arc length parametrization.

By the way, this can't be understated. It really simplifies kinematics, dynamics, geometry, etc, having |f'| = 1 throughout. It's not just for circles. This can be done for an extremely large class of curves and it makes the related math much more understandable and easier to deal with.

For a lot of computer graphics (I believe this is where Casey comes from), you care less about tradicional mathematics for physics and geometry. So you'd rather (maybe) take this pi appearing in the parameter space and push it to the velocity.

While some applications written in C++ are not performance sensitive, performance tends to be a major objective when choosing C++ for many applications.

I think this might have been fixed in latest versions of Java, though, not sure if value types are already in the language or just coming soon.

Aside from that, it's my understanding that GC can be both a blessing and a curse for performance (throughput), that is, an advanced-enough GC implementation should (theoretically?) be faster than manual memory management.

There are a few different ways a GC impacts code performance. First, even low-latency GCs have a latency similar to a blocking disk op or worse on modern hardware. In high-performance systems we avoid blocking disk ops entirely specifically because it causes a significant loss in throughput, instead using io_submit/io_uring. Worse, we have limited control over when a GC occurs; at least with blocking disk ops we can often defer them until a convenient time. To fit within these processing models, worst case GC latency would need to be much closer to microseconds.

Second, a GC operation tends to thrash the CPU cache, the contents of which were carefully orchestrated by the process to maximize throughput before being interrupted. This is part of the reason high-performance software avoids context-switching at all costs (see also: thread-per-core software architecture). It is also an important and under-appreciated aspect of disk cache replacement algorithms, for example; an algorithm that avoids thrashing the CPU cache can have a higher overall performance than an algorithm that has a higher cache hit rate.

Lastly, when there is a large stall (e.g. a millisecond) in the processing pipeline outside the control of the process, the effects of that propagate through the rest of the system. It become very difficult to guarantee robust behaviors, safety, or resource bounds when code can stop running at arbitrary points in time. While the GC is happening, finite queues are filling up. Protecting against this requires conservative architectures that leave a lot of performance on the table. If all non-deterministic behavior is asynchronous, we can optimize away many things that can never happen.

A lot of modern performance comes down to exquisite orchestration, scheduling, and timing in complex processes. A GC is like a giant, slow chaos monkey that randomly destroys the choreography that was so carefully created to produce that high-performance.

My comment is about the thinking behind making this decision, C++ or not. It wasn't "is it speculative that GC will add a cost?" or something like that.

I wonder how much of the thinking that leads one to conclude "I need so much performance here that I can't afford a managed language", for example, is real carefully thought vs. speculative.

GC overhead is always hard to measure except end-to-end, because it is distributed over everything else that happens. Cache misses, TLB shoot-downs. Mitigations are very difficult to place.

Practically, you usually just have to settle for lower performance, and most people do. Double or triple your core count and memory allocation, and bull ahead.

I'm with you. One should look at latency requirements and the ratio of profit vs server costs when making a decision. AKA when your product generates $250k/month, you're paying three programmers $40k/month, and your AWS bill is $500/month isn't the time to try and shave pennies.