Can finally put obs away for 10 second screen caps lol

Hard to not worry about it when after 2 years of applying to 2-4 every other day you get no responses. Like surely you'd think a resume with 10 years of experience would at least warrant a phone screen. I have several theories but I'm probably just another "armchair expert"

Where's the tin foil hat emoji when you need one?

But actually I might have been confusing what I'm seeing on job boards with what all the recruiters are telling me or it's a stale vibe from several months ago. Took another look at LinkedIn, indeed, dice and it seems relatively balanced if not listing more jobs with my stack like you said.

Doesn't change the fact that I'm not getting any interactions from these postings though. I finally got one response on indeed last week but after answering their questions and they said I was a strong candidate they directed me to a one way AI video interview site.. 3 years ago I had recruiters banging down my door trying to get me into interviews left and right. Trying not to rant but long story short it's not looking good for tech.

If you figure out the answer let me know. 10+ years of experience and haven't been able to find a job in the last 2 years.

Mainly looking for:

• Nodejs/Nestjs
• Typescript/JavaScript
• React/React-Native
• Rust

The only thing I'm seeing in abundance is C#/dot net. And everything advertised with PHP smells like WordPress.

Yeah Interfaces would be the next best thing.

The only reason why traits are considered better is because in languages like rust it can enable static dispatch. Whereas interfaces in C#, Java, Typescript, (and C++ via abstract classes, not templates) are always dynamic dispatch.

At that point I would argue composition/traits are the way to go.

"This extends Draggable". That's great but now we can't extend "Button" to override the click handler.

Traits: You wanna have Health, and do Damage, but don't want to implement InventoryItem? No problem. You wanna be an Enemy and InventoryItem? Go for it. What's this function take? Anything that implements InventoryItem + Consumable

It's a shame because how gitlab is basically begging to be bought out and hides a lot of useful features behind subscriptions.. I remember when it was originally just a GitHub clone way back when.

Rust was painful to look at until I started using it for more than 6 or so months

As a wise person once told the Internet, don't worry about picking the best one. But if you really had to pick one just start with the rust book. https://doc.rust-lang.org/book/ I would suggest to just dive in with a specific need you want to solve and instead of using your language of choice just use rust and look up stuff as you go. Hands on learning is usually the best learning. The only thing you need to "learn" is how to follow the ownership/borrowing paradigm that rust brings to the table.

With such a complex system like that it would probably be beneficial to actually build the parts you care about and take advantage of libraries handling the querying of Data like ECS and rendering with bevy. Otherwise you'll run into the risk of being limited by the library in one way or another.

Define a bunch of structs that you can use compositionally in bevy's ECS. Create specific systems that react to components being added, removed, or changed. Set conditions like Burnability, Durability, Temperature.. etc. React to those conditions or thresholds being met. Your reaction could even be a component. Damage(5), IgnoreArmorDamage(3), CurrencyUpdate(-5), GiveItem(Item::Sword(Stats {..}))

It basically gives you a foundation that feels like scripting but with the power of compile time safety for virtually everything. You get to "model" the data how you want instead of being limited or overwhelmed. And with ECS it really helps make things feel like Lego blocks that you can easily reuse across the entire project.

I want to say I think they are talking about how great it would be if we could kick JavaScript to the curb and just use WASM for everything. I'm kind of in the same boat.

However, WASM currently doesn't have direct access to things like the DOM, if I recall correctly (this might be the guardrails the OP was referring to?). So, it's only really good for things that are heavy on the CPU. But, as a counterpoint, I don't think it's from a lack of effort from anyone's point. The last thing I remember reading was that there were still a lot of things being worked on to make it happen.

Quick Perplexity search:

There are proposals and efforts underway to allow WASM to eventually call DOM APIs directly, without going through JavaScript. The main one is the "Interface Types" proposal which would allow WASM to bind to Web IDL interfaces.

Another related proposal is WASM GC (garbage collection) which was announced at Google IO 2023. This will allow WASM to share the same managed heap as JavaScript.