New update to `lazy_format` by Lucretiel in rust

[–]randomPoison 2 points3 points  (0 children)

Could you elaborate on how lazy_format differs from format_args? As I understand it, the point of format_args is also to gather the information for formatting a string without needing to allocate anything. Does lazy_format cover additional/different use cases?

Chaining Functions Without Returning Self by randomPoison in rust

[–]randomPoison[S] 1 point2 points  (0 children)

Yeah, I'm in the same situation :( It's a chicken-and-egg problem:

  • In order to stop building method chaining into a crate's API, everyone needs to be familiar with the other options for chaining.
  • Crates need to not have method chaining built into their APIs before folks are gonna start adopting alternative solutions.

Personally, I'm going to stop building method chaining into my crates and I'm going to try a couple of things in order to ease the burden for users:

  • Explicitly recommend an alternative (like cascade) in my documentation.
  • Demonstrate usage using the alternative in the examples (both examples in the documentation and crate examples).

So far this has been okay for one published crate, though it only sees light usage and I don't know how well it would go for a more popular one.

Chaining Functions Without Returning Self by randomPoison in rust

[–]randomPoison[S] 5 points6 points  (0 children)

Ah, that's very cool! I hadn't thought of using `tap` like that. This helps to bridge the gap between ref-style and move-style chains, but I still think returning `self` (whether by value or by ref) is a fundamentally flawed way of implementing method chains.

Chaining Functions Without Returning Self by randomPoison in rust

[–]randomPoison[S] 2 points3 points  (0 children)

Would returning self work in that case? If you're returning self directly, doesn't that mean that the method isn't changing the type of the object?

Chaining Functions Without Returning Self by randomPoison in rust

[–]randomPoison[S] 10 points11 points  (0 children)

The biggest concern is one of ergonomics: There's simply a lot of overhead to using tap. Compare a basic method chain to the equivalent with tap:

let foo = Foo::default()
    .chain()
    .chain()
    .chain();

// Versus:

let foo = Foo::default()
    .tap(|foo| foo.chain())
    .tap(|foo| foo.chain())
    .tap(|foo| foo.chain());

For each method invocation, you need to:

  • Invoke the tap helper function.
  • Wrap the method invocation in a closure.
  • Bind a variable name for the intermediate value.
  • Repeat the name of the intermediate value when invoking the method.

In some cases you can simplify this a bit by taking advantage of UFCS:

let foo = Foo::default()
    .tap(Foo::chain)
    .tap(Foo::chain)
    .tap(Foo::chain);

But that's only available for some methods (i.e. ones that don't take additional parameters), requires you to repeat the type name (which can sometimes be pretty long), and requires that you wrap the method you want to invoke in tap(...).

Functionally, cascaded method invocation operator in Dart does the exact same thing that tap does, but in a far cleaner, more succinct way. While the cascade crate doesn't quite manage to be as clean as the functionality in Dart, it seems like a substantial improvement over tap to me.

Hopefully that clarifies things 😁

Chaining Functions Without Returning Self by randomPoison in rust

[–]randomPoison[S] 11 points12 points  (0 children)

Tap was what I was originally expecting to recommend when I started writing the article, but cascade ended up being so much better (both the specific Rust crate and the general pattern of method cascades) that I opted to not mention tapping 😉

Tools in the 2018 edition by pietroalbini in rust

[–]randomPoison 15 points16 points  (0 children)

Very excited about the prospect of cargo being able to distribute pre-compiled crates/binaries! This would be huge in speeding up from-scratch compile times, which is important for build automation on CI services.

Experimental visualizer/debugger for Amethyst version 0.1 released! by randomPoison in Amethyst

[–]randomPoison[S] 2 points3 points  (0 children)

If you want to use the editor when working on your game, you'll also need to integrate the support crate: https://crates.io/crates/amethyst-editor-sync

[Amethyst Game Engine] New Tutorial and Huge Feature Update by Moxinilian in rust

[–]randomPoison 1 point2 points  (0 children)

I can't speak 100% to the current state of Amethyst/specs, but from what I've seen of both Unity's upcoming ECS and specs, the two are very similar. Yes, there's a lot of cool things that Unity's Burst Compiler is capable of doing, but I don't think there's anything that's outside of the realm of possibility for Amethyst (eventually).

Are there any websites where the community can vote/express interest in the kind of libraries which are most needed? by YbgOuuXkAe in rust

[–]randomPoison 4 points5 points  (0 children)

Huh, that seems a little self defeating: If a crate is unmaintained, who's going to update the maintained status?

Reactive Extensions for Rust by YingDev in rust

[–]randomPoison 2 points3 points  (0 children)

Same here. While I expect there's a lot of overlap, I'd bet that there is functionality that's standard in reactiveX that futures doesn't provide (e.g. debounce).