snaggen

joined 2 years ago
15
This Week in Rust 515 (this-week-in-rust.org)
 

@[email protected] wrote:

I have rewritten the Build Configuration chapter of the Rust Performance Book.

https://nnethercote.github.io/perf-book/build-configuration.html

It's now a much better guide to all the ways you can change the performance characteristics of your Rust program without changing its source code. These characteristics include runtime speed, memory use, binary size, and compile times.

Big improvements to your Rust program's performance are possible with simple changes. Try these things out!

 

Not happy to link to the evil site, but there was no other link, and I thought that there might be people here that migtht be interested in helping out with porting Kellnr to Axum.

Here is the original request by /u/secanadev on the evil site:

Hi Rustaceans,

I’m the author of https://kellnr.io. When I started working on Kellnr three years ago, https://rocket.rs was “the web framework” to use. Unfortunately, the project seems dead. Before adding more functionality using an unmaintained framework, I want to port Kellnr to https://github.com/tokio-rs/axum.

Kellnr is a huge project, so migrating it will take a long time as every handler, state, and test have to be migrated. I’ve never worked with Axum before, and the amount of work feels overwhelming.

Are there any brave Rust warriors with experience in Axum? If so, would you be interested in helping me migrate the project?

[–] [email protected] 23 points 2 years ago

I guess this answeres my previous question about the lack of updates to the Intellij Rust plugin.

[–] [email protected] 1 points 2 years ago (1 children)

I like skimming through these summaries, and especially since there are so many things happening on so different levels. It it everythign from tiny snake, to very advanced games. Good read.

[–] [email protected] 1 points 2 years ago (1 children)

What are the benefits of Smol compared to the dominant async framework Tokio?

[–] [email protected] 1 points 2 years ago

Cannot both be true?

[–] [email protected] 1 points 2 years ago

Darkreader didn't work well, but disable that and it looked ok in Firefox on Android.

[–] [email protected] 6 points 2 years ago

Order? I write them as I need them... is my code chaos, yes!

[–] [email protected] 4 points 2 years ago (1 children)

Well, bringing over comments by a bot feels totally wrong. I'm not sure we want to have reddit comments here, since it sometimes differ quite a lot in culture. Bringing over posts only, could be done by bot if it is determined by a human, but then on the other hand I don't see the point in involving the bot. Then you just look at the list in the bot instead of in /r/rust , and it is not that hard to just manually post if you find something there that would fit here. I like what you are trying to achieve, but I'm not a big fan of bots... it is so easy to get them wrong and then they can cause a lot of harm.

[–] [email protected] 4 points 2 years ago* (last edited 2 years ago)

Also, this community is coming along nicely. We are in the top tree communities on programming.dev if you look at the list of communities. We are the highest ranked programming language community, ahead of Python. So, I don't see any need for artificially inflating this community.

Edit: Link to the community page https://programming.dev/communities

[–] [email protected] 13 points 2 years ago (4 children)

No, just look at the rust community on Lemmy that imports stuff like this. It is flooded with a lot of content, but that makes it impossible to follow and interact with. Also, if you know it is a bot that posted, you don't have any reason to interact with that post. Automatic imports tend to feel like spam, so please don't do this....

I'd rather see that people keep an eye open for suitable news, or ask genuine questions and write other interesting posts by hand. It may be a bit slow early on like it is now, but that is somewhat in proportion to the engagement so it all fits together.

[–] [email protected] 9 points 2 years ago

When you compare "idea to deployment" speed, a dynamic language will always win. However, much of this win is due to a dynamic language will let you deploy with a lot of bugs. So, you will then have to spend lot of time fixing production issues. Rust will force you to fix most of these issues before you can deploy, hence it feels slower in this aspect. I previously worked for 10 years with a huge perl code base, and I trade the deployment speed for stability in production any time.

view more: ‹ prev next ›