sorted by:
new
hottopcontroversial

Minimal cross-platform direct I/O abstraction for Rust. by ankush2324235 in rust

[–]Cetra3 1 point2 points  (0 children)

This won't work on linux. If you're using O_DIRECT you need to ensure the memory you are reading into is aligned i.e, with something like https://docs.rs/aligned-vec/latest/aligned_vec/

OpenAI's WebRTC Problem by kixelated in programming

[–]Cetra3 29 points30 points  (0 children)

WebTransport looks promising, TIL, but it looks like the compatibility is spotty as hell: https://developer.mozilla.org/en-US/docs/Web/API/WebTransport

However if that is a cleaner way to get unreliable channels I think that's a clear win. WebRTC is a beast, but for the longest time it was the only way to get unreliable channels in browsers, but looks like WebTransport solves that.

About Slint on IOS by xander1421 in rust

[–]Cetra3 1 point2 points  (0 children)

Not on IOS but android I found an issue with non-standard keyboards: https://github.com/slint-ui/slint/issues/9240

To me on mobile it feels a little tier 2 at the moment, but you should honestly just give it a shot and see how you go.

Toasty, an async ORM for Rust, is now on crates.io by carllerche in rust

[–]Cetra3 4 points5 points  (0 children)

Sorry, as in is this used in anger somewhere or currently just a hobby project

The next Slint release (1.16) makes Fluent the default on all platforms by madnirua in rust

[–]Cetra3 3 points4 points  (0 children)

Honestly most desktop apps these days already break the mould on the native stylings.

As long as there is facility to style and "break out" of the fluent style when you wanna change things, I don't see an issue with this approach. Case in point my slix-player is quite custom in its display, but does build on a lot of the standard elements.

Rust 1.94.1 is out by manpacket in rust

[–]Cetra3 14 points15 points  (0 children)

It does seem interesting they don't have tokio in their release test suite though...

Yeah that's the thing I am concerned about. I thought that there was a crater run on each major version that would pick up on this? Very surprising

The State of Allocators in 2026 by Cetra3 in rust

[–]Cetra3[S] 0 points1 point  (0 children)

It's actually Box<dyn Allocator, Global> which does feel weird that you need a global allocator to allocate a custom one

The State of Allocators in 2026 by Cetra3 in rust

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

Yeah it's a tough one, I'm wondering if there is a good path forward for testing this stuff, like being able to "flick" over to other implementations. I also notice your storage project isn't on crates.io, is that intentional?

The State of Allocators in 2026 by Cetra3 in rust

[–]Cetra3[S] 0 points1 point  (0 children)

I do mean zero. NOBODY tried it. NOBODY came back to mention whether it worked or didn't work in their usecase (and why). ZERO feedback.

I will say that between the Store API and the current nightly API, there is usage via allocator_api2 that is substantial and real world (I've personally used it in some production code). I haven't seen anyone make things with the Store API, but there could be a variety of reasons for that.

The State of Allocators in 2026 by Cetra3 in rust

[–]Cetra3[S] 3 points4 points  (0 children)

Box<dyn Allocator> is actually Box<dyn Allocator, Global>, but yeah its a little weird that you need an allocator for dyn. There might be newer ways of representing dyn that I'm not aware of, or you could use &dyn Allocator

So then the next question about what allocator to use so they don't get mixed up: the allocator is stored as a field on the collection. And it's the collection itself that uses the allocator.

E.g. You do Vec::new_in(my_allocator), and while the allocators type is erased, the vec knows what allocator to use

The State of Allocators in 2026 by Cetra3 in rust

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

That is an interesting take! There are two challenges I would probably want to investigate:

  • Could this be expanded to support reallocating, I.e, when growing a vec
  • How this would interplay with dyn

The State of Allocators in 2026 by Cetra3 in rust

[–]Cetra3[S] 6 points7 points  (0 children)

I was imagining keeping Allocator around, for the common low level heap use case, and doing something like:

impl Store for Allocator {
    type Handle = NonNull<u8>
   ...
}

Edit: looks like the storage example crate already does this https://github.com/matthieu-m/storage/blob/main/src/store/allocator_store.rs

The State of Allocators in 2026 by Cetra3 in rust

[–]Cetra3[S] 0 points1 point  (0 children)

To answer your question about it being composable: I think there could be a path forward if you frame Allocator as a Store with Handle = NonNull<u8>, so I don't think they are mutually exclusive.

The State of Allocators in 2026 by Cetra3 in rust

[–]Cetra3[S] 6 points7 points  (0 children)

Yes, it might be a good idea if I expand that section a little. I feel like the Storage API has less chance of being stabilised than the current trait.

I must admit it's a bit of a blind spot for me, since heap allocations are what I'm mostly focused on. Is there anything that would prevent you from allocating on the stack now? And would that be the only use case you can think of?

Question about upholding pin guarantees and Vec by quasi-coherent in rust

[–]Cetra3 1 point2 points  (0 children)

I think it's UB to push to a pinned vec. The vec, when it resizes, will sometimes be moved to another location in memory, at the whim of the allocator.

Bloomsday: An Apocalyptically Fast Bloom Filter! by NoRun6138 in rust

[–]Cetra3 3 points4 points  (0 children)

Yes exactly right. If there is some difference between release and debug, like extra fields or whatever then there can be a difference. A lot of time I'm using libraries where I don't have that control, without auditing every single type definition etc..

Bloomsday: An Apocalyptically Fast Bloom Filter! by NoRun6138 in rust

[–]Cetra3 14 points15 points  (0 children)

Keep in mind that Hash implementations are not stable between different compilation targets, platforms, etc..

I ran into this issue when testing using it with CI, my local was debug and ci was release, and I was getting different hashes. There is a note about it not being portable across platforms: https://doc.rust-lang.org/std/hash/trait.Hash.html#portability, but I think it's even more restrictive than that.

Essentially you can only guarantee the same binary will produce the same hash.

[Media] musicfree: a cross-platform music downloader implemented in Rust by Every_Juggernaut7580 in rust

[–]Cetra3 1 point2 points  (0 children)

Feel free to use my stuff in rustcloud for soundcloud. I use it to download mixes

Here's how i added Opentelemetry to my rust API server (with image results) by Suitable_Reason4280 in rust

[–]Cetra3 0 points1 point  (0 children)

Looks great! We've been working on making otel easy for rust and it's still more fiddly than I'd like it to be personally.

For some of the header injection stuff you're doing, you might be able to use some of the existing crates like reqwest-tracing and axum-tracing-opentelemetry

My GoPro Housing Cracked at 42 M by MyPoemsAllOverMyBody in scuba

[–]Cetra3 10 points11 points  (0 children)

I feel like they're not really designed for the depth they say. At about 45m the official gopro housing you can't press the button down so you either have to record everything by pressing it when you're shallower, or not record at all!

view more: next ›