This was in 1985, on a ABC80, a Swedish computer with a 3 MHz CPU. So, in theory it would be much faster, but I assume there were many performance losses (slow basic interpretor and thing like that) so that for loop got close enough to a second for us to use.
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.
This looks really interesting, and I love the easy to use docker images! So, now I guess I know what I will fiddle with this weekend....
They don't require CLA, since it's MIT license. So what they showcase is the benefit of copyleft.
Order? I write them as I need them... is my code chaos, yes!
Normally during a project, I tend to restructure the code quite a bit.
First when it is small, I do it like you and have everything in one file, then as it grows I start to split out the things in to multiple files/modules. Then as it grows even further, I create subfolders. Try to define parts of the algorithms and break them out to their own modules. Like if you have a scheduling part, then you move that to scheduler.rs. Also, move out special types to types.rs, error types to errors.rs to keep the area with the actual algorithms more clear.
So, that the code feels like a mess as it grows is just a normal thing. And often, it is not worth trying to plan that much ahead since it is very difficult to predict the needs.
But for a REST server I have something like this
src/main.rs
src/types.rs
src/api/v1/mod.rs
src/api/v1/errors.rs
src/api/v2/mod.rs
src/api/v2/errors.rs
src/api/v2/types.rs
src/tests/v1.rs
src/tests/v2.rs
But the before the v2 version of the api, there was just a src/api.rs, src/errors.rs . So, I think the key is to not be afrad to shuffle code around and restructure it as you need. And it will not always be good, but then you just do it again. One of the things with a very strict language like Rust is that you can shuffle it around, and rewrite it without a big risk of adding hidden bugs.
Where do I find that option?
EDIT: Found it, it is in the menu when you click on your profile picture.
You can show ads without tracking the user and violate privacy. But they are not just selling ads, they also collect user data and sell that. So, the correct question would be, how can they adapt to survive on just selling ads?
Not even Linguistically. Colored people implies, that people are originally without color, and then some people have been painted. Hence, implying that no color is the norm.
I think the author is correct about the compile / test ratio being drastically shifted in rust vs other languages. One thing to have in mind regardng this, is that in larger companies testing may be performed by a dedicated team. Hence, a shift to rust will give the impression of a much higher workload for the developers. In reallity the workload should be pretty much the same since the bugs from testing still needs to be fixed, but that will be spread out over a larger time span due to going by the test team first.
Just to be clear, I'm not the author of the article. I just found it on the Internet and found it interesting.
Ahhh... Sorry, of course there was the 2021 edition in between.... Ignore me... 🤣