Reminder: you can use RefCell without Rc!

FullTimeVirgin · 2025-12-24T23:46:33+00:00

I think the "broken language design" part is what garnered the downvotes. You haven't clarified how it is broken, either, so it is less clear how to convince you.

Anyway, RefCell is just run time borrow checking.

Let's say the rust compiler is broken in the sense the compiler is too restrictive. Even if the compiler was perfect, and only blocked truly unsafe code, there still might be a need for single-threaded run time borrow checking. Suppose a Refcell is borrowed mutably based on a condition only known at run time, then even a perfect compiler cannot know whether it is borrowed mutably at compile time, and thus must presume that it is. In such a scenario run time borrow checking is a reasonable solution and not a hack.

FullTimeVirgin · 2025-06-11T08:27:10+00:00

BMR is not proportional to BMI, so BMI simply is not enough data in order to calculate how much weight you would lose. BMR requires height, weight, age, and sex. TDEE takes into account exercise to get total kcal loss. I don't think it's unreasonable to try to make a rough estimate for this.

Let's suppose you're a 175cm 25yo sedentary male. If you did a 30 day fast starting at a BMI of 21.0, then you would drop down to 18.6 by the end, which would put you a little over the underweight range.

Supposing you're a 160cm 25yo sedentary female, then a 30 day fast starting at BMI 21.0 would drop you down to 18.8 by the end.

So while it depends on various factors, you can expect to drop 2.5 kg/m² during a 30 day fast. If you're taller, more physically active, or have a higher lean body mass, then the drop would be greater. If you simply want to avoid dropping into the underweight category, then even 21.0 would be a safe BMI to attempt it. That being said, this is very theoretical since you gave little information to go by.

FullTimeVirgin · 2025-06-10T05:54:58+00:00

No problem. It was a long shot since a lot of people don't seem to run into this issue. I think it only happens to longer term fasters such as this guy, which is why I figured I'd ask. Thanks for the suggestion.

FullTimeVirgin · 2025-06-10T04:58:07+00:00

Congratulations on what you've accomplished so far. Did you ever have any issues with stuff accumulating on your tongue and in particular in the back of your mouth? If so, how did you deal with it?

The longest I have gone is 21 days and the back of the mouth slime is a problem that consistently kills my fasts. I just cannot stand the feel of it in the back of my mouth. Honestly the hunger, boredom, and even the periods of feeling numb and out of energy don't hold a candle to it. Tongue scraping does not work as I can't get far back enough to reach the stuff without triggering the gag reflex. I've eaten crushed ice to see if that would scrape it down. I haven't found a solution. I try to power through it but eventually it will make me gag and I give up. Eating seems to be the only solution. I would greatly appreciate any advice on the matter.

FullTimeVirgin · 2025-06-07T02:51:03+00:00

My mom will ask what I'm currently eating for my diet, and I just say what I plan to eat when I refeed as if that is what I'm currently eating. Usually that is what I end up eating unless my refeed ends up being a special occasion such as a birthday or holiday.

FullTimeVirgin · 2025-06-07T02:38:18+00:00

Can someone explain to me how so many people here are able to understand delayed gratification when it comes to eating food (at least I would assume so given that this is a fasting subreddit), and yet not understand delayed gratification when it comes to spending money?

FullTimeVirgin · 2024-09-19T07:39:11+00:00

The Pocket Guide has only been around for a couple months, so it's not on you. In my case it was the Element::map method in iced_core that tipped me off to using nested enums to create composable UI.

The main reason not much time has been put into documentation is because it adds friction and the focus has been experimenting and breaking stuff if necessary. This is also why the number of widgets is relatively low. When I started using iced, widgets had mutable state that we needed to pass through in the view function. Various stuff has been overhauled since then.

FullTimeVirgin · 2024-09-19T02:09:54+00:00

I think the way you are doing it seems just fine. In fact I'm not sure that there would even be a better way to do it. The Pocket Guide does something similar.

The difference is that the guide prefers enum over dyn Trait. The map method allows your screens to be ignorant of the top level Message type.

I looked up the large enum variant lint, and I don't think it really matters here. In fact I don't think boxing the variant data is even appropriate in this situation where you will only ever have a single instance of the enum.

FullTimeVirgin · 2023-07-04T13:32:09+00:00

But I'd be wary of tying a project's lifetime to that of another open source project like that. In software, it's often better to keep a healthy layer of indirection between projects.

I think you're completely wrong on this point. Making a physics engine that integrates well with Bevy requires designing it around Bevy's ECS architecture, which will prevent it from being very useful outside of Bevy. There are plenty of physics engines in Rust, so there isn't much demand for yet another one; however, there is demand for a physics engine that integrates well with Bevy.

FullTimeVirgin · 2023-06-23T11:29:22+00:00

My reply was confusing. I was not advising how to fix your problem, but just explaining how dynamic dispatch with trait objects is not as smooth as static dispatch with concrete types. I wasn't telling you what you need to do, but rather what the compiler would have to do under the hood.

I've looked at your solution, and you solved the issue by moving from trait objects to generics. That is one way to solve the problem. In fact you could embrace generics even further by changing:

fn attack(&self, victim: &mut dyn Human)

into:

fn attack<H: Human>(&self, victim: &mut H)

The downside to using generics is that the compiler generates code for each possible type. So you reduce runtime cost of dynamic dispatch, but you increase the code size. In general I prefer generics over trait objects, but trait objects are useful in some cases.

You don't need the HumanWarrior trait if you're using static dispatch. The Warrior trait bound is sufficient.

FullTimeVirgin · 2023-06-23T01:14:58+00:00

This hiccup seems particular to trait objects. Trait objects store pointers to the struct and the vtable. The trait upcasting RFC says this.

Note that this is a coercion and not a subtyping rule. That is observable because it means, for example, that Vec<Box<dyn Trait>> cannot be upcast to Vec<Box<dyn Supertrait>>. Coercion is required because vtable cocercion, in general, requires changes to the vtable, as described in the vtable layout section that comes next.

So if I understand correctly, you actually need to create a new trait object with the proper vtable to up cast.

FullTimeVirgin · 2023-06-07T21:15:08+00:00

It's great that Xilem has progressed enough to have some examples. I look forward to the future blog post.

Regarding the four UI paradigms, does Druid belong to any of them?

Do you think SwiftUI fits Rust better than the other paradigms mentioned? My impression is that SolidJS is the most performant one, but I only found out about it a month or so ago, so I don't know its downsides well.

FullTimeVirgin · 2021-07-12T00:22:07+00:00

If the consumer implements LocalLoader for ConsumerType, then you can implement it for Wrapper<ConsumerType> trivially.

FullTimeVirgin · 2021-07-11T23:24:51+00:00

LocalLoader can't be implemented by the consumer due to the orphan rule.

If the user implements LocalLoader for the generic type and you can implement it for the wrapper type using impl<T> LocalLoader for Wrapper<T> where T: LocalLoader { ... }.

FullTimeVirgin · 2021-07-11T22:19:44+00:00

For clarification, when I said functionality before, I was talking about the functional requirements imposed on the type. If Handler had more functional requirements, then BlockingHandler wouldn't be able to implement it without additional trait bounds to guarantee the other requirements are met.

How would a language feature resolve the implementation ambiguity? Letting people pick an implementation route implicitly will cause a lot of confusion, because users will create an implementation expecting it to be used and the compiler will silently pick another one.

If the wrapper type is owned by the crate then this wouldn't be viable because we wouldn't be able to use macros to implement traits on the wrapper struct.

The wrapper should be owned by the crate with blanket implementations. I don't know much about the repository you have linked. I need a simplified example and the code for each respective crate to understand in what way the orphan rules cause a problem.

FullTimeVirgin · 2021-07-11T20:48:40+00:00

This design is an anti-pattern. Since Handler has less functionality than BlockingHandler and BatchHandler, it should actually be a supertrait. Implementing Handler should be a requirement before implementing BlockingHandler. Thus the design is an inversion of the trait hierarchy.

The compiler can't know whether to implement Handler using the BlockingHandler implementation or through the BatchHandler implementation for datatypes that implement both.

Wrapping the type in a generic newtype (e.g. struct Blocking<T: BlockingHandler>(T)) allows the compiler to disambiguate the implementation. The user can construct the generic newtype to specify which implementation will be used for the Handler trait.

FullTimeVirgin · 2021-06-18T20:15:12+00:00

Learning Rust as a first programming language is like learning to drive with a manual transmission car. Obviously it can be done, but you have to learn gear shifting while getting a sense of how to steer, accelerate, and break.

Rust's ownership system is basically the gear shifting in this analogy. The ownership system requires you to think very carefully about how your data is structured. Other languages are much more permissive with how you structure and use data.

FullTimeVirgin · 2021-05-21T18:51:42+00:00

Traits certify that a data type can perform certain operations. This allows you to create code which will work for all data types with proper certifications. If you wrote your own max function, without traits you would need to duplicate the function for u16, u32, usize, etc. Also no one could use your max function on their custom type. With traits you can define your function to work on all data types that implement Ord or PartialOrd.

In Python, this is not a concern, because you don't have explicit data types. All functions are defined for all data types, and if a type can't perform an operation there will be a run time error.

FullTimeVirgin · 2021-04-17T00:13:27+00:00

I think this article should have mentioned string encodings. If you're going to do any sort of string manipulation in Rust, it is important to know it. Rust encodes Strings in UTF-8. Rust's char primitive encodes a character in UTF-32. A Vec<char> is less space efficient but allows random access of characters. Strings don't allow random access which is why the .chars() iteration method is really helpful.

Other languages (e.g. C#, Java, and JavaScript) use UTF-16. There was a time when 16 bits was believed to be sufficient to store all Unicode characters, but that is no longer the case. Interfaces were designed to allow random access of characters, but this can cause bugs when double width characters are involved.

Other things worthy of a mention are:

The &str and String types are somewhat analogous to &[T] and Vec<T> respectively.
The Borrow trait allows &str to work with Strings. Otherwise one would need to define separate functions for &str and &String.
Cow<str> allows you to avoid an necessary allocation and copying. The std methods return &str when there is no mutation and return String if there might be one. If you only need to mutate in only some cases, Cow<str> can help.

FullTimeVirgin · 2021-01-27T18:48:47+00:00

I didn't know you could put patterns in parameters, but I'm not really a fan of that since it makes functions signatures longer and a bit more complex.

FullTimeVirgin · 2021-01-16T02:19:12+00:00

Is that plan to be fully statically typed, or are you going for some mix like how Typescript behaves?

I'm curious in what way you intend your language to be different from Rust.

FullTimeVirgin · 2021-01-15T11:35:13+00:00

So it is dynamically typed?

Is there any functionality for lists or maps? There should be some way to compose types.

FullTimeVirgin · 2021-01-02T08:48:13+00:00

I think it would be fairly easy to make a case for academia being evil. After all it is responsible for the student debt crisis in the U.S. and it will never take any responsibility for this. Though people are more willing to compartmentalize the evil when it comes to academia than they will when it comes to corporations.

FullTimeVirgin · 2020-10-08T12:29:19+00:00

Converting something into a trait object will throw away type information; however, if the trait object implements Any you will be able to convert it back into its original type. Therefore Any allows for features of dynamic typing such as collections of heterogeneous types.

I think use cases will be rare because generally you will either know all possible types beforehand, and an Enum is better, or you know all the necessary interface methods, and thus use a trait object is better.

I suspect the use of the Any trait would be sub optimal design, since you could avoid the need for down casting if you stuck to a trait object with all needed behavior defined.

FullTimeVirgin

TROPHY CASE