snaggen

A reference &T holds a pointer, ie. the memory adress to the actual content of T

So, in the example x doesn't hold the value 42, it holds the memory adress to the memory there the integer value 42 is stored. So, to access the value, you need to dereference the reference. Which is why you need to use *x when you assign the value.

Fixed it.... I come from a language culture were we like our negations :) Also, not native english speaker, so combine the two and you are in for a ride!

But isn't it kind of obvious that if you are able to do 180k times improvement, then the baseline is probably not very impressive to begin with. Still, that doesn't take away that the optimizations were impressive, and that it was interesting to read about it.

And if I understand it correctly, it now would be enough for them to ping in this community in a post to get it do show up here... so that might be something for them to think about.

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

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.

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.