zygo_histo_morpheus

It's another c/c++ competitor along with rust and zig. https://odin-lang.org/

I don't know that it's the "algorithms": a lot of people just use their following feed on twitter and although it changed a while back that was the default feed on bluesky for a long time. I think that there is a fairly large portion of bluesky users who mostly just look at following and still don't really like mastodon.

Imo, a big reason why bluesky has been a more successful twitter competitor than mastodon is cultural: mastodon has been around for years before musk bought twitter, and a big selling point was that it wasn't like twitter, for example that its "less toxic". A large part of mastodons userbase never liked pre-musk twitter that much and will tell you of for acting like you would there. Bluesky on the other hand has a large portion of users who liked pre-musk twitter and are happy to follow pretty similar social norms as they did in pre-musk twitter.

This is to some extent reflected in the functions of the different sites as well, for example you can't quote retweet on mastodon which iirc is deliberate because qrt dunking is "toxic". Bluesky has quote retweets (although they allow you to untag yourself from a qrt).

Yeah I agree, I think looking towards the future is a better idea in general. I'm on lemmy but not tumblr myself

Fresh memes!

My theory is that the primary reason why the fediverse isn't more popular with young people is cultural. For instance, I don't think anyone in generation z would use the term "fresh memes" :)

But yeah I also think that tumblr has a nostalgia advantage. It represents the internet before it "turned bad", while the fediverse represents a possible future for the internet. Both have different appeals, but I think that nostalgia wins out for a lot of people.

Don't think it has anything to do with electron. VSCode is just the largest editor that people install extensions for, so it's what makes the most sense to write malware for. If vim was more popular, I'm sure there would be more crypto mining extensions for that (I wonder how many there are? Surely more than zero?)

This article uses the term "parsing" in a non-standard way - it's not just about transforming text into structured data, it's about transforming more general data in to more specific data. For example, you could have a function that "parses" valid dates into valid shipping dates, which returns an error if the input date is in the past for instance and returns a valid_shipping_date type. This type would likely be identical to a normal date, but it would carry extra semantic meaning and would help you to leverage the type checker to make sure that this check actually gets performed.

Doing this would arguably be a bit overzealous, maybe it makes more sense to just parse strings into valid dates and merely validate that they also make sense as shipping dates. Still, any validation can be transformed into a "parse" by simply adding extra type-level information to the validation.

Why do you think it's a bad idea? Both you and OP are in agreement that you should validate early, which seemed to be what your first comment was about. Is it encoding that the data has been validated in the typesystem that you disagree with?

If you want to test windows programs on linux, you're probably going to want to do that in a virtual machine, or even a spare computer just for testing on windows. Depending on how much you need to use excel, a virtual machine could be a good option for that as well, but if using Microsoft Excel™ is a big part of your job, maybe it makes more sense to just stay on Windows for work at least

fd is a lot faster than find. This might not matter if you're searching through small directories but if you're working in a very large project it does make things a lot nicer.

RFK is a C-nile

The US government recommending memory safe languages has really given people worms in their heads

Always squashing is a bit much for my taste, sometimes the individual commits have interesting information! Text from the MR in the merge commit is great though, maybe I should see if we can set that up with gitlab and propose that we start doing that at work.