Ok, good point, most languages I know use “C-style sequential function-calling” paradigm. Is there a specific idea that you have for a language that would better utilize our CPUs?

Notation that treats asynchronous message-passing as fundamental rather than exceptional.

I’m pretty sure there exists at least one research paper about notation for the actor pattern.

You explain pretty well why you don’t think C is a good fit for hardware we have today, but that warrants a proposal for something better. Because I for sure don’t want to debug programs where everything is happening in parallel (as it does in pong).

Yes, very much this. There are still my coworkers’s PRs in the feed, but not all of them and there is many other things there too.

What I’d want is to have notifications on the frontpage.

I’ve just realized that no, I don’t use bookmarks anymore. I used to use them, but nowadays, I just start typing the name of what I want to open and firefox omni-bar will find it in my history.

Ah here is the difference: I maintain a few gh repos and our company works exclusively on github. So in the morning, I open github.com to see notifications (via g-n shortcut).

Do you never open https://github.com/ where there is a “Feed” in the center of the site?

I wouldn’t say so - it’s not streaming app views from the server, it provides containers for apps, segmented into “grains”. So each open document gets it’s own container. Other than that, it’s just normal web apps (like immich or seafile).

For example, ether pad (document editor) is a) packaged to be single-click deployable on sandstorm (this is similar to dokploy), but also b) modified so that it runs each document as a “grain”.

In sandstorm, “grain” is some chunk of data + an instance of the app running. So when you open a document, it will spawn a new process for it on the server and attach the data needed to that process (similar to how you would attach volumes to docker containers). This grain is isolated from other open documents, which is good for security, but also good for development:

• apps don’t need to handle the organization or storage of documents (they just write to a dir and sandstorm associates it with the grain),
• apps don’t need to handle user auth or permissions,

The revolutionary thing about sandstorm is not all that much about administering hosting as it is about integrating deeply with applications.

My matrix server is nearing 5 years old. I have federation disabled, because I don’t need that - we are using it as a family chat. sqlite database I’m using is now 2GB, but other than that it is working great.

I do acknowledge that I’m not leveraging the things matrix is designed for (federation, e2e encryption), but to be honest, it’s not really good at that.

clap already supports all this: https://docs.rs/clap/latest/clap/struct.Arg.html#method.conflicts_with It’s just a great library, having you could think of and applying the same parse-don’t-validate mentality.

Jellyfin, and yes it thinks its very cleaver with mumbling metadata.

Report reason: I’m in this picture and I don’t like it.

I do find it funny though :D

There is also gruvbox. Not as much support, but I like it.

My laptops runs postgres, but it is still pretty portable

We are a matrix family, mind you.

Fun fact: in rust and python, they use “selfself” instead of “meme”

I hate that the pleasant news about standardization of CSV come with the let-down that is using two bytes for new lines.

Dan Luu. From summary of summaries:

I suspect I might prefer Rust once it’s more stable.

Just because we cannot prove something, doesn’t mean that we can treat strong claims the same way as proven hypnosis. If we cannot prove that UBI is overall beneficial, we just cannot believe it with the same certainty that we would if we had a bunch of studys on our side.

Look, I’m not saying that we have nothing - I’m just saying that what we have are educated guesses, not proven facts. Maybe “open question” was too strong of a term.

Well, you can conclude anything using your reasoning, but that does give the high degree of certainty that is sought after in the studies reviewed in the article.

Again, I’m not saying that I don’t believe static type checkers are beneficial, I’m just saying we cannot say that for sure.

It’s like saying seat belts improve crash fatality rates. The claim seems plausible and you can be a paramedic to see the effects of seat belts first-hand and form a strong opinion on the matter. But still, we need studies to inspect the impact under scrutiny. We need studies in controlled environments to control for things like driver speed and exact crash scenarios, we need open studies to confirm what we expect really is happening on a larger scale.

Same holds for static type checkers. We are paramedics, who see that we should all be wearing seat belts of type annotations. But it might be that we are some subset of programmers dealing with problems that benefit from static type checking much more than average programmer. Or there might be some other hidden variable, that we cannot see, because we only see results of code we personally write.