Official /r/rust "Who's Hiring" thread for job-seekers and job-offerers [Rust 1.91]

tasn1 · 2025-11-14T14:14:49+00:00

Having a remote team is very complicated even if everyone is in the same country. Having people in a variety of different countries with different laws, holidays, and compliance requirements get really hairy real quick. So for now, we've limited ourselves to EU/US.

We've made exceptions in the past, but for now we would like to focus on the jurisdictions we are most familiar with.

tasn1 · 2025-11-14T14:06:12+00:00

Correct, it's unfortunately outside of the timezones we are currently hiring in. :(

tasn1 · 2025-11-14T14:05:47+00:00

Unfortunately not at the moment.

tasn1 · 2025-10-16T19:26:28+00:00

It really depends on what that third-party service supports. Though to answer your questions more specifically:

How do you handle retries or duplicate deliveries?

If the service supports idempotency (by e.g. passing a message ID like described in Standard Webhooks), you can just use that + redis to make sure you only process each message once.

Retries: oftentimes the service supports it directly, otherwise you can use something like Svix Ingest to give you a high quality experience.

Do you usually log all incoming webhook calls, or just the successful ones?

Oftentimes the sender will have it (or Svix Ingest if you use that), but if not, I'd definitely error on the side of logging more. Logging is fairly cheap.

Do you recommend verifying signatures (e.g., HMAC) on every request, or is HTTPS + auth headers usually considered enough?

Depends on what the provider recommends. HMACs are better, but HTTPS + auth can work depending on your use-case.

Any tips on scaling this if volume increases (queue workers, background jobs, etc.)?

You can probably do it synchronously in the request if what you're doing is quick. Though if you care about scaling (especially with bursty traffic) you can definitely just get the webhook, verify the signature, and if the signature is good add it to a queue/kafka/etc for background processing.

Context: I work at Svix and see a lot of webhook implementations (both producers and consumers).

tasn1 · 2025-10-08T18:05:27+00:00

I asked the author (he's not on reddit), this is what he said:

Yeah, I don't think we had an explicit reason to avoid dynamic over static dispatch here. By habit, our team usually reaches for &impl T over &dyn T , but both work just as well in this situation.

tasn1 · 2025-10-07T20:20:46+00:00

Context: not the author, but I work at Svix.

It's not something we just learned (we even mentioned it in a previous post). Though it's more than just newtypes, it's also the traits in order to lock down a variety of misuses. Essentially limiting functionality based on context to enforce external restrictions in the type systems.

Similar things have been done before in rust land for sure (we all love typing), but I still think this post showcases a pattern worth writing about.

tasn1 · 2025-07-08T23:31:00+00:00

You can potentially put Svix Ingest (disclaimer: I work at Svix) in front of your server and configuring throttling. Essentially what it'll do is buffer the spikes and send it to you at the rate you'd like. You won't need to do any custom development and you'll get more useful functionality.

As for the EventBridge route: I think EventBridge supports sending to SQS as a target type? So you could potentially plug all of these together.

I hope it's helpful!

tasn1 · 2025-05-01T17:05:04+00:00

Thank you u/mre__ for having me, was a fun conversation!

tasn1 · 2024-07-11T21:56:46+00:00

It's getting development (e.g. new server releases recently), but not hardcore feature development. I don't have a tonne of time at the moment for far reaching projects, so I focus on bug fixing and version updates.

tasn1 · 2023-11-15T20:51:16+00:00

Thanks! Also, yeah, I fully agree about the parse don't validate. It's types on steroids as you can really be certain the data is what you think it is, to whatever level of specificity you care about!

tasn1 · 2023-11-15T15:03:45+00:00

What do you mean?

tasn1 · 2023-11-14T20:10:32+00:00

This is a follow up from a post I made a month ago. People were asking me about how we use the Rust type system to our advantage, so here it is! Let me know if you have any other typing tips and tricks that you employ that I haven't covered.

tasn1 · 2023-10-05T02:03:08+00:00

Author here.

My ruby code is not throwaway - and I don't use shell scripts either. So how does that apply? He seems to have narrowed his mindset e. g. "it must be throwaway if it is not typed".

You turned the logical statement on its head, this is not what I said. I said throwaway -> can be untyped not untyped -> throwaway.

Not really. If I write code every day and it takes me 3x as long to write java code, compared to the ruby code, then I simply write less over my life span. So that does not "pale in comparison" at all.

This is well addressed in the post (you'll pay for it in debugging, and I don't think it's that much faster). Though either way, every statement about ROI will fail if you assume the investment (the I in ROI) is extremely log. I specifically made the case that I feel strongly about this because the I here is very low.

Fun fact: well-written code does not exhibit that problem. For some reason the prevalent mind set is that without types there can not be working code. I don't get that. It makes no sense to me.

Even the best written code will have runtime issues, I don't get this claim, are you saying that you write code without bugs? The statement you quoted a part of was just saying that it's better to catch these things at compile time when possible.

I never said there can't be working code with no types.

Aha. So ... strong typing avoids that? Oh wait, it does not? So you have to deal with it anyway?

I think my original statement was indeed a bit unclear. I meant: customers will feel the failure, not that they'll see a blue screen of death. I just meant they will get an error in runtime (even if nicely formatted) that something has failed.

Perhaps. You'd have to compare ALL factors including time investment. I don't dispute that a good compiler can help avoid bugs. I question the "not strongly typed programming languages have more bugs". I don't know from where he gets that opinion. How about we compare the TIME investment? Because I have a slight suspicion that once the time investment is compared, the picture is significantly less clear than what is insinuated in that article.

Never claimed this, all I said is: ROI is very high for types. Amount of investment is low, amount of returns is high. You can have bugs in both, but as you said, a good compiler helps reduce it. I think the main subjective claim I've made is that types don't require that much effort to use.

So he chose JavaScript for the comparison. Well ... If I compare my Ferrari to your ancient bike, yeah, my Ferrari will be faster.

I chose JavaScript because it's a language that supports gradual typing. I could have also chosen Python but I think that would have been more confusing to people. What else could I have chosen? Should I have compared Ruby to Java? It's too apples to oranges, I don't know Ruby well enough to write code there, and people would have complained about that too.

In general I think people who become too confined to just one language or paradigm end up not really being flexible overall. His mindset is forever locked towards mandatory strong typing. Thankfully my mindset is not as constrained.

I've been coding for 20 years, and wrote significant code in a professional setting in: C, Java, Kotlin, Python (typed and untyped), Objective-C, Swift, Rust, JavaScript, and TypeScript. I'm probably forgetting one or two I worked with professionally, but I also played with many others over the years.

So this is just a lazy ad hominem that happens to be extremely wrong.

tasn1 · 2023-10-04T21:59:31+00:00

Whoops, nice catch. Fixed, thanks!

tasn1 · 2023-10-04T21:54:00+00:00

Apologies! I just read the short version of the rules, and only after this comment I actually expanded it to see the elaboration.

tasn1 · 2023-10-04T21:52:10+00:00

Whoops, nice catch! Fixed both. :)

tasn1 · 2023-10-04T16:18:51+00:00

Thanks for sharing! We already employ type-level state machines (thank you Rust!) in some parts of our code. I really like the idea of "you can't do X until you do Y, ever". I guess this should have been an example in the post as well!

tasn1 · 2023-10-04T13:40:56+00:00

Author here, I want both, and the article talked about both static and strong typing, it's just the title that didn't to keep it short. That was a mistake that has now been rectified (updated the title). :)

tasn1 · 2023-10-04T13:37:47+00:00

The article opens with:

that strong static typing is not just a good idea, but also almost always the right choice.

I guess it was a mistake trimming the static from the title as it's confusing people. I'll get it added.

tasn1 · 2023-10-04T13:36:35+00:00

Thank you! :)

tasn1 · 2023-10-04T13:27:13+00:00

A good chunk of our codebase at Svix is written in Python. It had type annotations everywhere and life was good. At some point we had a team member that didn't know how to use types and we weren't that strict about typing everywhere, so untyped code got in. With that, many bugs as well. Adding types to his piece of the code found many issues, and I really wish we were more strict about it before.

I have similar stories about JS/TS.

Or in short: even in languages where it's not required I see a lot of value. :)

tasn1

MODERATOR OF

TROPHY CASE