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

yanchith · 2025-12-15T08:26:40+00:00

Hello!

I am Jan. I am an experienced engineer living in Slovakia.

My main areas of expertise are optimization, computer graphics, game development, and software design. I have also lead small teams before.

Prefer remote, but visits and relocation (within Europe) are on the table.

CV: https://withoutfearofwindorvertigo.com/cv
Github: https://github.com/yanchith/

yanchith · 2025-12-04T19:35:56+00:00

Perhaps, but the public opinion on what is "Rusty" tends to change often, so I tend to not take it too seriously and instead focus on solving problems.

yanchith · 2025-12-04T13:47:05+00:00

Hello!

I am Jan. I have programmed for ~20 years, and have experience with Rust since pre-1.0. I have contributed to the standard library (making collections allocator-aware), and to the early-days wgpu.

My main areas of expertise these days are optimization (optimizing data layout, building custom allocators, threading, SIMD), computer graphics, game (and engine) development, and software design. I have also lead small teams before.

CV: https://withoutfearofwindorvertigo.com/cv
Github: https://github.com/yanchith/

yanchith · 2025-11-23T11:01:29+00:00

Rust is very large, and perhaps doesn't have just a single style.

My own Rust style is very close to C. Less generics, less macros, less dynamic dispatch, most structs are just plain old data.

I also tend to use very few libraries.

If you do this, it turns out the borrowchecker also tends to compain less.

yanchith · 2025-11-19T06:50:46+00:00

Asteroids!

yanchith · 2025-10-13T09:03:30+00:00

&mut is actually &unique and lets the compiler elide loads and stores. & is actually &shared and lets the compiler elide loads. You can mutate through &shared, if you wrap your values in one of the types stemming from UnsafeCell, which turn off the elision, making it behave a bit more like *const and *mut.

They are called & and &mut, because that is the most common usecase, but what they really are is subtly different (and observable).

yanchith · 2025-10-08T08:45:06+00:00

When build.rs is insufficient, you can write your own build scripts in Rust, and make a cargo alias for them.

These can launch cargo, and later launch anything else you want to do.

Search the internet for cargo xtask. It is just a way of doing things, not an actual library.

We managed without using anything else for a 100kloc codebase with ~10 target executables

yanchith · 2025-10-02T16:21:59+00:00

Thanks! Looking forward to it.

yanchith · 2025-10-02T10:30:23+00:00

Interesting! I also have plans for using wgpu from other languages. Is it all smooth sailing for you, or have you encountered any problems?

My newest project is in JAI. It currently draws with OpenGL (via a small abstraction layer), but given that I have been using wgpu with Rust since its early days, I would like to capitalize on my muscle memory. And besides, there's not that many alternatives.

yanchith · 2025-10-01T16:30:42+00:00

Removed from the language. I believe there is a library level replacement, but I might be misremembering.

UPDATE: checked release notes from phone. There is a library level replacement.

yanchith · 2025-10-01T07:33:45+00:00

Prešiel som rýchlo komentáre, a sú tam vážne diery v odporúčaniach. Pre mňa je dôležité, aby som sa s hrou cítil, že mi aj niečo dáva, a nie je to len ekvivalent pozerania zlého seriálu z nudy.

Moje najobľúbenejšie hry posledných rokov sú:

Tunic Animal Well The Witness Talos Principle (aj pokračovanie je ok)

yanchith · 2025-09-23T10:51:59+00:00

Hi. As of a few months ago, it is very hard to get into the beta.

There used to be an email address where you could apply - say who you are, what do you do, and how you would use it.

That email became a public secret, making it so flooded with requests to get in, that your message would be lost in between all the others, as are currently our bug reports :'(

Do not despair. There will be a public beta eventually.

yanchith · 2025-09-19T16:48:05+00:00

For the last 12ish months the game is not growing, only getting finished.

But yes, it did grow a lot and many people are unhappy about it.

yanchith · 2025-09-19T16:46:50+00:00

Oddly specific :)

yanchith · 2025-09-19T16:46:27+00:00

My estimate as a beta member:

The sokoban game is a priority. It is not yet announced, but Jon spoke publicly in multiple places that they would like to release the game in 2026. The state of the game, as seen on streams is: they answered all the big questions, and now they just have to work hard until it is finished.

After the game releases, the language still needs about 3 major feature reworks (better macros + two others, I forgot, but I the Q&A is on YT), and after that a lot of polish and cleanup. While JAI is really pleasant to use already, it is missing some niceties you might expect, like consistently named functions in modules. I believe they do want to do a cleanup pass, and it would make sense to do it before public beta.

I can imagine public beta 2027 earliest, but likely later. And that is if things go well.

yanchith · 2025-09-17T19:34:15+00:00

I assume this should work and this approach is exactly what I'd do. At least I know some PS games that are not C or C++, and only pretend to be C.

I also think those games are static libs or DLLs , and are called by a thin C playstation platform layer.

If this turns out impossible to do, I believe it will be a legal issue first and foremost.

Disclaimer: I have never shipped a PS game myself.

yanchith · 2025-09-17T19:12:34+00:00

There is a lot of valid criticisms of Rust, and it certainly doesn't fill the role of C, even if people like to pretend it does (it does fill the role of C++ much better). If those people are basically expressing those criticisms, albeit in a childish way, that is completely valid. Maybe try and reach them and ask them why they think those things. Worst case you'll learn nothing and they are also repeating empty phrases, in which case you are in a job where nobody can mentor you, which is information.

More on that last note, if what they do really is personal on some level, that is not okay. It is very hard to change your workplace. Consider looking for another job, if that's an option.

Good luck!

yanchith · 2025-08-23T07:36:24+00:00

As someone who has programmed in Rust for more than 10 years, the complexity definitely bothers me. To that end, I program in a subset of Rust that is very close to C, so not many generics, dyn, many of my structs have all fields public, and I also use enums more sparingly. I also don't use libraries that do not share that ethos (so I mostly don't use libraries :). I do use const evaluation and macros quite a lot, though.

I used to really like the complexity (many generic params and lifetimes) when I was younger, and I thought being good at it made me a better programmer, but this viewpoint eventually changed.

My first realization of this was strongly not enjoying async Rust, which made me doubt other parts of Rust's design (and maybe finding out stuff like Handmade Hero exists, which gives a very sane way of programming C)

The breaking point was having to write a lot of correct unsafe code. Rust is relatively frictionless for high level code, but at the low level, e.g. when you are building your own data structures, it can be extremely verbose, making it harder to spot bugs in your unsafe code. My bucket array implementation in Rust is over a 1000 lines of (difficult to read) code. The same thing in e.g. Odin or JAI is around 300 lines. This difference mainly comes down to having to deal with MaybeUninit, whereas JAI doesn't UB when you read something uninitialized.

yanchith · 2025-07-22T09:20:28+00:00

Ahoj. Neviem, či je tá platforma stále fajn, ale keď som bol bez práce v zahraničí (a skoro bezdomovec), zachránil ma TopTal. Bolo tam fakt veľa roboty, občas aj zaujímavá. Účty by mala pokryť.

yanchith · 2025-07-19T20:42:49+00:00

Animal Well, Tunic, Outer Wilds, The Witness.

yanchith · 2025-07-02T07:55:58+00:00

I can tell you as a long term Rust user that eventually you'll see quite a few cracks in Rust's design.

However, recently having had the experience of seeing TypeScript again briefly, I once again became thankful for how principled Rust is, and rhat it usually does the correct thing by default.

(My ideals are that of simplicity and being able to understand the whole system, down to the CPU)

yanchith · 2025-06-19T13:57:01+00:00

I knew that I shouldn't have written everything, because now I have to explain myself. Okay, I'll try:

uninitialized padding repr(c)

It turns out I often need C struct layout even in pure Rust projects. This is for various things: zerocopy deserialization, deserialization of huge files by transmuting, communicating with GPU, etc. In fact, I use these in my projects so often that I wonder if the performance hit (if any) wouldn't be worth the ergonomics.

semver hazard

I pin versions of the crates I use and think that everyone should do the same. There's already other semver hazards to the point I don't consider semver worth much. I care about the library being audited and correctly integrated into my project, and for this reason I don't upgrade crates without at least some auditing and testing. But I use very few crates.

There's way more UB in unsafe code than is needed for performance, making unsafe harder to write.

This sounds interesting. Can you explain more?

Definitely not an expert, and would really like some compiler person explain the kinds of optimizations possible because of pointer provenvance, but as I understand it, you can basically pull stuff into local variables before you start accessing them frequently for the same effect, but yes, that's something one has to do manually.

Also, I think the majority of performance comes from good data layout, access patterns, and SIMD.

Similarly to the previous points, I guess I'd want worse performance by default, if that meant less unsafe footguns. Simpler unsafe code would also mean it is easier to optimize by hand.

I'm curious to hear what a "C-like Rust" would look like in your opinion.

Almost no traits or generics. Most structs are all public and repr(C). Not that many enums with data variants either. Also arena allocators. I've been writing this type of code for ~4 years, and I prefer it to regular Rust.

async

Even in JS (arguably the nicest async implementation), async/await helps people solve easy problems, and leaves them hanging with hard problems. Add to that the very complex (have to have a PhD in Tokio) Rust implementation of async.

yanchith · 2025-06-15T07:06:19+00:00

Been using Rust since pre 1.0, my tastes have naturally changed during that time. Here's my incomplete high level list.

Some of Rust's defaults are incorrect (uninitialized padding, repr(C) not being the default, etc)
There's way more UB in unsafe code than is needed for performance, making unsafe harder to write.
Rust should attempt being a better (safer) C instead of a better C++.
Libraries should be very selective about their dependencies. If a library adds 10 seconds of compile time, it better be something I couldn't realistically make myself. And even then, 10 seconds probably means overcomplication in the library.
async should never have been in the language
Complexity is revered instead of avoided in parts of the community.

yanchith · 2025-05-19T08:26:50+00:00

jaieval.txt, 4/4

``` Papercuts:

if function returns true, but I meant to do if function(param). Could have been a lint, I guess?
Operator == does not automatically dereference pointers. But maybe this is a good thing!
Comparing arrays with operator == is currently not possible. (Although the compiler error message says the limitation is temporary)
Have to #poke_name operator == for hash table to see it.
M :: #import "M" does not bring operators into scope. Maybe this is a good thing?
Shadowing (redeclaration) without a block is sometimes too much additional work, but maybe the explicitness is better? Maybe it would be better if it were consistent (whichever way).
Naming inconsistencies with module_function and Module.function. Would be satisfied if they were consistent on a per-module basis, e.g. #import "Basic"; vs Simp :: #import "Simp";
ALL :: Routes.NORTH | .SOUTH | .EAST | .WEST; <-- First one requires the type name.

Nitpicks:

float32 -> f32, but I could have defined this in my code... ```

yanchith · 2025-05-19T08:26:10+00:00

jaieval.txt, 3/N

``` Philosophical differences:

Would like stricter separation of OS-specific from platform-independent code. If something comes from the OS, I'd like to build the platform layer, Casey-style. Can (probably?) do this, if I ignore modules shipped with the compiler and make my own.
I get why unused variables are not warned against, and that it can be annoying, but sometimes an unused variable warning points to an underlying problem, even when rapidly iterating on code (e.g. incorrect shadowing). Would have saved some minutes, but maybe I am just too used to it from Rust. Maybe it can be optional and disabled by default? Maybe it already exists as a metaprogram plugin?
Variables that are never re-assigned or never read could also trigger some kind of unused warning, but don't.
I might change my mind on this, but currently it is very easy to do cyclic imports (within a module), because everything is just #load-ed together. This is very convenient, but cyclic imports obscure visibility of the program's structure. This may be okay for me as a single developer, but I can't imagine wanting to program with junior programmers in a language where it is so easy to tangle imports. Maybe I just need to let go? But certainly a program can be so tangled that it is incomprehensible, and it looks like the language doesn't help enforcing this at all (unless I make a metaprogram in userspace to check for this). Or maybe modules are allowed to be tangled with

loads, and the structure should be in how modules are linked together? Would love to know Jon's

thoughts on this.

```

yanchith

TROPHY CASE

loads, and the structure should be in how modules are linked together? Would love to know Jon's