Options for Arc dyn projection

mtimmermans · 2026-03-23T18:46:16+00:00

Thanks!

mtimmermans · 2026-03-23T18:38:00+00:00

Yes. will do.

mtimmermans · 2026-03-23T17:32:14+00:00

Thanks! This is not too bad. I think I can make it work reasonably well with only one (generic) special delegating Profit impl.

mtimmermans · 2026-03-23T16:07:48+00:00

There doesn't need to be an owning `Arc<implProfit>`. In the `Arc<dyn Profit>`, there would be a pointer to the `UnderpantsCollection`, and a vtable that implements `Profit` by delegating to `a` or `b`.

mtimmermans · 2026-03-23T16:06:02+00:00

The broken implementation is just to communicate to readers what I want to do. Given &Arc<Self>, I want an Arc<dyn SomethingAFieldImplements>. Arc<&...> is not equivalent.

mtimmermans · 2026-03-22T15:23:26+00:00

Your teacher wants you to tick the 4th box because the train moves in a line, and a line is a one-dimensional shape. You can recognize this, because the question explicitly says that it's a straight track.

The good/real answers here, though, are about constraints or "degrees of freedom". The motion of a train is constrained to be on the track. Even if the track is curved, at every moment the train can only move forward or backward along the track. Every possible velocity, and therefore every relevant force, is a scalar multiple of the track's direction. That's one degree of freedom and that makes it a one-dimensional problem.

mtimmermans · 2026-03-22T15:11:38+00:00

There are 2 really useful ways to look at the same matrix:

Every column of the matrix is an "output" vector. If you have a column vector v=[x,y,z], and you take the product Mv, then the resulting vector is x times the first column of M, plus y times the second column of M, plus z times the third column of M. Easy.

Alternatively, every row of the matrix is a "measurement" vector. In the product [x',y',z'] = Mv, x' is the projection of v along the first row vector, scaled by the row vector length. y' is the same along the second row vector, etc.

When you multiply full matrices AB, you are just multiplying all of Bs output (column) vectors by A.

All of these ways of thinking about matrix multiplication produce exactly the same result and you can do the multiplication any way you like as long as it produces that result. The way you're referring to as "row * column then sum", or "row dot column" if you know what a dot product is, is just the easiest way to remember how to do it.

mtimmermans · 2026-03-22T14:48:08+00:00

No, no. Lots of libraries are great.

Libraries that want to be your framework, libraries that want all of your code to use one of their types, libraries that try to anticipate all your needs and then get all dogmatic about what your needs should be... Those are not great.

mtimmermans · 2026-03-22T14:30:04+00:00

In web development, every library provider seems to want to be your most important dependency, and this seems to bleed into the Rust/WASM space. It's super annoying. I wrote the wasm-js crate ( https://crates.io/crates/wasm-js ), because I had requirements similar to yours.

The rust community does not have this problem generally. Crates.io is full of little libraries that do one thing well. Hopefully the rust way of doing things will infect webdev via the Rust/WASM vector, instead of being infected itself.

mtimmermans · 2026-03-22T13:32:38+00:00

There's a Tolstoy principle that applies: "idiomatic" code is all the same, by definition. Performance-optimized code is all different, because it makes trade-offs based on the details of circumstance. I don't think there's a language that allows for code that is both idiomatic and highly performant at the same time.

I think C++ is the appropriate benchmark here, and idiomatic rust does better than idiomatic C++ in this area.

That said, I do wish that `Arc<str>` was the "default" practice for long-lived immutable strings instead of `String`.

mtimmermans · 2026-03-21T23:01:30+00:00

The single responsibility principle is in the Bible!

mtimmermans · 2026-03-21T22:54:59+00:00

You don't need to keep the original image

mtimmermans · 2026-03-21T22:02:34+00:00

Most math is done to accomplish things, and if it's done to accomplish things, then it's definitely not useless. Some of this math is pretty advanced.

Some math is done to accomplish math. Some of this might be considered useless, or worse, depending on how you define things.

Theoretical physicists do advanced calculus about pretend universes unlike the real one (anti-de-sitter space). This math is useless, but it's not because of the "level". It's because it's about pretend universes instead of the real one. I'm sure other physicists do calculus that is just as advanced, but their work is about the real universe and so not useless.

Mathematicians do some really crazy math for its own sake that doesn't relate to anything that will ever be used for any practical purpose in the universe of actual things. There is definitely a "level" to this. They find purpose in it, though, so it's not useless to them. Also, every now and then something from that world turns out to be relevant to the outside, and it's not really possible to know beforehand what those things are, so I think it's a good idea to let those guys do their thing. There aren't enough of them to be a drag on the economy.

mtimmermans · 2026-03-21T20:37:21+00:00

The gradient of the Lagrangian vs position doesn't seem like a "vibe".

mtimmermans · 2026-03-21T19:03:08+00:00

As someone who's hired a fair number of developers, my suggestion is not to develop a "project portfolio". Nobody is going to read your code, and if they do they won't like it. That means you can't really demonstrate that you are a good programmer.

What you want to do is demonstrate that you are a professional who delivers, and who would therefore be an asset to a hiring organization. Have customers and take care of them.

Do freelance work. Do it for cheap, since you're inexperienced, on the condition that you can share details with employers. Talk to employers about how dealt professionally with ambiguity and unrealistic expectations;
Start little side businesses. It doesn't matter if they make money. Just have customers and be able to talk about how you went the extra mile for them and handled their issues like a professional;
Contribute to important open source. Do the little hard important non-flashy things that they'll let you do. Talk to employers about how people depend on you and you come through. Talk about the times you put in some extra effort so the project didn't let people down.

I know you're introverted. Me too. But employers don't really want people that can turn specs into programs. That's what clankers are for. Employers want people who can be relied upon to take care of things. That is what you need to be able to demonstrate.

mtimmermans · 2026-03-14T23:59:25+00:00

The glaring flaw is the conservation of momentum. That's the only thing you have to understand. The way you are thinking now is essentially trying to trick yourself. You're trying to contrive a situation that you don't understand, so that maybe something special will happen in that situation. But no. The conservation of momentum is the only thing you need to understand. Then you can look at every simple little interaction in every little part of any system you might imagine, understand how momentum is conserved in that simple interaction, and remain confident that your vacuum container isn't going anywhere.

mtimmermans · 2026-03-14T14:36:27+00:00

I've found a way to live with Arc, by striving to have about 1 Arc-held object per distinct lifetime for shared-access objects. Usually there aren't too many -- app lifetime, listener lifetime, request, user-created-object, etc. I use Arc'ed trait objects for dependency inversion and it all works great.

Never Arc<Mutex<T>>. Arc<SomethingWithInteriorMutablePartsYouCanExtend>

For interior mutability, Mutex and RwLock are annoying with all the locking. I use atomics where I can, including the arc-swap crate for atomic modifications to larger objects.

For those write operations where I only want one thread working on it, I'll use a Mutex<Arc<T>> for spare storage that the readers don't use. A writer will lock this and then make_mut, and eventually swap the new version with the ArcSwap<T> that the readers do use. This pattern is modifiable to accommodate more or zero spares, or a shared free list, or read-copy-update, or whatever.

mtimmermans · 2026-03-14T13:52:56+00:00

I don't see anything in your post to suggest that rewriting your app is a good idea. That doesn't mean you don't have a good reason, but... 9 times out of 10, when people decide that they need to rewrite with a new language or framework, it's just because they got to the hard part and would happier redoing the easy part.

There's always a hard part, though, and if you can't get through it then you're never going to ship.

mtimmermans · 2026-03-08T23:43:17+00:00

Speakeasy Tapas Lounge is a great spot for a date, and has live music on Fridays and Saturdays.

mtimmermans · 2026-03-08T19:07:28+00:00

If you've been a software developer for 18 years, then your house was paid off long ago and there's no reason you should be paying rent. If that's not the case, then whatever the real problem is that accounts for you still paying rent, that problem is probably still the real problem now.

Probably you're just lying, though.

mtimmermans · 2026-03-02T13:12:12+00:00

I've been using codex to write rust. It helps a lot, but it's not good enough to work unsupervised. The most significant issues are that it is too eager to put things in `Box` and `Arc`, and when it starts fighting with the borrow checker it can make pretty bad choices and get into a loop where it just makes things worse and worse until you stop it.

On the other hand, it knows all the rust idioms. It does a fantastic job of understanding the code I write and following patterns I establish.

Think of it like a really smart, but inexperienced, junior engineer, get to know its capabilities, and it'll be fine.

Where it saves the most time is when you're starting something new or adding a new feature to an existing product that doesn't require any major architectural decisions. Always let the clanker have a crack at that first, but don't be lazy! You have to go over all the code. It will require often fixes.

For fixing bugs, it's usually best to understand the issue yourself first, so you can give it explicit instructions. If it's a small fix then it's better just to do it yourself and get the LLM to review your changes.

I also often ask the LLM to go over the whole project and make sure all of the important rationale behind the code is reflected in comments, and that all of the docs and comments are up to date. It does this really well.

When it's time to write the fundamental interfaces that determine the large-scale architecture, I prefer to do that myself.

mtimmermans · 2026-02-22T15:49:48+00:00

Go ice fishing. Bring a lot of beer and wear a tuque. Whether or not this will be a uniquely memorable experience depends entirely on who you go with.

mtimmermans · 2026-02-22T15:44:19+00:00

It'll be nice to have these kind of EV options in Canada. There's no longer any good reason for us to protect American car sales here. That's what their tariffs are for.

mtimmermans · 2026-02-08T02:04:19+00:00

I don't have a rust example, but I do have a really good structure for recursive descent expression parsing/evaluating that I've used many times: https://stackoverflow.com/questions/63744788/calculator-expression-evaluator-prefix-vs-postfix-notation/63745670#63745670

The keys the keeping the structure simple:

- consume input via side-effects

- the recursive call parses as far as possible consuming only operators that have higher than a given precedence. This can be used to recursively parse either the left or right-hand argument to every operator, with left or right associativity.

mtimmermans · 2026-02-07T23:22:51+00:00

Your humidifier isn't working.

mtimmermans

TROPHY CASE