snaggen

I see where you come from. I first turned to Go, but at the end of the day it was a nice language but it didn't tick my boxes. One of my main issues for backend servers, is for them to be robust. They should never fail in runtime. That means error handling is quite important, and as few runtime errors as possible. Go, fails this hard. The strictness of Rust, may be a pain while learning, and some syntax may be less than optimal, but the result will almost never fail in production. I have in fact never had a backend I wrote fail in production. The error handling also makes it easy to find any errors due to things out of my control. I switched a project from Java to Rust, and the log shrunk by a factor 10.

Note, I still use Go sometimes, but it is not my go to language. And on a second note, that you point to .unwrap() indicates that you never really used rust to write a backend, since use of .unwrap() will panik if you use that. You normally use .unwrap_or(...) or some other better construct. Also, complaining about unwrap() would indicate that you prefer a null pointer issue? Because, dropping null/nil is one of the great design choices, having null/nil is just a recepie for getting a runtime crash.

wouldn't it be better to use #[cfg(target_os = "windows")] instead of checking an env variable?

Reference: https://doc.rust-lang.org/rust-by-example/attribute/cfg.html

So, Linux is written by system programmers for system programmers.

This must be one of the most uninformed comment in a long time. Already 2001, there was quite a lot of UI work being done by the company Eazel, founded by Andy Hertzfeld who from Apple and with a bunch of former Apple people. Around the same time, Ximian (I think) was pushing project Utopia with the idea to form project teams of people from kernel devs up to UX, to ensure common tasks worked out of the box. One result of this is that printer configuration on Linux is a much easier than on any other OS. This all happened 20+ years ago, there have been quite a lot of UX people involved after that. And my experience is that people with little prior knowledge have an easier time with a modern Gnome desktop, than with Windows. The problem here is that most people know Windows to some extent, and are used to the weird quirks there, but any slight inconvenience on a new OS make them quit.

So, I will finally be able to drop some deps and use the built-in chown. Nice!

Always happy to see more projects being open source.

Now, I don't have any experience with Axum, but my experience is that the frameworks are quite similar, so much of the porting tend to be in parameters and types, authentication and session (of course, this may vary from project to project). So if you are familiar with Axum this might be a good way to start contributing to Kellnr. Well, I guess if you just want to learn Axum, it might also be a good way to start, it will just be a little slower.... but I guess it is a good way to learn a new framework if you have the time to invest.

Great to see that this moves forward in a steady pace. And being able to compile Rust for Linux seems like a nice milestone, especially since many objections initially against rust in the kernel was about GCC support.

That depends on the job I want to do. But generally my selection is something like this.

1. Is it a short simple script: Bash
2. Longer script, then a more competent dynamic language like Perl/Python.
3. Backend, a strong typed compiled language, with as few runtime errors as possible. If it depends on some particular API, the language with good enough bindings.

Preferred backend language, Rust, since that have the least runtime errors, thanks to its strong typing and the great error handling. But I also use Go if it have better libs for what I do, or Java for situations where that is more suitable.

In the annoying popup, there is a cog wheel, clicking that will show a menu. That menu have a checked checkbox, Always offer to translate, uncheck that.

Yes, you have a point. However adding heat is often implicit when talking about melting stuff. However, if it requires 3400C, then the answer would probably include a comment about that.

Well, I agree. But what I mean is that when people ask physics questions, it is often implicitly understood to mean under current conditions. You rarely hear normal people or kids (who I find asks most of the physics question) include anything about frictionless vacuums in the question. (For reference: https://xkcd.com/669/ ). So, for the egg question, regular people would most likely consider the answer to be "No, except under very special circumstances". But, I agree with you that if a simple Yes/No answer is expected, it have to be Yes.

Well, for eggs, that are carbon based, you will in fact have problems since carbon doesn't have a liquid state at regular atmospheric pressure. I guess you can add pressure, but is that really what we mean when asking a question if something melt?