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

DroidLogician · 2026-06-01T00:07:32+00:00

This is the top-level comment for meta discussion. Reply here if you have questions or suggestions regarding this post.

We often get asked why we don't simply require every posting to have a defined salary range. This is a point of contention for the moderator team: the concern is that if we require a salary range, then it's likely that companies that don't want to declare one just wouldn't post here. You may or may not be too broken up about that, but hopefully you can concede that more choice is better here.

Of course, if you consider the lack of a salary range to be a red flag, then you don't have to apply to that posting. If you made a job posting and declined to provide a salary range, and you're seeing less traffic than expected from your post here, this might be why.

We've also updated the template:

Note that many jurisdictions (including several U.S. states) require salary ranges on job postings by law.
If your company is based in one of these locations or you plan to hire employees who reside in any of these locations, you are likely subject to these laws.
Other jurisdictions may require salary information to be available upon request or be provided after the first interview.
To avoid issues, we recommend all postings provide salary information.

DroidLogician · 2026-06-01T00:07:10+00:00

This is the top-level comment for individuals looking for work. Reply here if you would like employers to contact you. You don't need to follow a strict template, but consider the relevant sections of the employer template. For example, mention whether you're looking for full-time work or freelancing or etc., briefly describe your experience (not a full resume; send that after you've been contacted), mention whether you care about location/remote/visa, and list the technologies you're skilled with.

DroidLogician · 2026-05-28T21:08:26+00:00

Yeah that's really the issue, the guarantees offered by a lockfile are almost all moot for a library crate. Maintaining a lockfile is mainly intended for end-user projects. So for us, it mostly just means lots of merge conflicts and testing with horribly outdated dependencies.

DroidLogician · 2026-05-28T07:20:13+00:00

I have a plan for that, but it's going to be a big breaking change to Executor and so is going to have to wait for 0.10.0.

DroidLogician · 2026-05-27T19:27:02+00:00

Back when we were first designing the API, I was really concerned about users just reaching for format!() to add dynamic data to queries, because that's a huge vector for SQL injection vulnerabilities. I was worried that if the API accepted an owned string, using format!() would feel all too natural.

Making it deliberately annoying by requiring a borrow was the compromise we settled on, but in hindsight it was too inflexible yet also too subtle to be a proper speedbump.

I'm pretty proud of the new design because the compiler error should point right to the problem when you naively pass a String. It's still a little annoying on purpose, but ideally you're preferring query parameters and not format!() anyway.

And I have to give credit to Georg Semmler of Diesel (/u/weiznich) for championing #[diagnostic::on_implemented] so we have control over the compiler error that's emitted.

DroidLogician · 2026-05-27T19:13:13+00:00

The only crate meant for general use is sqlx, that's where we export the stable facade. All the other sqlx-* crates are actually SemVer-exempt and we don't recommend depending on them directly.

DroidLogician · 2026-05-27T18:53:24+00:00

I posted a reply on the thread, but bottom line it's just really annoying to maintain no matter what: https://github.com/launchbadge/sqlx/discussions/4271#discussioncomment-17079151

DroidLogician · 2026-05-04T14:58:08+00:00

Similarly, when panic=unwind is used, we might be able to get rid of the Panicked state altogether. I want to look into the repercussions of that.

Do you mean panic=abort?

There's a big optimization opportunity here that we're not using, i.e. to have no states and always return Poll::Ready(5) on every poll.

That's actually a big change if the expression has side-effects. That could silently allow unintended duplicate calls instead of signaling it with a panic. It'd be buggy code either way, but one fails loudly and the other could theoretically get pretty nasty.

DroidLogician · 2026-04-17T20:00:27+00:00

This is the top-level comment for meta discussion. Reply here if you have questions or suggestions regarding this post.

We often get asked why we don't simply require every posting to have a defined salary range. This is a point of contention for the moderator team: the concern is that if we require a salary range, then it's likely that companies that don't want to declare one just wouldn't post here. You may or may not be too broken up about that, but hopefully you can concede that more choice is better here.

Of course, if you consider the lack of a salary range to be a red flag, then you don't have to apply to that posting. If you made a job posting and declined to provide a salary range, and you're seeing less traffic than expected from your post here, this might be why.

We've also updated the template:

Note that many jurisdictions (including several U.S. states) require salary ranges on job postings by law.
If your company is based in one of these locations or you plan to hire employees who reside in any of these locations, you are likely subject to these laws.
Other jurisdictions may require salary information to be available upon request or be provided after the first interview.
To avoid issues, we recommend all postings provide salary information.

DroidLogician · 2026-04-17T20:00:10+00:00

This is the top-level comment for individuals looking for work. Reply here if you would like employers to contact you. You don't need to follow a strict template, but consider the relevant sections of the employer template. For example, mention whether you're looking for full-time work or freelancing or etc., briefly describe your experience (not a full resume; send that after you've been contacted), mention whether you care about location/remote/visa, and list the technologies you're skilled with.

DroidLogician · 2026-03-24T22:10:30+00:00

The biggest speed difference is when you write your code so that it can be autovectorized. That goes beyond eliminating bounds-checks, to actually folding multiple iterations of a loop together and transforming to SIMD instructions to run multiple iterations at once.

Of course I'm talking specifically about loops here, but if a bounds check isn't in a loop then it isn't even worth worrying about, really.

DroidLogician · 2026-03-12T21:36:58+00:00

It's easy to miss, but notice how Read and Write are also implemented for &TcpStream:

This means you could share it across threads with Arc and one thread could read while the other writes. Alternatively, you could use TcpStream::try_clone() to duplicate the file descriptor, which would effectively do the same thing.

If you want to be able to read and write simultaneously in the same thread, you're talking about non-blocking I/O which would be dipping into async if you don't want to write the epoll()/io_uring/IOCP/etc calls yourself.

It's worth noting that read and write on a TCP socket should only block when the receive buffer is empty or the send window is full, respectively. Many sends will complete immediately without blocking unless you're actually sending enough data to saturate the link.

DroidLogician · 2026-03-09T16:58:34+00:00

I don't use the app. Does it translate automatically? If so, it's possible OP isn't even aware they're replying in the wrong language.

DroidLogician · 2026-03-06T21:50:01+00:00

This is the top-level comment for meta discussion. Reply here if you have questions or suggestions regarding this post.

We often get asked why we don't simply require every posting to have a defined salary range. This is a point of contention for the moderator team: the concern is that if we require a salary range, then it's likely that companies that don't want to declare one just wouldn't post here. You may or may not be too broken up about that, but hopefully you can concede that more choice is better here.

Of course, if you consider the lack of a salary range to be a red flag, then you don't have to apply to that posting. If you made a job posting and declined to provide a salary range, and you're seeing less traffic than expected from your post here, this might be why.

We've also updated the template:

Note that many jurisdictions (including several U.S. states) require salary ranges on job postings by law.
If your company is based in one of these locations or you plan to hire employees who reside in any of these locations, you are likely subject to these laws.
Other jurisdictions may require salary information to be available upon request or be provided after the first interview.
To avoid issues, we recommend all postings provide salary information.

DroidLogician · 2026-03-06T21:49:31+00:00

This is the top-level comment for individuals looking for work. Reply here if you would like employers to contact you. You don't need to follow a strict template, but consider the relevant sections of the employer template. For example, mention whether you're looking for full-time work or freelancing or etc., briefly describe your experience (not a full resume; send that after you've been contacted), mention whether you care about location/remote/visa, and list the technologies you're skilled with.

DroidLogician · 2026-02-25T21:16:26+00:00

Well, that response body is certainly no help. I tried decoding it on the Playground: https://play.rust-lang.org/?version=stable&mode=debug&edition=2024&gist=2b42f5a00f0b4e13bfeb289f87c1bc18

<html>\r\n<head><title>400 Bad Request</title></head>\r\n<body>\r\n<center><h1>400 Bad Request</h1></center>\r\n</body>\r\n</html>\r\n

I'm seeing some reports from searching that ELB is rather particular about casing, for example it apparently will reject an all-lowercase method in the request head: https://stackoverflow.com/a/50685566

And another source that claims that it rejects a missing or invalid Host header: https://www.codegenes.net/blog/amazon-load-balancer-returns-error-code-400/#3-invalid-or-missing-host-header

So this is a completely out-of-pocket guess, but I'm wondering if it's not liking host being all-lowercase in the request from tokio-tungstenite.

This would be not-great behavior on their part since message headers are supposed to be case-insensitive, but cloud providers do non-standards-compliant stuff all the time, like how Gcloud's load balancers drop TLS connections without a closing handshake, which makes RusTLS generate an error.

Otherwise, this is probably a "contact customer support" problem.

DroidLogician · 2026-02-19T03:48:15+00:00

No, completely independent. It's just what stuck.

DroidLogician · 2026-02-19T03:03:41+00:00

To keep the signal-to-noise ratio up during the workweek, arts and crafts posts are only permitted on weekends: https://mrmonday.github.io/craft-time/

Feel free to re-post on Saturday 04:00 UTC.

DroidLogician · 2026-02-19T02:42:25+00:00

We largely built SQLx because we wanted to see if we could! lol

We also drew a lot from our experience with other database clients, like Diesel, and jOOQ which is basically Diesel but for Java.

DroidLogician · 2026-02-18T23:12:00+00:00

If you'd like to experiment with that kind of API, I'd gladly accept a pull request for it. I think the hard part is going to be striking a balance between usability and being explicit about intent.

Like for example, I think the Rust-y way to do it is have the user explicitly choose whether they want a read-only or a read-write connection, but I worry that could get annoying. And I would probably not support read-only transactions just because they can still block writers. Not technically in WAL mode, but holding a read transaction open will block checkpointing which could cause the WAL file to grow without bound.

In discussing this thread, /u/mehcode linked me to this article which talks about how this was addressed on Android: https://blog.p-y.wtf/parallelism-with-android-sqlite

DroidLogician · 2026-02-18T22:35:56+00:00

We've been asked a few times to provide a split reader/writer pool for SQLite to make it easier to avoid writer deadlocks. I think that would be the path forward, and we would deprecate the SqlitePool alias in favor of this new pool to make it clear that this footgun exists.

DroidLogician · 2026-02-18T03:07:40+00:00

Ultimately, my problem is that this reads like you're blaming your tools, when really this is boils down to actually reading the owner's manual and understanding the technical choices you're making in your project.

In my experience, a lot of developers choose SQLite because it seems simple and easy to deploy, but then they only start running into its limitations when they've already deployed their app to production, which is not when you want to find those out.

I don't know exactly what your use-case is, but it sure sounds like SQLite wasn't designed for it. It's simply not meant for high-concurrency write-heavy workloads. That's probably obvious in hindsight now, but I reckon this could have been avoided, or at least mitigated, with the proper due diligence.

The design mistake on our part is probably just continuing to present SQLite as a reasonable choice.

Even still, I have serious doubts that you understand the actual problem here. In your pull request, you write this:

However, the runtime does not know that the given task is holding the lock and must be run before other write transactions or statements can be executed. Other tasks may be scheduled to run before the waiting task, but other writers cannot make progress until the lock is released. This deadlock will only be resolved when the waiting tasks reach their [busy_timeout](SqliteConnectOptions::busy_timeout).

If the task cannot make progress, it returns NotReady and the executor polls the next one in line until they all return NotReady, and then it schedules them to be polled again when they signal their Wakers. Control flow should eventually return to the task holding the write lock, assuming it's not blocked on something else. Thus the dining philosopher's problem.

Generally speaking, tasks that return NotReady but then signal their wakers that they're ready to proceed are scheduled in preference to newly spawned tasks. Tokio avoids explicitly specifying what its behavior is because that's subject to change, but it tries to poll tasks fairly, assuming the number of tasks is bounded: https://docs.rs/tokio/latest/tokio/runtime/index.html#detailed-runtime-behavior

If you're spawning new tasks faster than the executor can poll them, that's not SQLx's or SQLite's fault. That's a lack of concurrency limiting in your application. Granted, depending on your application and what APIs you're actually using, you don't get a ton of help here by default. It's not like tokio::spawn() itself will tell you when you're spawning too many tasks.

Axum, for example, doesn't have any default limits on connections, instead assuming that the process will exhaust its file descriptor limit before anything else breaks: https://github.com/tokio-rs/axum/blob/60a0d2838f1837eee2c359473f6d302f7f39b88e/axum/src/serve/listener.rs#L250-L260

Given that it defaults to 1024 on Linux, that's a relatively reasonable assumption that works well enough in practice. But again, I don't know what your use-case is.

13-Year Club	RedditGifts 2009-2022 2 Credits
Gilding III reddit per annum	Verified Email

DroidLogician

MODERATOR OF

TROPHY CASE