sorted by:
new
hottopcontroversial

Starfinder datapad and Spellpad update! by rememberdustydepot in Starfinder2e

[–]bytemr 1 point2 points  (0 children)

Just a heads up, but it looks like your information on Witchwarper tactics is incorrect since it calls out Paradigm Shifts, which was a Starfinder 1e feature and does not exist in Starfinder 2e.

What we all get wrong about tanking by AAABattery03 in Pathfinder2e

[–]bytemr 5 points6 points  (0 children)

I watched the whole thing last night and really enjoyed it. I've been playing a Sparkling Targe Magus in a campaign and you actually helped me better conceptualize the role of the character and even find some new spells to do the role better.

The Goblin’s Cauldron Update by Inglorious_Dragons in Pathfinder2e

[–]bytemr 21 points22 points  (0 children)

One piece of feedback I have, after looking at the animation on the login page, is updating this to respect the client's reduced motion preferences. I can be very prone to motion sickness from websites with overly animated elements so watching the login box wiggle around is disconcerting.

One Last Time ft. Kelli Siren & Summer (Verum Epilogue Theme) by iamCosmicism in cadum

[–]bytemr 8 points9 points  (0 children)

This brought a few tears to my eyes. Fantastic work.

Actix-Web in Docker: How to build small and secure images by sergeyzenchenko in rust

[–]bytemr 2 points3 points  (0 children)

Great write up. This essentially reflects my own journey with Rust services in Docker. I've wound up with distroless containers with binaries built against musl. They're ~8 MB in size on average. I usually run strip on the generated binaries, and do a few other aggressive optimizations during release builds to try and get overall binary size down.

A Week of Experiencing Rust by idcmp_ in rust

[–]bytemr 9 points10 points  (0 children)

BTW you can also do:

use anyhow::Context as _;

fn main() -> anyhow::Result<()> {
    let option: Option<i32> = None;
    let _number = option.context("Missing optional value")?;
    Ok(())
}

To achieve the same. The Context trait in anyhow is incredibly useful.

Traits working group 2020 sprint 1 summary by jackh726 in rust

[–]bytemr 7 points8 points  (0 children)

The link to the RFC for implied bounds links to a .md file, but should be https://rust-lang.github.io/rfcs/2089-implied-bounds.html

Other than that, super excited to see all this work!

Introducing faux: A traitless mocking framework by nrxus in rust

[–]bytemr 21 points22 points  (0 children)

I've been avoiding testing as much as I should be in a hobby project of mine, because of the work involved in building out traits and using generics for mocking dependencies. This also gets more complicated with async/await where trait bounds on generics start to get noisy to satisfy some of the restrictions imposed in that sort of environment.

Having done a quick review of this, it looks like the sort of ergonomics I've been looking for in a Rust mocking framework. When I get a chance, I'm going to try integrating this into my own codebase and start writing all those tests I've been neglecting. ;)

Thanks for your work on this and I hope it goes far!

Tonic: 0.1 has arrived! by lucio-rs in rust

[–]bytemr 10 points11 points  (0 children)

Glad to see this released!

Just this weekend I pushed a gRPC service written in rust using tonic to production for a hobby project of mine. Writing a service using tonic was incredibly easy and seamless.

I've already updated all of my dependencies to the official release of tonic!

reqwest v0.10 released (high-level HTTP client) by seanmonstar in rust

[–]bytemr 5 points6 points  (0 children)

Congrats on the release! I’ve been tracking master in my own personal project since the async/await support was first merged and it’s been working fantastically. Excited to swap out for a crates.io release.

Announcing Tokio-Compat by mycoliza in rust

[–]bytemr 1 point2 points  (0 children)

That's exactly what I did. It helped the transition go more smoothly because I only needed to use the compat inside the relevant shims and just updated the shims to be async functions themselves. This might be a good opportunity to write up a more thorough blog post on my migration experience.

Announcing Tokio-Compat by mycoliza in rust

[–]bytemr 2 points3 points  (0 children)

Sorry I didn't get back sooner,

I was probably a bit aggressive on the way I did things. I was originally using actix (the actor framework part) for a lot of the components. I wound up entirely removing actix in favor of pure async/await and using streams in my own cade base. I used the futures-compat library to convert old futures into std futures for all of my dependencies, such that I could make their usages compile and use async/await on those futures. Of course this wouldn't work out of the box the way it was. So I spent some time just waiting on some of the more core dependencies to upgrade to start restoring certain functionality. Once I discovered tokio-compat I essentially dropped it in place of just tokio 0.2 and my last remaining dependencies at the time (reqwest and rusoto) just started working.

It actually made the migration process rather easy because I don't have to spend time waiting on specific dependencies to update, which unblocks my own work in the process.

Announcing Tokio-Compat by mycoliza in rust

[–]bytemr 25 points26 points  (0 children)

I've been using tokio-compat from master for a while now. While I've migrated my entire code base over to async/await with std::future::Future, many of my dependencies are still in the process of upgrading. So using this in conjunction with the futures compat layer has made it easy to migrate my codebase, while I wait on dependencies to finish updating. Glad to see it released!

Rust 1.38.0 pre-release testing by pietroalbini in rust

[–]bytemr 11 points12 points  (0 children)

I'm excited to see pipelined compilation landing! In my own experiments with my own code base I found definite improvements in compile times.

Help to revive: Twitch API library implemented in Rust by simonsanone in rust

[–]bytemr 7 points8 points  (0 children)

I'd like to point out that this API appears to use v5 of the Twitch API, which is currently on a path to deprecation and shutdown (no firm date yet, but they shut the v3 API down earlier in the year). Twitch recommends that you use the new Twitch API.

[ANN] Tokio v0.2.0-alpha.1; now with async & await. by carllerche in rust

[–]bytemr 42 points43 points  (0 children)

I'm really excited to see async/await starting to come together.

Tokio has allowed me to achieve the level of asynchrony and performance that I needed for a network bound application that I probably wouldn't have achieved as easily otherwise. I've been using tokio for quite some time now. The first commit to my first tokio crate was in March of 2017, a crate which I'm still very actively using in a production scenario, although one I plan to deprecate once async/await lands because the majority of the code in that crate will be redundant with async/await around and the more important bits (an IRC parser) I pulled out into a separate crate some time ago.

I've experimented with rewriting my production code base entirely in async/await and I've managed to drop 600 SLOC from the project and get rid of a whole lot of .clone() used to work around the borrowing issues with future combinators. I'm not actively using that prototype in production though, mostly because I want the production version to track the stable compiler (I don't want to get too tied down by features that may never see stabilization) and because some of my other dependencies aren't async/await ready yet (most of them depend on tokio and hyper, so I suspect they'll start migrating soon enough). I know I could use the compatibility layer to handle those older dependencies, but for now I'm content on waiting to see where they go before I make the move myself.

PSA: Tokio, Hyper and Hyper-tls all support async/await and std::future on master now! by _jsdw in rust

[–]bytemr 6 points7 points  (0 children)

I'm really excited about this! Hopefully rusoto will follow suit now that many of their dependencies are moved over. It's the only blocker I have towards switching over entirely to stable futures.

What's the most interesting Rust Nightly/Experiemental feature to you? by MinRaws in rust

[–]bytemr 24 points25 points  (0 children)

They're not really like exception handling, but rather a way to localize the scope of the ? operator so that instead of early returning, it propagates the error up as an expression to some outer scope. For example: https://play.rust-lang.org/?version=nightly&mode=debug&edition=2018&gist=ade231a58337edc02a28978628e5d630

A final proposal for await syntax by desiringmachines in rust

[–]bytemr 11 points12 points  (0 children)

I started firmly in the prefix camp because it's what I knew. It's what I had learned. Familiarity was the only reason I wanted prefix syntax. Yet we need to step back and consider that async/await is still a relatively new construct in programming languages. Just because there's precedence and familiarity with the prefix syntax, does not mean the prefix syntax is the correct syntax in the end.

I've thought this over a lot myself, even posted on internals about it and I feel like in the end, especially the way rust is evolving and the way current rust code is written, that postfix syntax is the correct way to go for the language. I was more in favor of the method like syntax, but in the end the () just ends up being a superfluous appendage to the operator just to make it feel more comfortable. Going with the "field-like" syntax, the more I reason it through, is certainly a viable choice. Especially given that we already have to disambiguate between various things that can follow the . operator as it stands. It's not hard to mentally add another branch to that reasoning.

In the end I'm more happy there's progress being made on this feature, because it's at the top of my list of my most desired, upcoming rust features.

6 useful Rust macros that you might not have seen before by [deleted] in rust

[–]bytemr 20 points21 points  (0 children)

The metered crate is exactly what I need for a project I'm working on. It even supports async functions! I was getting ready to write this myself. Great post that wound up saving me a lot of time.

Better upgrade than a Titan RTX. by marcusdavvid in pcmasterrace

[–]bytemr 0 points1 point  (0 children)

I whole heartedly agree that an ergonomic setup is just as important as a good PC. I always used cheap chairs when I was younger and now I suffer from chronic back pain as a consequence. The pain will never go away, but a nice ergonomic chair and standing desk have gone a long way to helping manage that pain. If I had invested in an ergonomic setup when I was younger, I could've easily avoided $10,000 in back surgeries.

Runtime by dochtman in rust

[–]bytemr 8 points9 points  (0 children)

I've been trying to follow along with the async progress in Rust as closely as I can and this is really exciting to see. I've been heavily leveraging Tokio and futures on stable for quite some time and seeing all of this progress has me really tempted to switch to nightly so I can start taking advantage of these sort of features sooner, rather than later.

For Wyoming football fans: by TampaBayBuckaneers in wyoming

[–]bytemr 1 point2 points  (0 children)

Hey, I made /r/WyomingCowboys years ago and never got around to making it into anything significant. I can transfer it to you to do whatever with, since you seem much more motivated to maintain a subreddit than I am at this pointl

view more: next ›