vvanders

Not really if you've ever driven a manual transmission. Regen usually is stronger but the drive feel is not dissimilar.

Yup, fully agreed Zig stands above others here. Cross compiling C/C++ is just a special kind of hell. Each target always has some sort of bespoke toolchain and build environment constraint that add so much unneeded complexity.

I would not include Rust in that list, in my experience rustup and cargo are miles ahead of C/C++ when cross compiling.

"Let it crash" is largely about restarting systems to known good state in an expanding scope. The Zen of Erlang[1] covers it really well, it's a longer read but well worth it if you want to understand a lot of the design choices of Erlang.

Nearly all of the devices you use employ these approaches in one form or another. A watchdog timer[2] is a pretty simple and powerful version of this. Timeouts and retries follow a somewhat similar approach, Erlang just embraces that across the whole language. It really is a fascinating approach to a different design space(latency and reliability over throughput) through the requirements a telecom stack necessitated.

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

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

Oh it's very much a thing although maybe in different contexts.

My tech director in games used to have a ~40mb static array at the top of main.cpp with a big comment along the lines of "DO NOT TOUCH". When we'd come up on a demo or critical milestone and just could not get everything to fit in the ~512mb of ram we needed because the art team put in too many textures or our new subsystem too much memory he'd go in and knock 5-10mb from it and "save the day".

The same tech director removed mip level zero to get back ~33% of our texture memory. About a week later he told the art team that we'd optimized the game and asked if they noticed any visual differences. The art team said they didn't, about 4 weeks later it got out what he actually did and they were livid.

Yeah, it's a pretty neat ecosystem. PLCs are kinda like the Legos of automation, incredibly easy to mix and match with a fair number of (insecure) standard protocols.

I briefly toyed with the idea of building out some open source hardware/software but I didn't really seem like there was enough of a userbase to make it viable. Anyone using it professionally wants support and 10+ years of parts, most maker/hobby projects want direct access to code.

Still some pretty neat concepts for putting together highly customized processes with extensible and interchangeable hardware.

One thing missing here and in most of the visual programming discussions since it sits in a somewhat adjacent SCADA industry is Ladder Logic[1].

It was pretty illuminating how many parallels ladder has with the visual and scripting solutions I'd worked with in GameDev. Hot-reload under running processes, visual debugging very reminiscent of node based visual editors. I ended up automating our greenhouse with a P100[2] from Automation Direct and was pretty impressed with how straightforward it was to use.

Structured text is making in-roads in some places from what I can tell but ladder still seems to dominate because it's easily understood and maps well to a "relay based" mental model. It seems to be very sticky, at least more than most visual scripting languages I'm familiar with.

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

[2] https://www.automationdirect.com/adc/shopping/catalog/progra...

Not really surprising, radio only works if we all play by the rules. Even a small 5w transmitter up high enough can easily cover over 100 miles.

Most radio groups tend to be disaster recovery and communication adjacent so they care about infrastructure even if it's not directly on the ham bands.

I think it depends on a lot on the studio and culture. I don't think I saw a single unit tests before I left gamedev(a few smoketests to make sure the game didn't crash but that was about it).

I also rebuilt our audio streaming system over the course of 48 hours to use the texture streaming subsystem when we exceeded the 64 file handle limit on an certain platform. We needed to hit a date for a TGS demo and I can guarantee you that we had things which were even more YOLO for a fairly decently sized team/game.

Java's MUTF-8 makes me want to eject it into the Sun. Makes interop with JNI extra fun.

> ... like they are on Fortnite or Roblox for Android, for example

Go look up dead reckoning, those types of games are built to handle 100-250ms of latency which is way outside a frame/tick.

Bruce Dawson taught a 100 level class at the college I attended, it's been a while but I think the class title was something around image processing. The first or second assignment was to copy one image region into another, little did we know that we implemented bit blit.

After turning in the assignment the next class he grabbed one random assignment from the class and added some quick benchmark instrumentation and if I remember right then asked the class how fast we think it could run. The next 30 minutes was a total geek out on cache lines, prefetching, alignment and all the other dark arts of performance optimizations. I don't remember how fast he got it to go over the naive for loop but it was many orders of magnitude. There's a few classes that really stick with you and that was definitely one of them.

The HD2 from around that era was also a stand out. I still remember seeing one for the first time and just being floored by the 4.3" form factor.

https://en.m.wikipedia.org/wiki/Radio_propagation covers it a little bit. The short answer is that wavelength(aka frequency) vs raindrop size causes signals to scatter instead of attenuate and you can pick up a fraction of the original signal.

Yeah, a lot of this is providing visibility to low visibility high impact work or Anchoring[1] work so people's impact is correctly reflected as a part of whatever review process an organization does.

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

I think we're working from different definitions of learning curves. I include in the learning curve understanding your memory ownership model, not introducing use after free, heap corruption or other failure modes.

I would argue that if you don't understand the ownership of your data you don't really understand C++(or C) and you're still learning the language. That's usually the big shift I see when developers who have a background in higher level languages moving down to C++. I've seen plenty use after free and heap corruption happen in C++0x11 and onward codebases both staying completely within modern best practices and when code diverges since there's no guardrails(ex: std::string::c_str, std::unique_ptr::get and the like).

Once you include all the footguns that exist(yes, even in modern C++) and the legacy parts of existing codebases or code that diverges from modern C++ that's why I think it has a much higher learning curve to be producing code that is at the same quality as a passing compile from Rust in aggregate.

Shared ownership is code smell to me regardless of the language, I think Rust just makes it a bit more high friction.

Language difficulty I'm having trouble seeing how C++ isn't harder there. You have decades of features, lots of gotchas that I could rattle off and a bunch of implicit behavior that you only learn about when it blows up at runtime(if your lucky). Heck, I've seen heap corruptions stay latent in codebases for 6+ months only to have a new field added that causes them to cascade into a failure that took 3 weeks to debug across 2 different teams. I've still seen modern compilers not catch basic use after free scenarios in code today.

I won't disagree that you can get code to compile quicker in C++ but if your goal is feature velocity you're better served by a high level language. If your goal is stability, performance and memory which is the domain of systems programming then I think C++ has a bunch of hidden failure modes that Rust frontloads in an elegant way.

There are projects where you'd pick C++ for portability on platforms LLVM doesn't support or momentum with existing codebases but if I had to pick between the two my personal bias is towards Rust for all the reasons above.

Yeah, but rightly so those are "escape hatches" because you can leak memory with Rc/shared_ptr.

With C++ unless you have someone experienced on a team there's a host of "unknown unknowns" that feel like the team is making progress but then having to pay the cost when it blows up and usually when schedule pressure is near the highest point. Same for the build systems, retrofitting LTO is not a fun experience.

Rust in contrast calls out many of those things upfront, I've found those guardrails prompt conversations in tradeoffs and conscious choices(to say use Rc/RefCell) you'd be making anyway in C++.

> C++ has complexity, but has the benefit of a gradual learning curve. You can start with C, slowly add `virtual`, then add templates, then add the STL.

Having seen teams go Java -> C++ and other teams go C -> C++ I don't really think that's the case. The former leans on shared_ptr everywhere, the latter ends up hitting footguns with implicit behavior around move semantics, RAII(seen more than a few use after free here) and the like.

ASAN and other tools help, but assume they are run regularly and kept to a level of rigor I haven't always seen in codebases.

Having written C++ in one way or another over the last 2 decades I still get burned by that surface area.

Last week it was a combination of forgetting the exact specifics of RVO hitting the implicit copy constructor that was causing things to go sideways. The number of implicit behaviors are pretty wide and things like move semantics still feel pretty brittle.

Having worked in both domains on the technical side one thing they share in common is no one really knows what makes something "fun" or makes UI/UX "intuitive". There's no sure-fire formula and the most successful approaches I've seen require extensive experimentation and iteration.

To take that further the most successful teams weren't the "smartest" or the "hardest working" but ones that had the fastest iteration loop. It drives everything else about the process, relentlessly optimize that loop and it was like a superpower that enabled teams to take more chances at whatever difficult thing they were trying to solve.

> Also the argument that it's "grueling 80+ hour weeks day in and day out is" is bullshit! The only time I ever worked 80 hours in a single week was when I was starting out in Quality Assurance and I was getting paid hourly so I was happy to make the extra overtime.

Sorry but I'm going to call bullshit on your bullshit. Spent ~5 years in the industry and every place I worked crunched like hell and every place that my coworkers came from crunched like hell. There are companies that limit crunch but they are few and far between.

My experience was that those who survived crunch perpetuated a culture of needing to "pay your dues" and you weren't a "team player" if you didn't put in the extra hours on salary.

Ah damn that's a real shame, something to be said about how rarely restrict is used(I usually only touched it for particle systems or inner loops of components where I knew I was the only iterator).

One of the things I'm really excited about for Rust is restrict semantics are baked right there into the language with &mut/&. I think there were still a few LLVM bugs to flush out(because very little C/C++ code uses restrict by nature of how it subtly explodes when you get it wrong).

In theory when they sort that out Rust should be able to turn on restrict where it applies globally "for free".

Yeah, I automated some stuff out in our greenhouse, I ended up going with a PLC[1] which is a bit more robust and designed for reliability and industrial environments. They're very much like (expensive!) lego bricks that you can easily throw together + program.

The PLC sends me a mail each morning with how much water it used, the max temperature of the water pump(I repurposed a RV water pump with a PID PWM + SSR driven from the PLC) all running from a 24v solar system. They're very much designed to be in-the-loop on systems that need to be robust with pretty extensive error report/alarms and the like.

[1] https://www.automationdirect.com/productivity/p1000

Look into community solar in your local area. It's utility scale solar and you usually get an offset or pays back to shares depending on how it is structured.

Can confirm that Lua does run in WASM in the browser: https://github.com/vvanders/wasm_lua

I sometimes wonder what the world would be like if Lua had zero based indices and saw a bit broader adoption. It's such an easy language to embed/extends although QuickJS looks like it's going to give it a run for the money in the long term given the similar goals on ease of embedding.

I wonder if anyone has compiled QuickJS to WASM and run it in the browser.

I think we're mostly arguing about how useful the various approaches are. At least for me print debugging is a measure of last resort unless I want to extract some historical data out and I know it won't influence the timing of the issue I'm trying to chase down.

With print debugging your inserting the whole build + deploy + repro setup loop into your debugging, if that's a long time(say 20 minutes in one job I had with production hardware) you're in for a world of pain. I find that just about any other tool usually is an order of magnitude more efficient.

Also even the "step debugger" tools do the same thing you'd do with a print. LLVM for instance uses the IR JIT API to generate watch/eval values: https://releases.llvm.org/9.0.0/docs/ORCv2.html#use-cases

IMO you should relentlessly optimize your iteration times, that's the inner loop of development speed and print debugging fares pretty poorly in that area for all the reasons above.

> typically not as general-purpose as print

In my domain which doesn't usually cover distributed systems printf can be worse because it introduces synchronization primitives that have caused race conditions to disappear(and that race condition causes second order heap corruption or the like). On one platform system memory was so small(8mb total) that each output to stdout went over the serial link slowing performance down to 1/20th of a realtime process under any real logging.

Like I said, different tools for different uses, and really depends on the context. If there was one size fits all then we'd just use that but the diversity of debugging tools I think shows that you need a variety of techniques to approach the problems we encounter.

You seemed to be drawing a parallel between no-code -> "not as powerful", in my experience they're different tools for different use cases.

I also don't think they're nearly as no-code as you call out. VS' watch window has very few limitations compared to printf back when I was working on win32 things.

Also important to consider iteration time. I once worked on a system where adding a printf was a 20 minute process due to the need to heavily optimize for a memory constrained platform(scripting fit in 400kb block with the asset bake step).