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.

deleted by creator

deleted by creator

What bugs do you mean? Anything serious i should know about?

Rust will take time - it has a few concept that I haven’t seen in javascript/python/java/C++ family of languages. But it gives “zero-cost abstractions” i.e. a way to write high-level code without any performance penalty. And it has great tooling and WASM support, which is what you’d be after.

But as I said, it is all not worth it now, just for this application.

From what I read, it could easily be a tauri app, without a backend: just index.html in your system’s webview.

I did also forget to say it does look very nice, with animations and proper polish!

If you do delve into improving the performance, I suggest using Rust and no_std crates for dealing with images, such as https://docs.rs/zune-jpeg/latest/zune_jpeg/.

It would probably take some time to get it working, but it would probably increase performance and support any format you can find a crate for. But it does not seem like it’s worth it.

I’ll add this to my list of “things I might to when I don’t have a side project to waste my time on” :D

If you are interested (and can pull together a bit of funding) I can look into how we could do this optimization in WASM.

It’s JavaScript.

And it is slow, but not as slow as I expected it to be. I’ve optimized a photo I’ve taken with my DSLR, 6.3MB, 24MP, JPEG. It has taken ~50sec on this phone, in Firefox.

I know, it’s a phone, but also, my phone can and does save, optimize, and apply filters to such images in <1sec.