Exactly my thoughts. BabylonBee just seems like a collection of incredibly lazy political jokes. Folks in certain subreddits sure eat it up though; in some there are more BabylonBee posts than actual real content.
I spun up a test server of Pleroma recently. Following just a few people, 0 people following me AFAIK, I did join a few relays so my federated timeline is populated. It is currently showing 360MB RSS and the CPU load maxes out at ~50% of a single vCPU.
Note also that recently a fork called Akkoma[1] sprung up. If one is looking to self-host, it might be worth looking into this vs Pleroma (I don't have a horse in this race, was just doing some research on different ActivityPub servers).
Not the parent poster, but there seems to be some misunderstanding. The GitHub issue creator explained that they're getting two different behaviors depending on C compile flags. That's already not "the same behavior as Go" AFAIK.
> What kind of behavior do you expect?
Defined behavior, I assume. If V uses C as an intermediate, and the generated C code invokes undefined behavior, then V can not guarantee "no UB" in that case at all. It is completely up to the C compiler what happens. Even if the compiled app behaves "properly, like Go" with the specific C compiler, with the specific flags, on that specific machine, does not mean this behavior is defined and consistent.
Are there plans for docs to be updated? The 0.3 release notes claim:
> Option and Result are now separate types: ?Foo and !Foo respectively. Old code will continue working for 1 year and will result in a warning/hint.
Yet, doc/docs.md still states:
> V combines Option and Result into one type, so you don't need to decide which one to use.
Is there an up-to-date doc, or how does one find out more about these types? I found parts of the RFC overhauling the error handling [0] pretty bizarre, so I'm interested to see how the implementation turned out.
Combining them in general makes sense to me, at least to the extent of having an Optional<T> be an alias of Result<T, ()>.
There are some obvious cases where a none optional is separate from failure, like a hash map lookup or an element from an iterator. But I often also see optionals used to signal e.g. an unparseable string, where it would seem equally reasonable to return a Result or throw an error.
I’ve been writing a lot of Swift lately, and because it uses `throws` rather than a Result type, it’s made the often arbitrary choice of returning an optional value or raising an error more noticeable to me. Especially when using `async`, as pretty much everything declared `async` also throws, so if an Optional is actually what you want to return, you get some fairly gross boilerplate at the site of use:
guard let value = try await getValue() else { … }
This has turned into a bit of a ramble but my main point is that implementing Optional as a Result with void error type makes a lot of sense in my head.
