snaggen

I actually agree, I much prefer articles. However, I found this interesting since it looked at turbopack, parcel, rspack and others and talked about how it comes that the JavaScript ecosystem seems to start to use a lot of rust for their tooling. It was quite long though...

You don't have to use it....

Because of ownership you’re forced into certain hierarchies, which make the code ugly and hard to read.

For non-gc languages you always have ownership, in most languages you just have to keep track of it manually. And whenever the rust compiler gives an error, you would most likely have had a future issue in another language. For gc languages, this may still exist if you share data between threads, causing possilbe race conditions and data corruption. So, the ownership/borrow model is just a formalization of implicit rules that exists in most languages.

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.