Meanwhile, I’m using Pixel 3a for my main phone (for quite a few years now) and consider it a relatively up-to-date phone.

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).

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.

We are a matrix family, mind you.

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.

The original author does mention that they want to try using rust when it becomes more stable.

This is why any published work needs a date annotation.

Damn, this actually looks really good! Is there an estimate on when this will be useable-ish as a main phone for non-dev users?

Hindley-milner type inference for the win!

It’s hard to implement, but the result is a statically typed language, mostly without type annotations.

Because it is hard to design a study that would capture it. Because it is hard to control many variables that affect the “bugs/LOC” variable.

My conclusion is that it is hard to empirically prove that “static type systems improve developer productivity” or “STS reduce number of bugs” or any similar claim. Not because it looks like it is not true, but because it is hard to control for the many factors that influence these variables.

Regardless of anyone’s opinion on static/dynamic, I think we still must call this an “open question”.

Or post to gemini instead

Will read, looks interesting and I already agree with the premise but,

please people, add metadata (date, author, institution) and a bit of formatting to your pages. Not much, 10 lines of global CSS would help already.