While interesting, this entire article works with a static MyStruct. This means the type already is Any, and if you define MyTrait: 'static, then you can do the downcast by first casting to an Arc<dyn Any> and using one of the downcast methods.

For non-'static types, downcasting soundly is incredibly difficult. You need to somehow get the correct lifetime back from the trait. You're better off using unsafe at that point anyway. If the trait itself holds the lifetime (impl<'a> MyTrait<'a> for MyStruct<'a>), then that can help with it, though I'm not really sure how lifetime variance plays into the soundness of a downcast here.

Finally, at the end, I'd rather just use an assert! over an unchecked assertion. I know the goal is to look at the assembly with that assertion in place, so it makes sense why they used it here. In practice, an actual assertion is a lot better because the compiler gets the same information from it and you get validation at runtime that the information is correct.

Anyway, great article! The goal was to explore how Arc casting works, and I think it does a great job at showing and explaining that.

You can custom serialize (timestamp, tz) or timestamp, offset or (timestamp, tz, offset), no?

Ironically, that was a part of a back-and-forth I had with burntsushi (jiff dev) right here on lemmy.

sigh

I used chrono because it allowed storing a statically known timezone with 0 additional runtime bytes and had rkyv support. Both very important features for my application (rkyv database containing millions of timestamps).

I have yet to find a replacement library that supports either of these features.

Seems like a good policy in general, open to changes, i hope this will make reviewers' job easier, considering how hard reviewing PR's for a university project with partners who insist on using LLMs for almost everything, i can barely imagine how frustrating this all must be.

Hey! I'm a person who specifically wants to hear that LLMs are always flaming garbage. Thanks for the explanation. Intent and tone is hard online. Your original comment, which probably read as a joke and firmly tongue-in-cheek to you, read as a frustrated and resentful snarky one-liner zinger to me until I got this explanation that you didn't mean it that way. Of course, I'm carrying my own biases (anti-LLM, frustration with harshness and generalizations and insults that I perceive to be happening more frequently on the Fediverse than back on Reddit or in real life).

I wonder if there are more jokesters than actual harsh people and I'm just misinterpreting it. (I have been stepping back from the Fediverse because of how many generalizations and frustrated, resentful, snarky comments I've seen; and how many LLM discourse posts I see on programming.dev that I, who have that as a trigger topic, end up rabbitholing down instead of doing something more useful. Me even clicking and commenting on this post is an example of the latter, I fear.)

Thanks again for clarifying your intent and going de-escalation mode, I think we need way more of that energy.

As was said elsewhere on the Internet:

Don't get me wrong, I welcome this policy, I just wish the "one line zinger" was a little more detailed, because if you come away from the article without reading on (or, more realistically, if secondary sources pick up this quote without the surrounding context), one could easily get a wrong idea.

Fair, but I was making a general comment with tongue firmly in cheek. I didn’t mean to denigrate anybody. Certainly not any individual. It was broad commentary on the general, though certainly not ubiquitous, view on LLM’s in the larger communities on Lemmy.

Oof, lots of valid points, especially that the value of a contribution is in the decisions it makes. Having an LLM guess those decisions makes the resulting code significantly less valuable.

Hell, one could argue pretty much entirely worthless, because the maintainers could prompt an LLM themselves, if the decisions didn't matter.

I guess that the purpose of the one-line summary is to communicate the spirit of the policy. The details that you are asking for, is what constitutes the majority of the the policy document itself. While you could probably summarize the body of the policy in more detail, having multiple lists with different levels of details would likely lead to confusion. So I think that the approach they've taken makes sense

The policy summarizes itself this way: It's fine to use LLMs to answer questions, analyze, distill, refine, check, suggest, review. But not to create.

Saying that "it's fine" seems a little overly broad, because sometimes it isn't, but I suppose that by "fine" they simply mean that it's not forbidden by the policy. A more complete summary would also mention that where it is allowed, disclosure of LLM use is required.

Personally, on the few occasions where I've resorted to querying an LLM it's been very much the same kind of experience that using Stack Overflow used to be. It's a quick way to see one way that other people have done some thing, but you wouldn't want to rely on it being the right way.

Hey, I know you are probably trying to help, but when you talk over/about other people and categorize them/put them in boxes, it never helps open opinions and discussions. Maybe don't put your expectations first, especially if they may be wrong.

Sorry. Thought it's worth saying, and my hope with this message is to reduce the volume of assumptions people make about each other here.

Seems pragmatic and well-written. But it doesn’t say “LLM’s are hot garbage in all circumstances and people who use them are all smelly turds,” so I’m guessing there will be backlash in this community.

It's called a spam re-post.

Already posted, duplicate post

btw how's the new trait solver going?

Super cool! Hopefully that can resolve some of the long standing issues with the borrow checker.

@xoron @ExperimentalGuy if you need server side processing, fullstack mode have a nice macro to generate API calls.In case you need a js lib (ex. Codemirror editor) wasm binding allow to define extern interface.For any technical issue feel free to post on their Discord forum.

It has little to do with time on first glance, at least to me I read the name as a gif manipulation library. If it were named jiffy or similar it might be slightly more reasonable.

Oh, they would never

im switching to the rust stack mainly because i think it has better tooling formal-verification. formal verification is particuarly important in my project because it relates to cryptography.

i assume i can get something comparable to what i already did with JS... but with rust, i may be able to break out of the browser environment.

i not only want to be able to offer a native gui version, but with rust i think im on track for also being able to create a cli tool too.

What's your goal with switching languages? You need to figure out what business requirements are fulfilled more effectively given that technical change before making that change. I mostly say this because I don't hear a clear reason for the switch in your post.

For the rust ecosystem in general, reading through the cargo help output to see what tooling is there is a great start. You can see what functionality is already baked into the native language tooling, which should guide you on the right path. Off the top of my head, theres ways to test and lint your code already built in. Best practices are usually crate dependent, especially when working with something (I think) is macro heavy like dioxus(I don't do a lot of UI in rust). Make sure to go through the provided dioxus code examples because those will probably cover most use cases you'll be going for.

Yeah, thought they were just gonna recommend the time crate (which has seen some modernization over the years).

Kind of unfortunate that the ecosystem is even more fragmented than I thought, but jiff is being developed by Andrew Gallant, who's on the Rust team, so that has the potential to become the new standard...

Change your name to Err::<!,!>(return).unwrap()

Why ? It looks fine to my non-native-English eyes.

Nothing of significance will actually happen. The crate is too deeply intrenched in the ecosystem. And the little maintenance needed will be easily picked up.

Coming from C not C++, I actually didn't like chrono at first, but grew to be okay with it, and it gets the job done.