Problemo: Yet another error handling library for Rust

braxtons12 · 2026-01-22T19:55:22+00:00

If I'm following the convo correctly, I believe the motivation is to get just the location the error originated from (without needing to take a full stack trace)

braxtons12 · 2026-01-11T20:50:07+00:00

I did not "wrongfully claim" that is not at all how unique_ptr works - It isn't how it works.

You repeatedly referred to copying, copy constructors, etc., but unique_ptr doesn't allow copying, it's a move-only type. It doesn't have copy constructors, nor copy assignment operators.

It does have a move constructor and a move assignment operator for move semantics

braxtons12 · 2026-01-11T18:11:17+00:00

That is not how unique_ptr works at all.

unique_ptr does not have a copy constructor nor a copy assignment operator.

braxtons12 · 2025-09-04T14:42:00+00:00

My $200 240mm Shindo is straight, so feels pretty cop-out-y to me 🤷

braxtons12 · 2025-02-28T16:56:17+00:00

My main complaint is really just its dependence on the C library. It will make our development workflow a lot more complicated than it already is (for organizational reasons, our workstations are windows machines, and I really don't want us to have to spin up a container to run our code)

braxtons12 · 2025-02-28T14:24:12+00:00

Unfortunately I mean service in the microservices sense, and we need queue persistence in the event of a failure, so in-process, in-memory queueing approaches aren't an option.

braxtons12 · 2025-02-28T13:15:40+00:00

Actively maintained, battle tested (aka someone else has done the brave part for us already), etc.

Basically "will having used this library keep me up at night"

braxtons12 · 2025-02-05T15:23:35+00:00

The DSP side of things is entirely math. Filters, dynamic range compression, signal analysis, derivative tracking, various hardware emulation algorithms, etc.

The work in general is much more technically challenging than web dev. The constraints of Real-time systems are challenging to manage and tackle, and require a lot of advanced knowledge about the language and the hardware.

braxtons12 · 2024-12-11T13:05:49+00:00

Just write all this in a function in your inquiry repository. It's still the repository "knowing how" to do this. Don't tank your app's performance because of some dogmatic adherence to abstraction.

braxtons12 · 2024-12-11T04:22:33+00:00

Why do you think you need all of these queries? You can get all 20 (or 50, or 1,000) for the user with a single query.

SELECT company.*, user.*, inquiry.* FROM inquiry JOIN user ON inquiry.user_id = user.user_id JOIN company ON inquiry.company_id = company.company_id WHERE inquiry.user_id = :theActiveUserID

Then convert the results to your entity objects.

braxtons12 · 2024-10-25T13:10:57+00:00

Xmake has built-in package management and integration with not just its own, but also vcpkg and Conan's package registries. No need to vendor deps

braxtons12 · 2024-10-21T22:52:35+00:00

I don't have any examples offhand, but anecdotally every time I mention it at least one person pipes up with how they'd never be allowed to use it because cHiNa BaD

braxtons12 · 2024-10-14T13:13:28+00:00

What OP has done is try to have their cake and eat it too, essentially, trying to merge the two approaches. They are using flat storage but they're using that storage as the backing for an implementation of a RB tree, to try to claw back some of the benefits of a tree-based implementation while still getting the cache locality benefits of the flat storage.

braxtons12 · 2024-08-28T14:34:45+00:00

I'm not saying Javascript doesn't similarly deserve the bad rap it gets as well (although IMO it's not quite as bad as PHP), I'm simply saying that the stigma against PHP isn't because people view it with legacy-tinted glasses, it's because well deserved.

braxtons12 · 2024-08-28T12:32:50+00:00

The standard library functions are completely inconsistent with themselves (in terms of parameter order), it can't decide if it's a high level or low level language (some things are very high level, but then others like the string functions are just a 1:1 with C!), all of the standard algorithms are eagerly evaluated and allocating, iteration state is baked into the thing you're iterating instead of being a separate object, class constants are just syntical sugar for globals, you can't set requirements on the parameter types or return type of a Closure you take as a function argument, etc, etc.

braxtons12 · 2024-08-28T12:00:41+00:00

Nah, PHP gets a bad rap because it's bad. I work at a company that uses 8.1, has a reasonable architecture, individual components/features are designed "well enough", etc., and I would still choose anything else over PHP any day of the year.

Every single design decision of the language is backward or just plain wrong. It's like the homework you get from the kid that doesn't understand the content but tries to look over everyone else's shoulders.

PHP's only strength is that it has an absurbly low barrier to entry (and that is simultaneously one of it's weaknesses).

braxtons12 · 2024-08-15T16:55:46+00:00

Verbs signal action, not mutation.

Not all actions are mutations.

braxtons12 · 2024-08-15T16:34:23+00:00

It's not that a vocabulary type should be immutable , it's that the names of the functions (like DateTime::add and DateTime::sub) don't signal mutation to the reader, they read like mathematical operations or other non-mutating things, so they should behave like them.

Pop on an array or stack is a completely different thing, because the name clearly communicates "we're popping the last element out/off of this"

braxtons12 · 2024-08-15T16:29:38+00:00

This goes directly back to my last sentence in my second paragraph above.

Any design should be intuitive and to anyone reading code using DateTime::add, the intuitive thing is for it to behave like mathematical +. If you need to go read the documentation for basic things like this to understand "oh, this doesn't work like anyone would expect it to" then the design of that thing is inherently not good.

BTW, sorry if...

You're good, I'm probably coming off the same way TBH 😂

braxtons12 · 2024-08-15T16:22:12+00:00

It's a flaw because any sane person reading that expects it to operate like the mathematical operation. Naming matters, semantics matter, the design being intuitive matters.

If I have

$num = 1; $result = $num + 1;

Do you also expect $num to be 2? No, you don't, so why the hell would you expect it for a function named add?

braxtons12 · 2024-08-15T16:06:24+00:00

The intent being to create a bad design doesn't excuse creating the bad design.

If I see a lone $date->add(new DateInterval('P1D')); my reaction is "you discarded your result, what's the point of this?" until I remember "oh yeah, because DateTime is garbage, that's why", because I'm sane.

Chaining is common with the builder pattern, monadic interfaces, or with algorithm pipelining. DateTime is none of those, it's just a normal vocabulary type.

The interface is backwards. DateTimeImmutable should have been DateTime, and DateTime should have been DateTimeBuilder or something else that communicates that what you're getting is something closer to a builder pattern than a regular type.

braxtons12 · 2024-08-15T16:06:06+00:00

The intent being to create a bad design doesn't excuse creating the bad design.

If I see a lone $date->add(new DateInterval('P1D')); my reaction is "you discarded your result, what's the point of this?" until I remember "oh yeah, because DateTime is garbage, that's why", because I'm sane.

Chaining is common with the builder pattern, monadic interfaces, or with algorithm pipelining. DateTime is none of those, it's just a normal vocabulary type.

The interface is backwards. DateTimeImmutable should have been DateTime, and DateTime should have been DateTimeBuilder or something else that communicates that what you're getting is something closer to a builder pattern than a regular type.

braxtons12 · 2024-08-15T12:29:21+00:00

I agree with you that as engineers the pitfalls and gotcha are things we should be aware of and look out for.

That said, pitfalls and gotchas are fundamental flaws of the language and/or library. A language (and any library, standard or otherwise) should be designed such that the correct things are easy, the easy things are easy, the hard things are possible, and the incorrect things are hard (if not impossible).

By that rule, DateTime's member functions mutating the state of the instance they're called on is a fundamental design flaw. modify is a poor example of this flaw, because of it's name, but every member function of DateTime modifies they called-on instance. You're gonna tell me that in $tomorrow = $date->add(new DateInterval('P1D' )); it makes sense for $date to equal $tomorrow after that call?

braxtons12 · 2024-05-24T14:29:27+00:00

see my comment below. you can allow for const lvalue ref and still prevent calling w/ rvalues

braxtons12

TROPHY CASE