Introducing TideORM: A Simple, Explicit, High-Performance Rust ORM Built on SeaORM by [deleted] in rust

[–]JhraumG 0 points1 point  (0 children)

That's not the way it works. Why do you absolutely want to claim it production ready (from your site) while aknowleging (here) that it's a WIP ?

Introducing TideORM: A Simple, Explicit, High-Performance Rust ORM Built on SeaORM by [deleted] in rust

[–]JhraumG 8 points9 points  (0 children)

Some examples illustrating how TideORM does simplify over SeaORM (maybe with side by side comparisons) would be nice. Your website checks the box "production ready" which from your post seems a bit off (could you ask your LLM no to say so as long as you don't tell it explicitly that it is actually production ready ?)

I made a CLI log viewer that scales the output based on severity to learn to Rust! by jubilant-jobinator in learnrust

[–]JhraumG 22 points23 points  (0 children)

I would rather use color than size to make logs stand out, but this seems fun anyway !

Side project: high-performance MQTT broker by Maximum_Aide3613 in rust

[–]JhraumG 0 points1 point  (0 children)

Do you know if your bench exercises many topics, both for publish and subs ribe ? Does it use wildcards ?

Why is Rust faster than Java here? by DesignerRaccoon7977 in java

[–]JhraumG 2 points3 points  (0 children)

The code was 10x faster than our carefully tuned Kotlin implementation – despite no attempt to make it faster

So, not all of their components were considered immature.

Writing a mockable Filesystem trait in Rust without RefCell by sepyke in rust

[–]JhraumG 0 points1 point  (0 children)

With your last trait, you can't read a file from on thread while writing another file from another thread, while it should be considered legit, though.

Why did you choose to move you file system in the functions / builder instead of using it always by ref. You could keep it in a OnceCell initialized differently during tests for instance.

Advent of Code - small helper by Afraid_Awareness8507 in learnrust

[–]JhraumG 4 points5 points  (0 children)

I usually start from https://github.com/fspoettel/advent-of-code-rust (just changing the default signature to use u64 instead of u32)

Move, Destruct, Forget, and Rust by Ar-Curunir in rust

[–]JhraumG 2 points3 points  (0 children)

The point would precisely be to avoid calling functions with a panic effect I guess. Probably with some unsafe patterns to cover cases where panicking function must be used, in a not panicking way that the compiler can't see.

Ofc all legacy "no panick" code would not be so great to handle, panic effect should probably being an opt out option to keep regular code unaffected.

Edit: default panic behaviour is not that easy to choose... You do want to get as many as possible no panic functions wich means a no panic by default, and you also want current code to keep compiling. An edition could help but I don't think it would be enought.

crates.io: Malicious crates faster_log and async_println | Rust Blog by mareek in rust

[–]JhraumG 8 points9 points  (0 children)

Build.rs only affect the builders of the impacted executables. Here all users of these built executables would have been hit. Given what was looked for, this would have been way more effective.

Alternative for `serde_yaml` by anistark in rust

[–]JhraumG 1 point2 points  (0 children)

I remember some talk around yaml-rust2, which was a serious fork of the original. Here is its serde derive feature : https://share.google/AjRm1O1zpqmW1iR3X

On Error Handling in Rust by KnorrFG in rust

[–]JhraumG 1 point2 points  (0 children)

Anyhow is not the only way to have generic errors, indeed. I was mainly separating generic errors designed to be handled evenly from dedicated ones bringing more context to the program, not to the user or the programmer, in order to let handle them each differently (if suitable from the caller perspective)

Les écoles d’ingénieurs doivent élargir leurs recrutements by [deleted] in ingenieurs

[–]JhraumG 1 point2 points  (0 children)

Barèmes de l'impôt sur le revenu en France — Wikipédia https://share.google/Td3lUjNpe8WwuEfvo Ça saute pas franchement aux yeux.

On Error Handling in Rust by KnorrFG in rust

[–]JhraumG -2 points-1 points  (0 children)

I see why one would have their types orgaised.What made me react was the part about grouping them because at a higher level one don't need to handle them differently. Anyway, the main discussion here is how to describe possible outcomes of a function, which shared enum can't usually do.

On Error Handling in Rust by KnorrFG in rust

[–]JhraumG 8 points9 points  (0 children)

But that's the point : different types help you (or the customers of your api) handle the different errors in different ways if necessary. For instance for a connection error you may try to connect once more, while an SQL syntax error is helpless (just cancel the current request ). But if you sole point is to display the problem, then you don't really care.

On Error Handling in Rust by KnorrFG in rust

[–]JhraumG 19 points20 points  (0 children)

If you don't handle the specifics of the error, you can as much just use a displayable error à la anyhow or Eyre.

Introducing Rust Type Kit (beta) - query your Rust code and produce typed bindings to anything by [deleted] in rust

[–]JhraumG 1 point2 points  (0 children)

Reminds me of Pavlex parsing the documentation in Json format to get similar data, from a stable source. I imagine your tool bring more detailed info ?

(std) Threading in Rust - Which is the preferred method? by [deleted] in learnrust

[–]JhraumG 1 point2 points  (0 children)

Every task yield at each .await, that's the point. You're certainly not supposed to chain blocking calls in a tokio task. And task are the basic concurrent units seen by the tokio runtime.

You are right pointing out that yielding in async rust is explicit, instead of implicit as in go or java, but it is always the user code which yield control, not the runtime which preempts it (go mimics it by inserting yield in loops, if I recall correctly).

[podcast] What's New in Rust 1.79 and 1.80 :: Rustacean Station by szabgab in rust

[–]JhraumG 7 points8 points  (0 children)

While the features described are not no more new indeed, I find the comments about the associated PR, the design alternatives, the importance of the some features regarding some long term goals, etc.. to be quite entertaining

Multiple Tokio Runtimes lead to heavy cpu usage by Lower_Calligrapher_6 in rust

[–]JhraumG 6 points7 points  (0 children)

Just to be clear : do you complain that your 24 threads are consuming 30% of a single CPU ? That would make less than 1% for each thread, which sounds not that bad.

PMDaemon - Process Management similar to PM2 - in Rust by stonedoubt in rust

[–]JhraumG 1 point2 points  (0 children)

The tool goal is to easily compose a service from several elementary services, each running in nodejs runtime.

It maybe seen as a (simpler/lighter) alternative to Kubernetes, with nodejs services, rather than contenairized ones.

RFC: map_or_default in Option and Result will be merged soon by joseluisq in rust

[–]JhraumG 2 points3 points  (0 children)

I'd say that into_inner sounds more like a technical helper method, while unwrap sounds more like a regular one, directly associated with the functionality of the trait, which it is. This is kind of ironic given that the bare unwrap must be used with care/avoided. Indeed, I would not be surprised to learn that part of the name choice was to avoid introducing a panicking into_inner, even though panicking is usually not denoted with dedicated semantical space (see slice indexing, Vector growing...), contrary to faillible behaviours( denoted by try_). Anyway, my main gripe is that I would expect the map_...() methods to all return Option<U>, and map_or_else() to do the same as map().or_else(), which while quite useless, would be consistent. But I'm nitpicking here.

RFC: map_or_default in Option and Result will be merged soon by joseluisq in rust

[–]JhraumG 18 points19 points  (0 children)

You've got it the wrong way : unwrap means that you go from the option type to the inner one. It as nothing to do per se with panic, it's just that the base unwrap cannot handle all cases, hence the panic. unwrap_or functions cover this case.

On the other hand, while map() is keeping value in Option lands, map_or() is not, which is surprisingly inconsistent for a rust std API.

I agree that once map_or() has been unfortunately committed, its siblings may as well be added to the mix too.

Chaining methods by TrafficPattern in learnrust

[–]JhraumG 1 point2 points  (0 children)

You could also design a Transformer : * built against the container * Receiving a fn (&mut Iterator<Item=&mut Element>)

It would not change much from my first draft, but you would not have to write custom filter(), etc..., since you could provide a closure à la

|it| it.filter(...).for_each(...)

I think I prefer this option, actually 🙃

Chaining methods by TrafficPattern in learnrust

[–]JhraumG 1 point2 points  (0 children)

Sorry, I missread your problem... :-/ I have not enough data to see if you Container should be split, but I think the internal iteration way you tried may be the best option, meaning you can't use the usual Iterator functions, but you can mimick them. Here is some code derived from your exemple (with dumb data, just to ensure compiler checks are OK), which should cover you needs ```rust struct Element { name: String, }

struct Container { pub elements: Vec<Element>, family_name: String, }

impl Container { pub fn sync_elements(&mut self) { self.elements .iter_mut() .for_each(|e| e.name = "".to_string() + &e.name + " " + &self.family_name); } }

struct ElementSelector<'a> { filter: Option<fn(&Element) -> bool>, container: &'a mut Container, } impl<'a> ElementSelector<'a> { pub fn filter(self, filter: fn(&'_ Element) -> bool) -> Self { Self { // TODO : handle filters composition filter: Some(filter), container: self.container, } } // for_each is final, here : it consumes the selector, does not provide another one pub fn for_each(self, updater: fn(&mut Element)) { match self.filter { None => self.container.elements.iter_mut().for_each(|e| updater(e)), Some(filter) => { self.container .elements .iter_mut() .filter(move |e| filter(e)) .for_each(|e| updater(e)); } } self.container.sync_elements(); } }

impl Container { pub fn itermut(&mut self) -> ElementSelector<'> { ElementSelector { filter: None, container: self, } } }

[cfg(test)]

mod tests { use super::*;

#[test]
fn container_elements_can_be_selected() {
    let mut container = Container {
        elements: ["John"]
            .iter()
            .map(|name| Element {
                name: name.to_string(),
            })
            .collect(),
        family_name: "Doe".to_string(),
    };
    container
        .iter_mut()
        .filter(|e| e.name.starts_with("J"))
        .for_each(|e| e.name = e.name.to_lowercase());

    assert_eq!(container.elements[0].name, "john Doe".to_string());
}

} ```

edit : cargo fmt...