vvanders

Blueprints are a good callout(and Kismet before them). Many PLCs[1] are heavily visual language based with Ladder, FBD or other variants. I wouldn't be surprised if they were the most widely used application of visual programming languages.

[1] https://en.wikipedia.org/wiki/Programmable_logic_controller

Your point on willingness to learn is bang on. If there's no remorse or intentionally negligent then yes that's a different story.

Did the person know they screwed up? Did they show remorse and a willingness to dive in and sort it out? They likely feel like absolute shit about the whole thing and you don't need to come down on them like a ton of bricks. If that much damage could be done with a single person then you have a gap in your process/culture/etc and that should be addressed from the top.

One of the best takes I've seen on this was from a previous manager who when confronted with a similar situation as the article(it was a full DB drop). The person tried to hand in their resignation on the spot, they instead(and I'm paraphrasing here) said: "You're the most qualified person to handle this risk in the future as we've just spent $(insert revenue hit here) training you. Moving forward we want you to own backup/restore and making sure those things work".

That person ended up being one of their best engineers and they had fantastic resiliency moving forward. It turns out if you give someone a bit of grace and trust when they realize they screwed up you'll end up with a stronger organization and culture because of it.

Now if that is worth the complexity/cost is a fair debate but there are mechanical advantages to mid-drive motors.

[1] https://forums.electricbikereview.com/threads/ebike-motor-po...

Tons of awesome technical details in the post and I've always felt that Lua's co-routines are incredibly undervalued. We used to run Lua in all sorts of crazy places and it really punches above its weight.

The above quote + zoom out at the end also makes some really good observations. Some of the most powerful systems I've worked on picked a couple core technologies that were complementary with good interop rather than a one-size fits all. Will be interesting to see where Piccolo goes.

[1] https://ferd.ca/the-zen-of-erlang.html

Watchdog timers will happily kill/restart your processes that don't poke them often enough. Even in my hobby exercises I've seen I2C busses hang up often enough(and bring the whole system down!) when some protocol bit goes wrong that I think the design is actually quite inspired. As I understand it this isn't talking about known error cases(that are handled) but protocol mismatches and other things that shouldn't ever happen.

Many other comments touched on it but it's a purpose built OS, much in the same way I'm not going to build a UI in Erlang, Hubris seems well positioned for the space that it occupies.

We even had things like designers writing scripts for AI in literate programming with Lua using coroutines. We fit in 400kb of space for code + runtime using Lua on the PSP(man that platform was a nightmare but the scripting worked out really well).

Rust excels when you know what you want to build, and core engine tech fits that category pretty cleanly. Once you get up in game logic/behavior that iteration loop is so dynamic that you are prototyping more than developing.

The PS3 was also an interesting architecture(i.e. SPUs) from that perspective but it was so distant from the current time that it never really took off. Getting existing things ported to it was a beast.

Bevy really nails the concurrency right IMO(having worked on AA/AAA engines in the past) it's missing a ton in other dimensions but the actual ECS + scheduling APIs are a joy. Last "proper" engine I worked on was a rats-nest of concurrency in comparison.

That said as a few other people pointed out, the key is iteration, hot-reload and other things. Given the choice I'd probably do(and have done) a Rust based engine core where you need performance/stability and some dynamic language on top(Lua, quickjs, etc) for actual game content.

The baseline for that industry is... bad and the latest round(s) of layoffs in that industry has made it worse.

Hydraulics and attachments open up almost an endless possibilities.

[1] https://www.sota.org.uk/

[1] https://realtimecollisiondetection.net/books/rtcd/

Happened back in '11 when they were going after Android OEMs, despite the fact that the actual devices weren't infringing they still tried to get them blocked.

I just ran a couple runs to an in-wall AP + 2 1gbe port(w/ one PoE) and it's so awesome to have that all done with one cable.

FWIW if you're building something at a certain small scope ladder is perfectly serviceable.

The primary value I've seen across teams has been more on having shared team context across a codebase, if something goes bump in the night you've got a sense on how that part of the codebase works. It's also a great opportunity for other engineers to ask "why" and explain parts that aren't obvious or other context that's relevant. We'll find the occasional architectural mismatch(although we like to catch those much earlier in the design process) and certainly prevented bugs from shipping but if that's the primary focus I think a team is missing a lot of the value from regular code reviews.

The hobby already struggles with gatekeeping/driving off people who don't "ham right" and so making the hobby more accessible is a big positive in my book.

This has always felt backwards and I hope it leads to some more interesting modes across the bands.

I worked on a title where this was particularly problematic from a game design perspective(limited ram, large assets), we ended up designing in "slow" sequences to mask the disk load.

[1] https://docs.rs/tokio/latest/tokio/runtime/struct.Runtime.ht...

He didn't have a degree so in order to have a class that was accredited his co-worker(who was also fantastic) had to be the "professor of record" and they co-taught the class(since he actually had a masters and was "qualified" to teach).

Uf, feel that one. If the engine isn't designed with your genre in mind you may be making some significant structural changes(which will be interesting to see how open source engines handle that).

Even if they don't take the engine a different direction the up-leveling cost of getting new features/bug fixes is significant. Back when I was working in industry we had one person who's almost fulltime job was to merge -> fix compile errors -> fix runtime issues -> checkin change and uncover more edge cases that got broken -> repeat process, it was brutal.