vvanders

The fact that Rust also has a pretty-print("{:#}")[1] a single character away is also really convenient. When you're working with JSON or debug printing types it's nice to be able to format that without reaching for external tools.

[1] https://doc.rust-lang.org/std/fmt/

That's highly dependent on access patterns and domain space.

When I was optimizing for render sorting on mobile hardware we knew we would never see 2k+ drawcalls and cache aware tuning gave us huge end-user facing benefits.

I hope Godot/Bevy do well but there's a kernel of truth there as well. It was not uncommon for us to make significant changes to licensed engines to meet the needs of the game style/design. UE3 for instance was pretty awful for open world titles(gears was quite a rails shooter and the engine reflected that), there's a number of titles that took the renderer and re-did many of the major game systems.

Once you make changes like that upleveling is a serious challenge. We had one dev who's responsibility was to pull latest, spend about a month getting to to compile, another 1-2 months fixing all the issues, checking it in only to them spend another 2 months fixing all the cases that weren't tested. With a ~6mo uplevel cadence it was just enough time to finish it in order to start the next uplevel. Once you've gone through that internal engines start to look appealing(although they have their own pitfalls, I.E. heavy dependency on MAX/Maya for editor support and other "fun" bits).

IMO it doesn't really matter if they do a 180, they've telegraphed the direction they want to go. If I had a dependency on Unity I'd be evaluating my options pretty seriously to migrate off of the engine.

Hopefully it spurs further investment in things like godot and bevy.

They're still incredibly dangerous. Even with all the safety guards you've got 50-300hp being directed to a free-space shaft.

When we got a mower we went with a flail mower because we'd be mowing near neighbors and a bush hog(giant lawnmower blade style mower) will happily pick up a rock and send it with enough force to easily kill someone at a good distance. Flails tend to throw less things(which is why highway maintenance use them for mowing along the road).

It's such a sad state of things, really where ham radio should be going but instead it feels like things just get stuck in the past(unless you're talking FT-8 but even that is less about experimentation and more just another mode to get contacts on).

Elecraft gear has pretty good output/inputs but it's spendy, it's a hard ask for someone to fork out $1k for a 10-15W radio.

The whole bandwidth/symbol rate thing is also just incredibly short sighted, a number of other counties have started to change things but here in the US we can't even seem to get something as simple as that updated.

It's funny, I spent a good long while in gamedev with various visual tools(UE3 Kismet[1], node/UI editors in Maya/MAX, etc). The parallels between PLC workflow and those are uncanny.

Might be one of the few industries where I've seen visual hot-code reloading on-the-fly in production scenarios used at scale. The visual debugging of ladder is really similar to debugging tools we had, heck FBD[2] comes really close as well. Kind of an interesting covergent evolution of two different domains coming to very similar tools.

[1] https://docs.unrealengine.com/udk/Three/KismetUserGuide.html

[2] https://en.wikipedia.org/wiki/Function_block_diagram

If you're going to be installing anything in adverse environments or for any period of time PLCs are the go-to for a lot of one-off solutions. Some of them get pretty spendy quickly but Automation Direct has some reasonable($100-200) PLCs[1]. I ended up automating our entire greenhouse with one including a PID based water pump to drive a bunch of different downstream outputs that worked really well.

[1] https://www.automationdirect.com/adc/overview/catalog/progra...

+1 on ditching PowerLine, they've been shown to exceed local RFI limits by turning all your house wires into a giant radiating antenna[1] but somehow they haven't pulled them from the market. The cynic in me says this is because it only tends to impact HF bands, if they they hit > 400mhz I'm sure they'd be gone tomorrow.

[1] https://ham.stackexchange.com/questions/2032/do-ethernet-ove...

The ISM bands are much, much more limited in other countries(eg duty cycle). I agree that really interesting stuff is happening in ISM space however reallocating ham allocations doesn't seem like the right path forward.

FWIW I think repealing the symbol rate restrictions and opening up bands a bit more would go a long way towards the spirit that ham was started with. The hobby seems pretty ossified these days and it would be great to see more advancements in digital modes and stuff closer to the state of the art.

A good counter to this is having a strong technical IC leadership roles(I.E. Staff IC or similar) that leadership regularly gets input on in terms what is impactful in areas like this. The key piece is the work is low-visibility when successful and high visibility when it goes all wrong. A strong technical organization will recognize that and leverage high-judgement individuals close to the technical work so that they it can be accounted for properly.

Mekka talks about this in terms of underrepresented groups[1] but the same principals apply as well to any low-vis when successful / high-vis when it goes wrong(I.E IT, Ops, etc) roles. It's really up to technical leadership in an organization to make sure that they're noting high-impact/low-viz work and surfacing that in a way that the "new shiny" doesn't drown it out. I've been in both domains(high-vis graphics/shiny!, low-vis tooling/devx that had huge impact) and you really do need to account for it properly otherwise you'll have exactly the situation described in the article. Your company/org will falter and stumble as those infrastructure pieces slow everything down if you don't retain/reward the people doing that work.

[1] https://mekka-tech.com/posts/2018-08-09-the-difficulty-ancho...

Seeed and RAK make modules that are ~$20 and work over AT commands, however you still need to abide by ISM bands(or relevant band plan for the country you are in) which can limit your duty cycles.

The fact that spreading factors are orthogonal as well is also pretty impressive. In the ham space other than FT-8 you don't really see a whole lot of interesting modulation techniques like you do with LoRa. The fact that it works over ISM bands is pretty neat and you can do some impressive things with just a couple ~$20 AT command based radios.

I don't think anyone is suggesting shared_ptr explicitly, more that if you're coming from Python/Java/etc it's a similar to a GC memory model and a bit more familiar if that's where your experience is. I've observed in a number of codebases unless you're setting a standard of unique_ptr by default it's fairly easy for shared_ptr to become widely used.

FWIW I consider shared_ptr a bit of a code-smell that you don't have your ownership model well understood, there are cases to use it but 90% of the time you can eliminate it with a more explicit design(and avoid chances of leaks + penalties from atomics).

I've seen so may flat profiles due to shared_ptr. Rust has done a lot of things right but one thing it really did well was putting a decent amount of friction into std::sync::Arc<T>(and offering std::rc::Rc<T> when you don't want atomics!) vs &mut T or even Box<T>. Everyone reaches for shared_ptr when 99% of the time unique_ptr is the correct option.

Those disjoint memory addresses can be an absolute pain to deal with, ask anyone who had to spend time dragging performance out of the PS3 despite it being faster on paper. UMA/USM can also bring it's own set of issues when you have pathological access patterns that collide with normal system memory utilization.

For what its worth UMA/USM wasn't build to bridge a gap but rather to offer greater flexibility in resource utilization for embedded platforms, that's been moving upstream(along with tiling GPUs) over the years. With UMA you can page in other data on a use-case basis which is why they were relatively popular in phones, if you don't have a bunch of textures loaded on the GPU you can give that space back to other programs. Although come to think of it we used to stream audio data from GPU memory on certain consoles that didn't have large discrete system memory(the bus connecting System <-> GPU memory had some pretty harsh restrictions so you had to limit it to non-bursty, low throughput data which audio/music fit well into).

There are always exceptions, programming for the PS3 was... interesting given the SPUs didn't have any caches, although one could argue they were closer to DSPs with the manual DMA required. I'm not really interested in arguing semantics but more that those languages tend to be what you see modern, battle-tested OSes developed in.

My point is if you're not using C/C++/Rust what are you using that exposes those concepts? Not saying you can't do those things in other languages(I've shipped cache-aware datastructures at scale in Java using ByteBuffers + flatbuffers) however you're having to reach through abstractions and/or other limitations. Say nothing that on most OSes that C tends to be the OS ABI as well.

If you don't understand C, C++, or one could argue Rust these days you're sitting at an abstraction level much higher than where the "systems" domain tends to be. ABI, cache misses, page tables and memory mapping, restrict, all of that stuff is at an arm's length in a managed language.

One of the best courses I had was taught by Bruce Dawson, it was an entry-level "image processing" course but really it was a tour-de-force on cache hierarchies, modern computer architecture and how to build efficient real-world algorithms and not things that just scored well on the complexity scale. The first assignment was a simple bit-blit, he grabbed a random assignment from the class and in about ~30 minutes walked us through a multi-order-of-magnitude performance improvement with just small adjustments that made the program more cache-aware and also showed how you empirically test for performance improvements instead of doing it in a theoretical manner.

Back when I was in college(which was admittedly a long while back now) those sorts of things just weren't taught and that class was by-and-far an outlier from traditional coursework. My experience has been that even though there's a lot of talk about "fundamentals" in a CS degree it's touched at such a shallow layer that practical application of any of those fundamentals are missing and it doesn't "stick".

I've met all of a handful of people who can tell me what restrict does(much less how to use it), what a cache-aware data structure is or why we care about value types. ABI is just a 3-letter word to a large majority of people because they just don't have to deal with it(but are then oblivious when it blows up, I.E the number of times I've seen STL in what are supposed to be ABI-safe boundaries). That stuff is all foundational at the systems level. I've had much better luck with breaking people of their assumptions(I.E. Big-O) and working up from first-principals of how computer architecture works and structuring systems in such a way that take advantage of that instead of a theoretical ideal.

Degrees are useful but there's a whole class of things they skip over as well. When I was going to college the state college didn't teach C on a regular basis and we usually had a number of people at my community college since the course was offered there. When I was looking to transfer from community college into state not a single college offered C++(it was during peak Java) and so I didn't attend.

Even then I regularly find that so-called "fundamentals" are missing, the number of times I've had to explain page tables, how the kernel shares memory and other core details is surprising. Everyone drives Big-O notation left/right/center but can't tell what a page fault is or why algorithms with higher complexity wipe the floor with better "ideal" algorithms under actual operating constraints. I've found that engineers who have drive or innate curiosity will poke in those areas but getting a degree doesn't automatically confer that knowledge(or guarantee that it sticks).

Also, if you're getting into systems programming I care about 0% about "prestige", it's a domain that is even more binary(things work or they blow up spectacularly[1]) than some other programming domains. I care that someone understands the fundamentals, can apply reasoning and drive a hypothesis with data more than what college they did/didn't attend.

[1] https://www.usenix.org/system/files/1311_05-08_mickens.pdf

Still didn't prevent us from taking a wide berth around the idea when I was working on my first title in the industry. The studio was aware of the patent and wasn't willing to take on any risk.

Having seen a number of footguns with references and lambda captures as well where the compiler won't warn/catch I don't think it's unique to coroutines.

We were using coroutines about ~12 years ago in embedded contexts, this was with Lua which has very good support and being a managed language avoids all the footguns here while still allowing very fast interop with native code(at least in the case of LuaJIT).

I hate to drag Rust into every C/C++ conversation but this is one area where the language really keeps you within the guardrails. Callbacks are hard to use correctly in Rust, less because of the language and more just do to the messy lifecycle aspect of them. You can side-step that with shared_ptr/Arc but then you're stepping into memory leak territory when you have a circular reference(and the atomic ref counting isn't cheap either).

> A very real aspect is credits. If you're developing some SaaS product or whatever, you stay a nameless cog in the wheel, and in the worst case your entire work was for nothing because the company goes down in flames anyway.

That really depends on the studio and publisher. I saw all sorts of credit shenanigans in my time in industry, hell I spent ~3 years on a title and because I left before ship due to insane crunch all I got was "Special Thanks". I saw people from the publisher that did almost nothing get top billing while art/dev get near the bottom. I won't even get into "developer interviews" where a large majority were from the publisher who weren't working directly on the title.

IMO if you like the space do it as a side project or gamejam/indy angle, I know of very few places from my time in the industry that were "sane".

I've not been in that industry but was for a while, the closest input metric I ever saw that correlated to success was how fast your tools let you iterate on ideas to find the core of what was "fun" and the polish it until it shined. Same applied to the art side of the pipeline, the more headache importing/iterating in-engine the more things diverged from render -> in-game.

Oh and how much publishers meddled in games and/or set constraints. At one point one of the big 3 wasn't approving games that didn't have multiplayer regardless of genre, got to spend ~5mo working on multiplayer that was totally broken until we got sign-off that we could pull it from the title.

I've had to deal with fragmentation at some point or another across most titles I've shipped or larger programs. Small allocations are actually worse in some ways because they incur a lot of fine-grained fragmentation. My favorite was logic in a fairly well-known game engine that would allocate a generic name for an entity and then immediately rename it to something unique. That 5 byte allocation would be left behind multiplied by every entity cost us ~30mb of a 256mb fixed memory address space.

If you don't deal in those sorts of domains that's fine but don't dismiss them as those are some of the primary use cases for native languages. Pimpl is a hack, it's a clever hack in the context of C++ but it's not something intrinsic to native development. For instance it's a non-concern for languages like Rust(which just handle this whole domain much better due to not having to inherit a bunch of legacy behavior).

There's a bunch of feedback in adjacent threads that you seem to be ignoring so I suspect I won't change your mind here but I would encourage you to be a bit more open and consider that there are use cases where things like this matter rather than dismissing them offhand.

If you don't care about heap allocations then why are you using C++ :)

Heap fragmentation is another, pimpl works but it's really papering over limitations in the pre-processor and header model that leaks details to downstream consumers.

That gives me serious collada vibes. I've been out of the space for ~6 years but I recall that collada was the thing that was supposed to solve all of this, looks like it didn't really take off.

Flash wear says hello.

That's good to hear, I've used that in the past to drive down codesize even on non embedded targets by compiling for size and rebuilding the stdlib.

Pretty decent overview and lots of solid advice, on this point:

> So why should you, as a seasoned software developer, become a mentor?

Early in my career I got some very good advice and mentorship from a number of people that I respect who didn't have to do it but did so anyway. I pay that forward wherever I can and I only ask that others do the same.

We're better as an industry if we support and lift up our fellow developers across the board. There's a number of things that I've seen people struggle with over the years(imposter syndrome, first time breaking prod, difficult organizational issues, etc) and being able to give them the tools to better approach those things is really rewarding. If you approach it authentically with care and a positive intent you can have a real impact that lasts across someone's career and technical journey.