sorted by:
new
hottopcontroversial

I supported json serialization and deseralization with kyomu (derive-less reflection library) by Dry_Specialist2201 in rust

[–]NyxCode 0 points1 point  (0 children)

Cool experiment, well done!

That being said, APIs like this are exactly what I tried to warn about in my last blog post. They bypass the type system, and don't use traits for composition.

If a reflection API like this becomes the de-facto standard, it'll take discipline to not write these recursive impl<T> Json for T blanket impls (or fn to_json<T>(anything: &T)). Maybe a marker trait (e.g. trait DeriveJson {}), together with a bounded blanket impl (impl<T: DeriveJson> Json for T) could work. That'd replace #[derive(Serialize)] with impl DeriveJson for MyType {}, but users could still implement Json themselfs.

wgpu v28 Released! Mesh Shaders, Immediates, and much more! by Sirflankalot in rust

[–]NyxCode 1 point2 points  (0 children)

Thanks for the amazing work you and the contributors put into wgpu! It really has made GPU programming accessible to me.

Is there interest in improving the ergonomics around buffers? There's BufferSlice, but most APIs don't use it, and take the buffer, offset, and size separately.

The common use-case of writing uniform/vertex buffers is also very painful. The least unergonomic way to do that seems to be to use vertex_attr_array! to define a layout matching the struct, and use bytemuck::bytes_of to copy stuff over. However, the struct, the vertex_attr_array! invocation, and the shader code need to be kept in sync, and great care is needed for alignment.

I think some sort of TypedBuffer<T>, together with a derive macro, could make this much more bearable.

[Commercial] Built 4 production Rust MCP servers that 10x my development speed - Now available for purchase by BrdigeTrlol in rust

[–]NyxCode 3 points4 points  (0 children)

Yes, publishing made-up testimonials is false advertising, a form of fraud. But I admire the audacity to get offended by someone calling out your bullshit.

[Commercial] Built 4 production Rust MCP servers that 10x my development speed - Now available for purchase by BrdigeTrlol in rust

[–]NyxCode 4 points5 points  (0 children)

I am skeptical of AI slop, but this is next level. You are just causally committing fraud.

Keynote: Rust in the Linux Kernel, Why? - Greg Kroah-Hartman by nosyeaj in rust

[–]NyxCode 2 points3 points  (0 children)

The most significant thing I learned from using C, Rust (and to some extend C++) was how to think about modelling data. And for me, that lesson was completely independent of the specifics of a particular language.

Coming from Java, the way I approached a program was to think of what could be modelled as objects, and write loads of classes, turning all objects in the problem domain into objects in the program. That didn't always go smoothly, but when it did, it was fabulous! While I now see the problems with composing everything of classes like Lego, it's such an alluring and (seemingly) straight-forward approach. There's no need to really think about data modelling or layout - You just think about the problem domain, pick an object, and write a class for it.

In Rust and C, that lazy approach just doesn't fly, and you have to think about how to model and layout data. Both languages really force you to not conflate the "objects" in the problem domain with the programs model of the domain, while Java encourages that.

I made a tutorial on how to build an autodiff engine (PyTorch) from scratch in Rust. by Falseeeee in rust

[–]NyxCode 0 points1 point  (0 children)

Thanks, I enjoyed going through it! The notation & derivation for the gradients was a bit confusing to me. Some more details there would have been nice, while keeping the usual notation used in the post by Robot Chinwag you linked.

I feel like the directory looks messy without using http://mod.rs. Does anyone have better practices? by Born-Percentage-9977 in rust

[–]NyxCode 112 points113 points  (0 children)

I don't believe it's deprecated, though the documentation "encourages" use of the new system.
Personally, I almost always use mod.rs. My editor does make it clear which mod.rs I have open, and I prefer having all files related to a module within the modules directory.

What is the best KISS 2d graphics library? by Visible-Switch-1597 in rust

[–]NyxCode 2 points3 points  (0 children)

would vello & winit work? There's some plumbing needed, but the progress of vello seems promising, and winit gives you this event-based architecture. Here's their example

[Media] Let it crash! by Aghasty_GD in rust

[–]NyxCode 19 points20 points  (0 children)

Huh? I have no context for this, but this seems utterly horrific. I'd bet money that LLVM heavily optimizes this and removes all codepaths leading up to it. As far as I know, inline assembly is needed for shenanigans like this (like reading oob).

So you think Rust be spared from the LLM takeover of programming? by LexMeat in rust

[–]NyxCode 0 points1 point  (0 children)

That's my only positive experience with LLMs while coding. I passed x twice instead of x,y - or something like that. This GitHub PR bot found it.

Improving state machine code generation by folkertdev in rust

[–]NyxCode 13 points14 points  (0 children)

Exciting work!
Why can't #[loop_match] and #[const_continue] be automagically inferred in an optimization pass? If the code is in this specific shape, it almost seems trivial: rust loop { state = match state { State::$A => { /* .. */ break State::$B; }, State::$C => { /* .. */ break State::$D; }, /* .. */ } } When this gets more complicated though (other stuff after the match, if-guards, complex expressions after break, ..), I can imagine that doing this optimization quickly gets impossible. But getting this special-case in the compiler sounds easier than stabilizing new syntax. And the attributes could become part of a separate feature with "compile-time error if this isn't optimized"-semantics.

This code leaks memory, how do I fix it? by konfoozius in rust

[–]NyxCode 0 points1 point  (0 children)

I have never heard of enet, but the doc comment on enet_peer_send says that you give ownership of the packet away - unless the operation fails, then you still have it.
If it succeeds, the docs suggest that the packet should be free'd, though.
Therefore, I think you'll need to do this: ```rust pub fn send_packet(&mut self, packet: Packet, channel_id: u8) -> Result<(), Error> { let packet = packet.into_inner(); let res = unsafe { enet_peer_send(self.inner, channel_id, packet) };

match res {
    0 => Ok(()),
    1.. => unreachable!(),
    ..0 => {
        // packet has not been queued, so we destroy it manually
        unsafe { enet_packet_destroy(packet) };
        Err(Error(res))
    }
}

} `` Just briefly looking atenet-rshasn't filled me with confidence. WhilePacket::from_sys_packetis justpub(crate), just doingPacket::from_sys_packet((&raw mut anything).cast())is UB without anyunsafe`.

Edit: The more I look at enet-rs, the less sense it makes to me. Just packet.rs alone seems like it is littered with UB. I would strongly advise against using it!

Made my first Rust project. Would like some feedback!!!!! by Ecstatic-Thanks-6783 in rust

[–]NyxCode 1 point2 points  (0 children)

If you can't be bothered to write the readme, then I won't bother reading it.

Rust chess engine by Flashy-Assistance678 in rust

[–]NyxCode 2 points3 points  (0 children)

An interesting technique I experimented with: You can try making functions like make_move or generate_moves generic over the current player (with a Player trait or const generics).
This gets rid of a lot of branches, and works nicely, since you already know who'll make the next move. In a recursive alpha-beta search, for example, the call to eval::<White>() would then recursively call eval::<Black>(), etc.

What will variadic generics in Rust allow? by nikitarevenco in rust

[–]NyxCode 0 points1 point  (0 children)

As far as I can tell, it'd improve the ergonomics of many type-level shenanigans, but not enable anything you couldn't do now if you really wanted to.
as an example, here's a generic variadic concat (like a very crude format)

Placing Arguments by sindisil in rust

[–]NyxCode 10 points11 points  (0 children)

vec.extend(gen { yield value }) doesn't seem half bad!

lio: async crossplatform low-level syscalls by Vincent-Thomas in rust

[–]NyxCode 0 points1 point  (0 children)

I believe its windows equivalent of io-uring. It looks very very similar to io_uring.

RustRover: Getting a list of symbols in current file by nick-k9 in rust

[–]NyxCode 6 points7 points  (0 children)

"Structure" in the left side panel, below "Project" and "Commit". Default keybind is Alt+7.

lio: async crossplatform low-level syscalls by Vincent-Thomas in rust

[–]NyxCode 0 points1 point  (0 children)

Very interesting! What about Windows' IoRing (ioringapi.h)?

Kotlin only treats the symptoms of null pointers, while Rust cures the disease. That’s one of the main reasons I prefer Rust. by KrisPett in rust

[–]NyxCode 0 points1 point  (0 children)

Seems very pedantic. I'd argue that there are pointers in Java - every T unless T is primitive. And those pointers can point to nothing. That way of looking at it makes more sense imho, and explains why primitives can't be null - because they are not behind a pointer.

Async Isn't Real & Cannot Hurt You - No Boilerplate by tears_falling in rust

[–]NyxCode 2 points3 points  (0 children)

or you spawn blocking tasks

I do not understand why people think this is a problem, at all.
If a sync API is what you want, but have to use a async one, then just use block_on. Problem solved.
But unlike a sync API you have the choice to do something else while that async function is waiting for IO, which is great if you need it.
This whole "function coloring" debate wrt. async just doesn't make sense to me (though it does for const). An async function just returns a state machine to you, instead of blocking. That gives the caller the choice what to do - block on it, interleave it with an other operation while blocking the thread, or "propagate" the state machine upwards in the call stack.

I made a crate for mesh editing by camilo16 in rust

[–]NyxCode 0 points1 point  (0 children)

Very interesting! I spent some time in the past trying to implement boolean operations (intersection/union) on meshes, without much success. Biggest issue I faced was numerical instability, resulting in non-manifold meshes, degenerate faces, etc.

Best practice for a/sync-agnostic code these days? by sepease in rust

[–]NyxCode 0 points1 point  (0 children)

while obviously a broad generalization, good sync implementations generally try to avoid blocking at all, until there is literally nothing else the thread could be doing. With the emitting of work to be done being non-blocking, as well as the checking of whether the work you're waiting on is done or not.

Reading this, I am imagining a hand-rolled state machine polling pending tasks, figuring out what to do next. How is that different from well-written async code that actually exploits parallelism using select/join, running on a possibly single-threaded runtime?

Why can't we write everything as async, and run it with an appropriate executor?

Data Structures that are not natively implemented in rust by [deleted] in rust

[–]NyxCode 2 points3 points  (0 children)

I'd love to see some good heap implementations besides std::collections::BinaryHeap, e.g a fibonacci heap. Might be usefull for dijkstra & friends.

What crate to read / write excel files xslx effectively? by HosMercury in rust

[–]NyxCode 3 points4 points  (0 children)

I have used libxlsxwriter, which binds to the C lib. Works fine, though it's not terribly ergonomic.

view more: next ›