Rust-playground Alternatives

rust-playground reviews and mentions

• Lock-Free Rust: How to Build a Rollercoaster While It's on Fire
  2 projects | news.ycombinator.com | 16 May 2025

  Yes the code for the alternative is awful. However I tried rewriting it with a better alternative (basically the same as the lock free code, but with a mutex around it) and was still 40% slower. See https://play.rust-lang.org/?version=stable&mode=release&edit...

• Matt Godbolt sold me on Rust (by showing me C++)
  14 projects | news.ycombinator.com | 6 May 2025

  Explicit allocators do work with Rust, as evidenced by them already working for libstd's types, as I said. The mistake was to not have them from day one which has caused most code to assume GlobalAlloc.

  As long as the type is generic on the allocator, the lifetimes of the allocator don't appear in the type. So eg if your allocator is using a stack array in main then your allocator happens to be backed by `&'a [MaybeUninit]`, but things like Vec instantiated with A = YourAllocator<'a> don't need to be concerned with 'a themselves.

  Eg: https://play.rust-lang.org/?version=nightly&mode=debug&editi... do_something_with doesn't need to have any lifetimes from the allocator.

• Understanding Memory Management, Part 5: Fighting with Rust
  1 project | news.ycombinator.com | 6 May 2025

  > Strictly speaking, Rust doesn't support overloaded functions. Function overloading is when you define the same function but with different arguments, and the language selects the correct one based on the argument type. In this case, it's two different implementations of a trait for two different types.

  You're right that there is no function overload in this article, just some implicit derefs.

  I would argue however that Rust has overloaded functions (function resolution based on argument types) due to how it handles trait resolution. Rust may not have syntax sugar to easily define overloads and people generally try to avoid them, but using argument-based dispatch is extremely common. The most famous example is probably `MyType::from(...)`, but any single-method generic trait using the generics for the method arguments is equivalent to function overloading. There are also other techniques. Using nightly features you can get far enough so a consumer can use native function call syntax.

  Overload in nightly: https://play.rust-lang.org/?version=nightly&mode=debug&editi...

  Overload on stable: https://play.rust-lang.org/?version=stable&mode=debug&editio...

  The mechanism and syntax may be different from overloading in C++ or Java, but as a user the result is the same and it causes the same pain points.

• From Gophers to Crustaceans 🦫➡️🦀
  2 projects | dev.to | 3 May 2025

  Some code snippets below will not run on their own, so you can copy them to the main function in the Go Playground or the Rust Playground and run to see the output.

• Pretty State Machine Patterns in Rust
  4 projects | news.ycombinator.com | 19 Apr 2025

  I prefer giving the transitions explicit names over relying on the From implemenations defined on the machine (defining them on the states still prevents bad transitions). The raft example drops a bunch of syntactic noise and repetition this way:

  https://play.rust-lang.org/?version=stable&mode=debug&editio...

      fn main() {

• A surprising enum size optimization in the Rust compiler
  3 projects | news.ycombinator.com | 10 Apr 2025

  I think that's just peephole optimization. If you change from bool to a u8 it doesn't use the invalid bit pattern as a discriminant even though it could: https://play.rust-lang.org/?version=stable&mode=debug&editio...

• Rust Any part 3: we have upcasts
  4 projects | news.ycombinator.com | 30 Mar 2025

  the article isn't very good for anyone not already familiar with the problem

  > What I'd like to do is have some base trait object and query it to see if it supports other interfaces

  > rust doesn't have inheritance

  rust traits and lifetimes have inheritance, kinda, (through rust types do not)

  E.g. `trait A: Debug + Any` means anything implementing A also implements Debug and Any. This is a form of interference, but different to C++ inheritance.

  This is why we speaking about upcasts when casting `&dyn A as &dyn Debug` and downcast when trying to turn a `&dyn A` into a specific type.

  But because this inheritance only is about traits and the only runtime type identifying information rust has is the `Any::type_id()` the only dynamic cast related querying you can do is downcasting. (Upcasting is static and possible due to changes to the vtable which allow you to turn a `&dyn A` vtable into a `dyn Any`/`dyn Debug` vtable (in the example below).

  The part of bout downcast form the article you can ignore, it's some nice convenient thing implicitly enabled by the upcasting feature due to how `downcast_ref` works.

  This https://play.rust-lang.org/?version=beta&mode=debug&edition=... might help.

  So I think what you want might not be supported. It also is very hard to make it work in rust as you would conceptually need a metadata table for each type with pointer to a `dyn` vtable for each object safe trait the type implements and then

• Towards fearless SIMD, 7 years later
  5 projects | news.ycombinator.com | 30 Mar 2025

  10.99 ± 0.39 times faster than target/release/testit

  [1]: https://play.rust-lang.org/?version=stable&mode=debug&editio... (I'm just using the rust playground as a pastebin; the actual benchmarks were run locally)

• How to Get Started with Rust Programming
  3 projects | dev.to | 16 Mar 2025

  Rust Playground - Try Rust code in your browser

• The magical applications of zero-sized types in Rust
  1 project | news.ycombinator.com | 14 Mar 2025

  It's nice seeing people mess around with compile-time index types. I've played around with checked array indices using some tricks (https://play.rust-lang.org/?version=stable&mode=debug&editio...), but checked slice indices obviously require a lot more work.

  One application I once thought about is "safe pointers". Suppose we have a bunch of pointers into a buffer, and we want to manipulate them without passing around the original buffer everywhere. The idea would be to use marker types or lifetimes to link the pointers to the original buffer at compile time, so we can use proof values to manipulate them safely.

  Of course, the devil's in the details with these sorts of ideas, so I never got very far. It's great to see an actual implementation of a closely related idea.

• A note from our sponsor - InfluxDB
  www.influxdata.com | 12 Jun 2025

  InfluxDB 3 OSS is now GA. Transform, enrich, and act on time series data directly in the database. Automate critical tasks and eliminate the need to move data externally. Download now. Learn more →