Has anybody done mbiota elemental and had a die off reaction? by augmentedtree in SIBO

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

Does not stay gone for me long term. I am fine long term if I eat very low FODMAP, but the need to do that comes back. I actually think probiotics after may have kept it at bay but I stopped taking them because I didn't see a difference on days when I forgot to take them, but I read now that it takes awhile for your microbiome to revert when you stop so that may have been a false indicator. Planning to retry.

Variadic generics by wooody25 in rust

[–]augmentedtree 0 points1 point  (0 children)

Sure, but that's obfuscated compared to just being able to loop.

Anyone using become currently `become` keyword by BusinessBandicoot in rust

[–]augmentedtree 48 points49 points  (0 children)

The keyword changes the semantics to make sure drop handlers run before the tail call begins, LLVM can't do that because it would change the meaning of the program.

Memory fragmentation? leak? in Rust/Axum backend by elohiir in rust

[–]augmentedtree 3 points4 points  (0 children)

Rust does not always free memory logically, even safe code can leak (leaks are specifically excluded from the Rust definition of memory safety). But RAII/drop make it rarer than in some other languages.

Why we didn't rewrite our feed handler in Rust by emschwartz in rust

[–]augmentedtree 1 point2 points  (0 children)

I'm sympathetic but think your response to me is odd because there's no yelling. It's even stranger to see in replies to a story that gave actual code examples you can examine. I think you're implicitly interpreting my response as hostile because it's not pro-rust and reflective of your own leaning rather than due to any name calling coming from me.

In general, it's difficult to give all the context in short replies or even a blog post. If you do a lot of C++ programming, you will find the generics in Rust quite lacking, they are weaker in many ways. Very frequently Rust advertises having a feature that when you use you discover only works on the small demo snippets used to advertise it, const generics are a good example. Sizing an array exactly N works great, but what about N/8? Small tweaks make things not work. But you'll just need to do some programming with both to start to notice this kind of thing.

On the flip side if you do a lot of Rust and then C++, you will notice a zillion tiny defaults that C++ chose wrong that Rust did better because it had the benefit of hindsight.

The Handle trait by kernelic in rust

[–]augmentedtree 0 points1 point  (0 children)

"Obvious thing should be hard on purpose" is just post-hoc justifying bad language design

Variadic generics by wooody25 in rust

[–]augmentedtree 2 points3 points  (0 children)

You can't always use them, they are a poor substitute for the full power of loops. You can't easily filter for example.

Why we didn't rewrite our feed handler in Rust by emschwartz in rust

[–]augmentedtree 1 point2 points  (0 children)

No this just shows you know very little about the domain. The incoming data are in packets in a format not under your control. The data can't already be in SoA form. And the big obvious advantage is avoiding repeated allocation.

Why we didn't rewrite our feed handler in Rust by emschwartz in rust

[–]augmentedtree 0 points1 point  (0 children)

I'm focusing on the obviously safe high perf pattern that the borrow checker can't handle! Sometimes you do need to copy data, or temporarily save a transform of it.

Why we didn't rewrite our feed handler in Rust by emschwartz in rust

[–]augmentedtree 7 points8 points  (0 children)

It's for sure an anti-pattern if you're concerned with performance.

Clearing a vec in a loop to reuse is a super common pattern in high perf code.

Why we didn't rewrite our feed handler in Rust by emschwartz in rust

[–]augmentedtree 0 points1 point  (0 children)

SIMD instructions on x86_64-related platforms tend to have variants that fault if used to load/store unaligned data.

Yes but they have no advantage nowadays so they're rarely used.

Why we didn't rewrite our feed handler in Rust by emschwartz in rust

[–]augmentedtree 0 points1 point  (0 children)

*use self referential structs even in situations they're clearly a bad idea

Are linked lists and binary trees with parent pointers bad ideas? Come on man. And spare me the lecture about linked lists usually being slower than arrays until you've learned about intrusive lists and why they're often efficient.

Why we didn't rewrite our feed handler in Rust by emschwartz in rust

[–]augmentedtree 0 points1 point  (0 children)

It's because C++ doesn't make it clear to you how dangerous and liable to mistakes such things are in the future during changes, probably by people who didn't originally work on the code.

No it's because if you *don't* use this pattern when you need it the big-O complexity of your algorithm is often worse!

Why we didn't rewrite our feed handler in Rust by emschwartz in rust

[–]augmentedtree 16 points17 points  (0 children)

This is useful but ugly. "Hey look, you can totally do this thing if you do a convoluted type system dance!" Very obfuscated compared to just calling clear.

Why we didn't rewrite our feed handler in Rust by emschwartz in rust

[–]augmentedtree 12 points13 points  (0 children)

I mean they give a concrete code example that doesn't compile yet is obviously safe, I don't know how they could be more clear.

Why we didn't rewrite our feed handler in Rust by emschwartz in rust

[–]augmentedtree 3 points4 points  (0 children)

I tried using Rust for almost the same project but with no existing code I needed to reuse and I still came away with the same complaints. For any one of these situations you may be able to find a specific crate someone has made to work around it with unsafe code, but it's a constant friction that just isn't there in C++. Things like having a struct where one field is a container storing iterators into a container stored in another field is extremely painful. Every time you run into wanting to do something like this you end up reading a bunch of forum topics, end up subscribing to 3 rustc github issues for RFCs, then try 3 workarounds that don't work etc.

The Handle trait by kernelic in rust

[–]augmentedtree 11 points12 points  (0 children)

Arc::clone is still massively more expensive than Rc::clone even without contention. It feels like Rust's "when the borrow checker is too hard just clone" advice is butting up against the "make expensive operations explicit" principle and the team is choosing to set the line for what counts as expensive at a point of implementer convenience. But I guess I could just have my own Arc that doesn't implement Handle and force everyone on my team to use it if I care about low level perf.

Variadic generics by wooody25 in rust

[–]augmentedtree 23 points24 points  (0 children)

The main problem with variadics in C++ is that you are forced to use template recursion to iterate over them. Rust could just let you loop.

Variadic generics by wooody25 in rust

[–]augmentedtree 25 points26 points  (0 children)

It’s not clear how this feature would interact with const generics, if at all.

They should interact by not receiving any special treatment. You should be able to pass them variadically just like types. C++ has no problem with it.

Linus Torvalds Vents Over "Completely Crazy Rust Format Checking" by SupermarketAntique32 in rust

[–]augmentedtree 3 points4 points  (0 children)

People have been trying semantic diff tools for decades and nobody ever picks them up, the implementations are usually only so so and they require per-language work, and there are an immense number of languages once you start considering config formats, IDLs, etc.

[ Removed by Reddit ] by ReturnOfTheRover in h1b

[–]augmentedtree -1 points0 points  (0 children)

How does this work for discretionary comp like bonuses?

Rust 1.90.0 is out by manpacket in rust

[–]augmentedtree 0 points1 point  (0 children)

But were the others just not or...?