vvanders

It's pretty decently deployed as far as I'm aware and I've yet to find anything that is in the same class without getting into some of the more esoteric modulation schemes(although LoRA is pretty impressive on it's own, for instance the different spread factors are orthogonal so you can have multiple devices transmitting at the same time without colliding if they use different factors).

I've found the AT modem command[3] based modules[1][2] to be fairly drop-in and usable, I was even able to pair via BT on my phone and use the BT serial TTY to send/recv without any specific software. It's pretty hard to beat ~$20 modules that you can just drop in and run over UART.

Keep in mind these are mostly for point-to-point although if I remember correctly you can also configure them for a standard LoRA deployment through that command interface as well.

[1] https://store.rakwireless.com/products/rak4200-evaluation-bo...

[2] https://www.seeedstudio.com/LoRa-E5-mini-STM32WLE5JC-p-4869....

[3] https://docs.rakwireless.com/Product-Categories/WisDuo/RAK42...

Games and Applications aren't that far apart, most titles will be developed on existing engines that are predisposed to certain genres/constraints and will need to work within that the same way that UI frameworks limit what possible things an application can do(which is quite a lot).

I've spent a decent amount of time in both spaces in my career, it is totally possible to build performant, fluid applications but it requires a degree of care and investment. Usually "good enough" suffices and that's where things land but there are also developers who prioritize that and short of very restrictive environments you can build responsive applications.

Besides, at the end of the day all UI is doing is rendering, with a direct path to the GPU just like games do :).

Last time I used perforce in anger it did pretty decent with ~800GB repo(checkout+history).

I keep expecting someone to come along and dethrone it but as far as I can tell it hasn't been done yet. The combination of specific filetree views, drop-in proxies, UI-forward and checkout based workflow that works well with unmergeable binary assets still left Git LFS and other solutions in the dust.

+1 on testing this against a moderate size gamedev repo, that usually has some of the harder constraints where code + assets can be coupled and the art portion of a sync can easily top a couple hundred GB.

I got a $20 starbucks giftcard, once.

I've aware of royalties in some really, really rare cases(think north of 10M sales, in the < 1% of game sales category), but even in that case from what I heard the publisher had a cap on the upper limit per year in the contract.

I only ever saw an hourly contract once in my entire time in that industry and it took 2-3 weeks to sort out due to the fact that HR had never done one before at a pretty large-sized dev shop.

In all the places I worked there was an informal crunch period and then a very explicit one. Even during one of the formal crunch period I would catch shit for leaving at 10pm even though I was in at 8am. There was definitely a visibility aspect that if you were staying till 1-2am and rolling in at noon that was considered that you were contributing "more". There's a couple shops that do a decent job but large swaths of the industry are completely dysfunctional.

There's also a confirmation bias where if a successful game ships with crunch it is perceived as one of the contributing factor to their success and then further drives crunch across the industry.

I'm a bit over a decade removed from that industry but that largely lined up with my experiences(and from the tabs I've kept on things it doesn't seem like much has changed).

There's a constant stream of developers who have a high degree of interest in games so not only is crunch incredibly common but also compensation is significantly less(was about 1/2-1/3 standard SWE rates when I was in the industry). Combine that with publishers who pull recording industry contract style shenanigans and it's just a brutal industry. Tons of really interesting technical problems but even as someone who knew what they we going into at the time I advise people to think very carefully if it's a career option they want to pursue.

That's not technically correct(which is always the best kind of correct :) ), HWUI has been multithreaded for quite a long while now. That doesn't prevent apps from doing bad things but it's been possible to do smooth animation on Android since the days of project butter.

Yeah, I think Bevy[1] is also a great example of something that fits in well with a lot of Rust's strengths while also showing that it's possible to lean in heavily to very gamedev centric approaches with how it approached ECS.

I think there's is some truth around try to avoid unsafe, that said the times I've dropped down into it I've found myself chasing heap corruption or use-after-free on more than one occasion :).

Some of Jai's AoS/SoA transforms look neat and certainly interested to see what it looks like once it starts opening up more.

[1] https://bevyengine.org/

The explanation was good but I have a quip with treating video games as lesser. We were doing NAT punchthrough and other complex UDP NAT traversal well before STUN/TURN was an established thing.

That said most of it has centralized to so that there is an authoritative server to handle cheating which means that you can mostly get away with not needing a complex traversal these days. Some of the stuff in the early '00s did some pretty impressive things(ex: dynamic host migration when the hosting console would drop out).

Yeah Automation Direct is already in this space with their Arduino PLC[1] which has compatibility with their existing modules/etc.

I'm only adjacent to the space and have use their stuff for some home automation but from what I've seen it's more important that you can get replacement parts and reliability.

[1] https://www.automationdirect.com/open-source/home

A lot of the contexts where C++ has been deployed predate the shift to UTF-8 so I think there's actually more of a reason to have the support.

> Well… Many Rust enthusiasts treat it either as a silver bullet or everything else as unholy (unsafe).

I don't think anyone here is saying that, at least in this thread the parent(and myself) were both careful to qualify there might be contexts that it could be useful in. If you see anyone saying that Rust solves every single problem then feel free to call them out for being full of shit :).

I'm not going to be giving my designers a Rust tutorial the same way we did with scripting Lua, you're still going to have a FFI somewhere which will require unsafe and a bit more care. However having had maintained pretty significant codebases in quite a few languages I will say that Rust code is more stable, crashes less and still runs in the same footprints as C++(C gets the codesize edge by having a much smaller stdlib and surface area). It's about knowing where your tools do well and where they have rough edges and a better tool is appropriate.

Having to switch between C, C++ and Rust codebases on a regular basis I think you're underselling the complexity of C++ and overselling how difficult Rust is. C++ has a huge surface area, you have to figure out what subset you want to use(exceptions: y/n?, RTTI: ditto, stdlib or custom containers, etc). Then you get into Rule-of-5, move semantics, template metaprogramming, undefined behaviors(don't use global constructors/destructors). I could easily list 20 years of various ways I've seen C++ explode in spectacular ways(volatile semantics anyone?).

If you want to use C, Zig, or C++ more power to ya. No one is forcing you to use Rust but for those of us who are interested in a language that isn't dragged along with decades of baggage Rust offers a compelling development story and largely delivers on the areas it aims to hit(accessible systems development, memory safety and first-class tooling in my experience).

Ex-gamedev here, I have no idea what you're on about.

Gamedev isn't some place of rainbows and unicorns that makes it a unique snowflake. I spent more than my fair share of time chasing down heap corruption, invalid iterators and all sorts of other fun issues.

If anything working on a console where the compile, cook, upload, play cycle can be long having something that removes a whole class of errors would have been great back then. I don't think anyone is saying Rust is a silver bullet but it certainly has aspects that are beneficial in certain contexts.

You see it surface in SCADA/PLCs in the form of Ladder programming and Function Block Diagrams. That said from what I understand industry is trending towards more text based approaches lately.

As an ex-gamedev it was interesting to see the overlap there when getting into a bit more serious automation stuff. Edit/deploy live, visual representation of state(which is where ladder excels) and other things we used to do a lot of in game dev was present, but on physical running hardware connected to other sensors/endpoints.

There is a tradeoff in space / performance, I've just never found for my use cases it was large enough vs the significant(~10x) perf boost I got.

From what I recall in the message format[1] protocol buffers require you to walk quite a few parts of the data structures where in flatbuffers you are just reading offset and traversal is significantly faster.

Flatbuffers also let's you control data layout into the packed buffer so you can guarantee cache locality which makes a huge difference when it comes to real-world traversal performance. Data oriented design and FlatBuffers go together really well(which isn't a surprise given some of the background of where FlatBuffers comes from).

[1] https://developers.google.com/protocol-buffers/docs/encoding...

My go-to for needing to deserialize structured data in a fast way these days is flatbuffers[1]. It compacts nicely and more importantly is zero copy/allocation(within the constraints of your language where possible) in deserialize. Which lets you do neat things like mmap it from disk.

We used to store 20-30mb of animation data with it and we'd just mmap the whole file and let the kernel handle paging it in/out, worked great.

I don't know how up to date their benchmarks[2] are but my experience has been that it beats almost every other off-the-shelf solution(other than maybe capn-proto which has some similar properties).

[1] https://google.github.io/flatbuffers/

[2] https://google.github.io/flatbuffers/flatbuffers_benchmarks....

AX.25 is anything but modern. No FEC, floods easily and has other constraints.

I don't know why but there doesn't really seem to be a push to so better on FM digital modes compared to what you see with FT-8.

Yep, my favorite part of heap/stack corruption is not when it crashes immediately but rather when it rears its head 2-3 weeks/months later when some upstream call pattern or timing has changed.

I've spend weeks chasing down single instances of this on multiple projects. The nasty part is you have no predictability in if it's going to be one that crashes immediately, silently writes garbage(hopefully not to disk!), is a latent lurking crash or security vuln.

If you trash the stack then there's a good chance you lose the backtrace as well which can make a hard to debug issue become "find the needle in the haystack". I hope it's something that reproduces quickly and consistently because otherwise you're in for a ride.

Yep, it's been a while since I've been in the industry but with med-large teams your the composition of staff is such that Art/TechArt/Design are where the majority of the time/effort is going to be spent.

Last team I was on of ~60, we had 9-10 devs, if I could build tools that made our design or art team more effective that was a better use of my time(within reason of course).

Integrated engines just reflect that composition.

Realtime collision detection[1] has a fantastic chapter in this with some really good practical examples if I remember right.

Great book, I used to refer to it as 3D "data structures" book which is very much in theme with this thread.

[1] https://www.amazon.com/Real-Time-Collision-Detection-Interac...

> Plants are being regularly ordered to go into service, or remain in operation, and skip any scheduled maintenance.

If you don't schedule maintenance then your equipment will schedule it for you, usually at the least convenient time.

You can take the same patterns and apply them, it just takes a little more rigor since beam/otp had this built in.

My favorite is hardware (or software) watchdog timers. Very simple to implement and surprisingly effective.

LoRa is designed to handle hundreds of devices in the same area since the commercial use case is densely deployed nodes. The spreading factor is orthogonal so it is able to multiplex in the same frequency assuming your data rate is constrained enough for the largest spread factor.

There's a bit more on involved with gateways and coordination that you don't get in P2P mode but the PHY has the pieces you need I'd you wanted to do something similar.

We had one of the first 85D and have sold for a lot of the similar reasons.

The real nail in the coffin was that they dropped mobile service in our area. I had a to replace the 12v battery, tried to do it myself, could not get parts.

The nearest service center is a 6-8hr roundtrip for me, more than happy to pay for mobile service but they didn't offer it any more.

Either way the shift to EVs has happened, with the F150 lightning and other offerings Tesla has largely achieved one of the main reasons we were an earlier adopter.

Yup, you see the same thing in industrial automation, even Automation Direct[1] which is on the cheap end is going to be 5-10x what HD/consumer options are. That said you know what you're getting and also that you'll be able to get support/replacement parts on short notice(I had one of their flow sensors go bad on me and they RMA'd + shipped with absolutely zero hassle).

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

Back when I was in the industry there was very few games that did better than breaking even. It's the same reason you don't see a lot of independent large studios any more. If you need to hit the top 15-20% to make it only publishers who can afford to spread out the risk are able to stay afloat.

unique_ptr doesn't have any aliasing guarantees, unique_ptr::get() will happily hand out references to the interior pointer.

It does give you non-ambiguous ownership semantics which is a good thing but there's still plenty of ways to misuse/abuse it.

That said if you can make the aliasing guarantees(such as Rust's borrow checker does) that opens up the possibility of automatically applying restrict semantics[1] which enables further set of optimizations available to the compiler.

[1] https://en.cppreference.com/w/c/language/restrict

TCP forces sequencing across all packets, SCTP is a bit closer.

Let's not forget that it's modified UTF-8[1] you get back from JNI lest you think that you'll be able to use the buffer as-is.

[1] https://docs.oracle.com/javase/10/docs/specs/jni/types.html#...

It's not just how easy it is to embed, it's also really small in both code + runtime size. I've shipped it on systems with sub 8mb of total system memory(we used a preallocated 400kb block), until quickjs came along there really wasn't anything comparable. It was also much faster than anything else at the time and regularly beat v8 in the benchmarks I ran.

Unity+Unreal are the public engines out there but there's plenty of in-house engines and tool chains you don't really hear about. I wouldn't be surprised if it's still deployed in quite a few contexts.