As a global citizen of Earth, I would agree. But I'm also a citizen of the United States, and have a vested personal interest in its academic and economic superiority. And I think that's normal. You don't even have to be nationalistic or patriotic about your particular country to feel that way. Academic and economic declines in any country will cause problems for everyone who lives there.
Of course there should be. However, those nations should worry about that on behalf of their citizens. No other nation is going to concern itself with whether Americans can live close to their parents.
Yup, the author is in a fairly rare fortunate situation for someone who is good in his field. A lot of us moved countries or continents to be good at our jobs, and there is always a personal cost.
Although, for grandkids, I guess that when you are far you are also more intentional with making sure you spend time with their grandparents when they are far.
There are plenty. The author is over exaggerating the prestige of CMU compared to other institutes outside of the USA.
Just in the western countries:
Toronto, Cambridge, ENS in France, the many max Planck institutes in Germany (eg Tubingen), the two federal institutes in Switzerland.
Faculty positions in any of those are likely to be better than CMU (in terms of start up package, funding, quality of students, quality of faculty, and ability to hire people).
This is the sort of attitude that allows nations to fall. If a nation isn't protecting it's most valuable resources, they will be taken away by others who want them.
in this case, no. it's a client game and performance isn't at all critical, so the state and loop could be trivially handled by a regular js function. if at some point a server architecture was desired, it would be trivial to host that function on node.
my take: as a backend developer he was fixated with the idea of having a server no matter what (if your only tool is a hammer, everything looks like a nail), and as go was his main language he just went with that. then he figured out it didn't really have a point, but instead of just translating that simple logic to js he overengineered the whole thing and overcomplicated his design and build process by transpiling to wasm.
there are some bugs, though. i just won a couple of matches at escoba (very nice little game, i hadn't played this for ... decades!) and the game state wasn't properly reset for the next. that's probably the llm ...
The front end is still react. But I'd be curious to know if LLM's are less prone to errors generating code for strongly typed languages over others like Javascript.
From experience: A static type system is MUCH better for agents than dynamic. I've done a few projects both ways - the agent is just much, much better with the static system because it sees compile errors right away, and also has access to better static analysis tools. I don't know how much the types themselves help the LLM, it's better context but more tokens, but the agent seeing errors is just a huge difference.
It's also much easier for you as a developer to digest the code if you need to refactor because you got lazy and accepted some slop.
In my experience, a massive YES. At least with agenetic models that have an iteration loop, and in languages like Rust where the type system is strong enough to prevent categories of bugs.
Why would you edit or delete files inside a running container? It’s ephemeral and supposed to be used stateless. You can attach volumes from host system if you need persistence.
At least one use case I've seen for Docker is to replicate the massively microservice oriented system. If your app is deployed across 200 different containers in prod, you're going to be testing it by spinning up the same basic containers with Docker in dev. That means a lot of incremental changes-- trivial stuff like adding transient logging or bypassing default flows-- inside the container as part of the development process.
Then you get into politics: you might need change XYZ for your feature, but you don't own that common image and have to rely on someone else to deploy it, so until then it's manual patches.
> Then you get into politics: you might need change XYZ for your feature, but you don't own that common image and have to rely on someone else to deploy it, so until then it's manual patches.
Or just make your own patched image of XYZ and use that as a base.
Because there are different use cases. About 100% of the people I talk to that use docker, are using it to make a separate set of dependencies available in a possibly-different distribution. For THOSE people, the ephemeral, stateless nature of docker is a huge detriment in usability, and a chroot would be far more appropriate. I see docker users waste countless hours working around its statelessness. All the time. YMMV
> ephemeral, stateless nature of docker is a huge detriment in usability, and a chroot would be far more appropriate
But ephemeral changes (e.g. inside the running container) are the opposite of statelessness in the comment you are responding to?
And if you have required intricate custom changes in mounted host volumes (config, ...) that are not living alongside the compose file in the same repository, you can have "statefulness" that survives killing the containers.
If you want stateful filesystems, you should be using a different tool. https://12factor.net/ outlines the design philosophy of serving compute resources in the cloud that containers (not docker, containers) attempt to solve. Inventing use cases for containers that are not the intended purpose, is not surprising you are having issues. You can make holes in things with drills and guns, but only one of those tools is being used for their intended purpose.
