It sounds like they use everything to give their subscribers good results. Which is what it sounds like I am paying for.

I doubt a judge will look favorable on people saying "but my LLM said it was 1k"... cause they are known to hallucinate.

It's nothing new, its just the old stuff packaged together and pre-configured.

I mean this is true, but we aren't talking about the consumer here. We're talking about the industry which is to say the powerful people who own and run all these companies.

What has happened is that those overseas countries now have all the experienced engineers over there and they know it. So you see things like the Trump admin begging Korean companies to keep their workers in the US because they understand how to actually do these things. And the reason the Trump admin did that is because they owe favors to the rich people who want to profit off of factories in the US.

I actually think if they did just give 100k to homeless people a year that it would actually solve itself.

The problem is they give 100k to grifters who say they'll do something about it.

> I believe that an intro course should get students coding since the first major hurdle is learning how to construct any kind of program at all. The switch to a more "employable" language isn't going to make education worse.

None of this is the issue at hand. The switch to python is because industry uses it. The article correctly makes the point that racket was intentionally designed to get students coding as easily and quickly as possible. It has multiple steps of teaching languages for exactly that purpose, introducing concepts in ways that let students grapple with them one at a time in an interactive environment.

Meanwhile in python complex topics like duck typing, object oriented methods, exceptions, the distinction between iterables and lists, how to use a command line/terminal or how to configure an IDE, and so on must be covered before people can start writing code for the exercises. Racket is streamlined for beginners.

The root cause of the messenger failing was the missing nail. Sure it could have been many other things, but in this case it was the nail. And if it was a pitched battle that was narrowly lost by one message, sure, they could have won or lost because of a dozen other factors, but in this case it was the missing message. There are likely many other important things to worry about, but in the system as it is today, it failed for want of a nail.

Plenty of large engineering outages were because of single keystroke typos. Should these systems be less prone to human error? Of course. Are they? Some of them are, but right now some of them aren't.

The point being made is that small things can be important if other things go wrong. We should fix the other things, but often they are much harder to fix than the small thing. And really, we should care about both, since humans are capable of that.

- Heap allocated call frame. Instead of being pushed onto the stack, co-routines tend to have their call frame (local variables, arguments, etc.) placed into heap memory (or at least may be place-able into heap memory). This often enables the other features.

- Control can leave co-routines in more ways than standard function calls. Generally this means returning (often called "yield") to the caller without completing the whole function. It can then be later resumed, returning to where the function originally left off. Generators are a common pattern enabled by co-routines that rely on only this part (and so many systems can optimize out the heap usage, for example).

- A co-routine is usually an object with an interface that allows you to move it around and resume it in different places than it was originally called. This can include on different threads, or depending on the sophistication of the system, different processes or machines.

Those are the three big points in my mind. I'd recommend trying lua coroutines, personally (I like minmalist engines like defold to use it in) to really get a feel for how these are on the edge between "language feature" and "library feature".

The paper is much more on the side of application and system performance. But you couldn't even write such a system without a library like this providing you the tools to do so. This is much more in the domain of "basic tool for ecosystem" than "library for specific tasks". It's on the user of the tool to address the paper's question, not the builder of the tools.

It allows the public to comment and maybe the senator will like the public support they are getting. Alternatively a pharma lobbyist will show up and toss them a few hundred thousand in campaign contribution promises. And they'll weight the relative value of those things. Depending on how that goes they (or another senator seeing this play out) will actually make an issue of it and it will start the more formal processes.