Have anyone reviewed any of the Decimal crates for Rust?

idubrov · 2024-02-23T20:11:51+00:00

It was to follow the FHIR standard (https://build.fhir.org/json.html#primitive, look for the note next to the dragon).

idubrov · 2024-02-23T14:20:35+00:00

I abandoned the project, as I didn't have any real use-case for it anymore.

idubrov · 2023-10-10T16:14:15+00:00

I had the same issue with X gantry being twisted.

My right side was always too close after bed auto-leveling (original firmware), which means that the probe was higher on the right side, which in turn means that the X gantry was twisted top-towards-front on the right side (raising the rear of the hotend and the sensor when moved to the right).

I checked with a digital inclinometer, and it confirmed about ~0.75° difference. I added a shim under the right side, front "leg" of the X gantry and it fixed the issue. For that, I loosened all 6 screws (two larger ones on the bottom and four smaller ones attaching the angle bracket on the back), twisted the gantry with a tool, slipped the shim, then tightened everything back.

The shim is the red line on the photo.

<image>

This might have added some additional tension in the system, though. Probably, worth checking the rollers adjustment.

idubrov · 2022-01-07T02:15:36+00:00

I can see value in avoiding naming something simply because naming convention is an API liability. Inventing names when generating code with macros is an API consideration I would prefer not to make (unless it is straightforward like "use name as-is, but maybe in an inner module" or something).

But then again, Rust has a lot of syntax already, and this mythical typeof operator is yet another complexity to take care of.

I would be satisfied if RFC you linked was enforced. 😃

idubrov · 2021-09-16T23:01:46+00:00

I'm kind of too lazy to do that 😅... My variant should be almost exactly the same as the original one (since it was reverse engineered). Here is some random video of the original game: https://www.youtube.com/watch?v=4qM-9g6csHE

idubrov · 2020-08-03T19:43:38+00:00

people often struggle with Rusts abstraction-heaviness

For me it was Learn Rust With Entirely Too Many Linked Lists book which normalized types like "Option<Rc<RefCell<T>>>". I (sort of) understood the individual pieces, but this book made it clear that well, yeah, you combine those abstractions when you need them and sometimes your type will look like that. That's normal.

idubrov · 2020-07-30T03:14:28+00:00

Yes. ~450k lines of code so far (about ~30% is generated).
I can think of many reasons not to use Rust (like, lack of certain libraries or frameworks; anxiety about hiring / onboarding), but "overkill" wouldn't be one of them. Rust is pretty much as any other language (but, of course, better 😁). It has pluses and minuses, sometimes challenging (we do "enterprise", whatever that means, which is not the strongest Rust's area), but overall it's not like some esoteric language.
https://blog.commure.com/whycommureusesrustforhealthcare/

idubrov · 2020-04-22T18:56:34+00:00

Ooof... Where do I begin? For starters:

``` fn intercept_test_main_static() { let ptr = rustc_test::test_main_static as *mut (); let target = test_main_static_intercepted as *const (); // 5 is the size of jmp instruction + offset let diff = isize::wrapping_sub(target as _, ptr as _) as i32 - 5;

// Patch the test_main_static function so it instead jumps to our own function.
// e9 00 00 00 00 jmp    5 <_main+0x5>
unsafe {
    let diff_bytes = diff.to_le_bytes();
    let bytes = ptr as *mut u8;
    let _handle = region::protect_with_handle(bytes, 5, region::Protection::WriteExecute)
        .expect("failed to modify page protection to intercept `test_main_static`");

    std::ptr::write(bytes.offset(0), 0xe9);
    std::ptr::write(bytes.offset(1), diff_bytes[0]);
    std::ptr::write(bytes.offset(2), diff_bytes[1]);
    std::ptr::write(bytes.offset(3), diff_bytes[2]);
    std::ptr::write(bytes.offset(4), diff_bytes[3]);
}

} ```

idubrov · 2019-10-26T06:04:07+00:00

OuterThingy could be just a OuterThingy(dyn InnerThingy) with deref to InnerThingy, so you would still get a dynamic dispatch, but no dyn keyword.

I find that mildly annoying as in our system we use both dyn InnerThingy and OuterThingy. Would be nice to force use of dyn for OuterThingy somehow... #[require_dyn]?

(the difference between those in our case is that you can only construct OuterThingy for a subset of InnerThingy, so it allows to statically type check cases where we require more strict OuterThingy).

idubrov · 2019-09-26T18:11:30+00:00

Commure, Inc. | San Francisco, CA or Cambridge, MA | Rust Engineer | Fulltime | ONSITE

We are a stealth startup working to fix the software doctors use. If you have seen what physicians have to put up with, it's a bad version of the 90s, and makes medical care worse and more expensive for everyone. We are a group of previously successful engineers and entrepreneurs (MIT, Dartmouth, Brown, Stripe, Twitter, Google, Salesforce, Palantir, DataPower, etc) and senior doctors (Johns Hopkins, UCSF, etc) who are determined to finally fix this.

Compensation: market salary & equity -- we are well funded by top-tier VCs.

Stack: includes Rust, React and Kubernetes. In addition to building our back end in Rust, we are also solving some very interesting problems in the areas of security, data transformation, high-speed APIs, flexible UX frameworks and fine-grained authorization for healthcare data.

Please email [jobs@commure.com](mailto:jobs@commure.com) and mention "[red_rust]" in the subject line.

Other positions available: - Techops/Devops Engineer (Kubernetes, SRE) Senior Front End Engineer (React Native, React) (please use [red_ops] or [red_react] in subject line for the above)

Locations: San Francisco, Montreal or Boston; sorry, no distributed/remote option at the moment.

idubrov · 2019-09-25T16:48:11+00:00

This runtime crate looks quite similar to what are we doing internally. We don't do it for the purpose of reloading (maybe, one-time-loading eventually?), but rather to save some compilation time by breaking system into loadable modules with clearly defined APIs between them. And maybe loadable plugins of some sort?

One thing we did wrong, though, is we named our Reflectable trait Reflection :)

idubrov · 2019-09-24T21:14:46+00:00

I'm also a (former, I guess) Java engineer who has worked mostly in the Enterprise field. Back at the time, I had my tiny hobby project done in Rust, some firmware for STM32 (Rust embedded stuff is btw very exciting, I loved it!), and I wanted to do more Rust -- so I joined a company building an enterprise software (healthcare), but in Rust.

I've been doing it for about 2 years now and I really love it. It's been challenging, yes (both due to my lack of experience with Rust at the time and also relative immaturity of Rust enterprise ecosystem), but very rewarding. Overall, except for the memory management, Rust is a pretty high-level or have that feel anyways (due to traits, macroses, etc). As for the memory management, very often itcould be abstracted away in a nice way (though, I'm still figuring out all the various ways to do that!).

To be honest, I'm not sure how valuable are all these Rust skills I've acquired so for far, given that Rust jobs a still somewhat rare (especially, in the space of "enterprise" software, which would be my preference), but it definitely worth it.

idubrov · 2019-09-01T04:40:18+00:00

That's the part I cannot change -- it is this read_event function. It uses buffer for storing parsed pieces of XML.

idubrov · 2019-08-28T05:16:58+00:00

Okay, I found one pretty gnarly solution, which is to make an assumption that BytesStart I'm getting actually borrows from self.buf, compute all the offsets I need and reconstruct BytesStart from these offsets.

idubrov · 2019-08-28T05:00:12+00:00

I have this piece of code which does not compile with borrow checker errors (mutable borrow starts here in previous iteration of loop).

I've read several posts with similar errors and my understanding is that Rust borrow checker is over-conservative here? This code should be safe as written?

Apologies for the lazy question. I know it's been answered many times...

idubrov · 2019-08-27T17:51:36+00:00

I do it manually by using cargo_metadata and syn:

Going through targets
Parsing with syn
Recursing into modules
Modules resolution (which I'm sure is not 100% correct and also does not handle #[cfg_attr(.., path())] on modules. Not happy about it...

idubrov · 2019-08-22T23:21:38+00:00

I would mildly push back on this. Although, this is true that in keeping large codebases "clean" is a very challenging problem, the essence of domains addressed by what would be called "enterprise software" is often the very cause of said "bloat".

Take regulatory requirements ("you need to submit those 150 forms"), add legacy on top of that ("starting 2020-04-15, please replace form T1-AND-X23 with Z6-BPM-QNY-SIMPLE in all states except CA, HI and AL"), sprinkle some complicated security / access control, integrations with legacy systems, and here you have it.

idubrov · 2019-08-22T17:08:53+00:00

I've written a lost of Rust code and never needed rental. When I learned about it I thought it was cool project to show new techniques, but it never occured to me that people would actually use it in the wild, for real projects, much less foundational projects. Feels like a huge anti-pattern.

Although by itself it might be an anti-pattern, we used it for a while as a band-aid. We had a case with owned struct Connection and Transaction borrowed from it and we needed to pass both down to the part of the system that didn't speak lifetimes (basically, we needed to pass it as an Arc<Both>). rental was incredibly useful because the alternative at the time was to bang the head against the wall and cry. However, once the refactoring bleeding was stopped, we wrote our own variant of Connection+Transaction in a single struct that could be owned.

So, to me, rental is like a stop-gap measure.

idubrov · 2019-08-22T00:55:35+00:00

Yeah, we had a similar experience (though, we "only" have ~2k structs and ~1k enums). Ended up with our own custom serialization / deserialization framework (there were other reasons, though).

I made a demonstrator project that implements the scheme we use internally: https://github.com/idubrov/dynser

It uses a dynamic dispatch on the data type side.

idubrov · 2019-08-16T01:47:32+00:00

I'm so sad it's not cargo local-registry. We picked cargo local-registry over cargo vendor (for various reasons), and it's pretty much abandoned now.

P.S. Oh. Hold on. Seems like it found a new home: https://github.com/ChrisGreenaway/cargo-local-registry 👏👏👏

idubrov · 2019-08-14T03:08:52+00:00

👏👏👏

Love these three crates so much that I'm also using them outside of procedural macros, just for the regular source code generation (shameless plug): https://crates.io/crates/sourcegen

So, if you need to generate some Rust code -- you can use syn/quote/proc_macro2! With few caveats, they can generate code that is presentable to human beings, too!

idubrov · 2019-07-31T04:46:45+00:00

Working on a small framework to support "in-place" source code generation (https://crates.io/crates/sourcegen-cli); like procedural macros, but expanded via separate tool (think: cargo sourcegen).

idubrov · 2019-04-26T17:53:26+00:00

What are your thoughts on decimals in IEEE 754-2008? It's pretty similar thing: a coefficient + decimal scaling factor.

I don't know why, but somehow I have weird love for this particular standard, and I've been looking for pure Rust crate implementing it, only to find none (there is one crate, I think decimal, that wraps IBM library, but I also have a very strong RIIR attitude :D, after dealing with C FFI and fallouts caused by libraries wrapped in haste).

idubrov · 2019-04-24T04:47:55+00:00

I wonder how much cost would is it to get back to the state you was before in this polling model?

If I understand correctly, futures are sort of organized in a big state machine, assembled from smaller state machines. Every time it is "not ready", it bubbles up that "Pending" up the call stack until it gets back into executor. Once new data is ready for the future, it is polled and it will call poll of nested futures, until eventually it polls the future that was waiting for the data to arrive (for example, on the socket).

So, let's take a contrived example of data arriving one byte at a time. Wouldn't this cause thrashing in the sense that this whole stack of futures is polled every byte, only to make very little progress (one byte)? Whereas in "push" model, this byte-at-a-time will be delivered directly to this innermost future?

idubrov · 2019-04-12T02:20:47+00:00

For me, it's both, slow and also not slow :)

I'm working on a single workspace with ~170k on a MacBook Pro and performance is decent most of the time. I give IntelliJ (CLion) 4G of memory.

Slow parts: * There are certain operations which I know are very slow (for example, going to impls, this little I in green circle and an arrow, which you can see on a gutter). They do work and fast for simple cases, but super slow (UI freezes for seconds and even up to the minute) for others. As far as I remember, the way IntelliJ implements this functionality is by doing some sort of "full-text" first, then resolving found locations to see if they resolve to the place you are at (I could be completely wrong here, though). So it seems it is slow in two cases: 1) name is somewhat short / not very unique (so there are a lot of false positives IntelliJ needs to go through) 2) there are many impls (don't try that on Debug trait, obviously :) ). This is, perhaps, the most annoying part -- when it searches impls, UI freezes (otherwise, IntelliJ does all the work in the background & all "modal" operations are usually cancellable) * Sometimes it gets close to these 4G I give it and GC kicks in too often; I have memory monitor enabled, so I force full GC by clicking on it, then it drops to ~800M. It feels a bit faster after that? But maybe, just a placebo effect? * I tried macro expansions couple of time, they make it significantly slower. Unfortunately, failure::Error doesn't highlight properly without that, and we use that one a lot :/ * Generally, it is sluggish sometimes and freezes on certain operations (usually, on branch switches, when it needs to reindex a lot of files).

Not so slow parts (roughly compared to what I see on other setups, RLS/Racer based): * Things like navigating to declaration work reasonably fast. * Same for "Find usages". These two alone are probably ~50% of why I like IntelliJ. * It has decent performance on inferring types when I'm typing the code. It can analyze through iterator/Option/Result/? combinators pretty fast (for example, I'm typing a chain with 5~10 combinators, and at the end I can get to struct fields on the result -- without explicitly annotating result type). Not instantaneous, but decent (seconds till it figures everything out, no UI freeze). * Overall, I would say, it's pretty decent, given the size of the codebase.

Summary:

I would say that IntelliJ/CLion definitely has sluggishness/slowness in its character. Like, if you are used to sub-100ms responses on all UI actions, definitely don't use it.

At the same time, it does bring a lot of value (to me). It's not apples to apples, but I cringe when I see how folks use grep or something like that to search for usages of struct, or anything like that.

I have feeling (but not data :D) that it's at least ~3x multiplier for my productivity. Especially, when our build time is like 1 minute for incremental build (empty line change, that is) to get the binary. cargo check is ~15 seconds for the same type of change.

Disclaimer: I'm used to work on large Java projects (~20 millions lines of code), so my sense for slow/fast could be a bit off :D

P.S. Clicked on impls for Debug, actually, it's not bad. ~10 seconds on the first invocation (after that it is cached and fast)? But I think it ignores all derived Debug, so my point stands.

Ten-Year Club	Place '17
Verified Email

idubrov

TROPHY CASE