It’s surprisingly calming to listen to Patrick cathartically vent, after what must’ve been a stressful education and career in finance.

Keep Lemmy small. Make the influence of conversation here uninteresting.

I’m doing my part!

It’s basically corporate anti-virus software. Intended to detect and prevent malware.

According to the article this system also detects power outages and shuts off when they happen. Just like full-scale solar power systems. But yeah, no physical kill switch.

I’m guessing regular non-LP DDR works fine socketed in desktops because power is nearly a non-issue. Need to burn a few watts to guarantee signal integrity? We’ve got a chonky PSU, so no problem. On mobile devices however every watt matters…

I doubt doing it in software like that outperforms sqrtss/sqrtsd. Modern CPUs can do the conversions and the floating point sqrt in approximately 20-30 cycles total. That’s comparable to one integer division. But I wouldn’t mind being proven wrong.

Well, yeah, but you asked why they didn’t use integer sqrt. It’s something many programming languages just don’t have. Or if they do, it’s internally implemented as a sqrt(f64) anyway, like C++ does.

Most CPUs AFAIK don’t have integer sqrt instructions so you either do it manually in some kind of loop, or you use floating point…

The builtin u64.isqrt seems to be available in nightly only, and additionally I guess the author didn’t want to use any external crates as part of their self-imposed challenge. Though I think there may be an off-by-one result with f64.sqrt I don’t think this functionally breaks their u64 code because they loop to root_n + 1.

https://doc.rust-lang.org/std/primitive.u64.html#method.isqrt

There isn’t even any memory management in their code. And arguably the most interesting part of the article is implementing a bignum type from scratch.

The author pointed out they also could’ve just called openssl prime -generate -bits 1024 if they weren’t trying to learn anything. Rebuilding something from scratch and sharing the experience is valuable.

And I don’t think they give out stock grants to warehouse workers, but I could be wrong.

Yeah. That’s my point. And still people take these jobs and work very hard indeed. Try explaining “limited bathroom break time” to your average tech worker.

Average Amazon .com Warehouse Worker hourly pay in the United States is approximately $16.96, which is 7% above the national average.

People don’t seem to understand the average worker would kill to make $80/hour and $200k in RSUs. Not a dream job, right.

Yeah. Tech has gotten worse. But you really think it’s better in any other sector? I’m sure there are a few highly-compensated lap-dance-inspectors out there but the vast majority of workers deal with the same shit techies are dealing with, for significantly less pay and respect, if you can believe that.

One of the developers I respect most in my career walked out on .5M in bonuses on Amazon because of their ranking system for his employees. I was shocked.

This also shows what an incredibly privileged position techies have in the job market. I totally understand quitting Amazon. Really, I wouldn’t want to work there either. But ask one of their warehouse workers if they’d ever quit and forfeit a 0.5M bonus…

Eh. I work in tech. I have friends who work or worked at almost every big tech company you’d recognize. These are still jobs, dealing with layoffs, annoying bosses, etc. has always been a fact of life. But from what I can see the average techie still has it very good compared to most other jobs. My friend who is a nurse would certainly like to earn a tech salary, not have to deal with hospital politics, and not work night shifts all the damn time, and take time off whenever they want to not whenever there’s availability…

I think Big Tech is still pretty much a dream job for most people. High pay. Perks. Work/life flexibility. It’s certainly not as dreamy as it was 5 years ago perhaps, but realistically I’d take it over pretty much anything else.

It’s not like Rust is the first language which requires you to reason about ownership. People still write tons and tons of C++. Rust is much faster to write than C++ in my experience, because ownership is checked by the compiler instead of requiring the human programmer to constantly think and reason about.

I wouldn’t write gameplay code in Rust like I posted above, but most of the complaints about the borrow checker making Rust somehow exceptionally hard to write are overblown imo. There’s a learning curve but then it makes sense.

Completely agree with all those points.

The author seems to be a enthusiastic coder and made several game engines in Rust. I’m not sure why they didn’t hook up some hot-reloadable scripting to their engine, call it good, and build games. Probably less work than writing this very long article :)

Yeah I would probably not use Bevy either if the only option is to write all gameplay code in Rust. It doesn’t seem like the best tool for the job.

I’ll grant C# is easier to iterate with. But C/C++, i don’t think so. You still have to carefully consider ownership with those, just like Rust, and refactoring can be laborious. Except with Rust once it compiles your code is probably correct, ownership-wise, which iterates considerably faster than running C++ code and getting segfaults (or data races)…

I helped ship multiple games. All of them used scripting languages, like Lua or in-house, for gameplay code. It makes sense for iteration.

Oh and C# and Java come at a cost, of course. It’s easy to write them, I’m a big fan of C#’s design, but its overuse is also how we ended up with so many relatively simple indie games which consume gigabytes of memory and constantly drop frames stalling for GC. Nothing is without tradeoffs.

For me the biggest difference between Rust and C++, for things like scripting, is cargo. Being able to just add an awesome parser, or support for a particular file-format, to my “script” with a single line in cargo.toml is awesome. In this particular way cargo is better than Python even. The amount of time spent on acquiring, setting up, and linking libraries in other languages cannot be understated.

TLDR: “I picked a systems programming language to write and iterate on a bunch of gameplay scripting. Why does Rust not meet the needs of a gameplay scripting language like <every link in the article which either refers to dedicated game-programming scripting languages, or Unity which is whole goddamn commercial game engine>. Hmm yes, the problem must lie with Rust, not with the choices I made in my project.”

Just try to write a complete game with nothing but open source libraries in C++, or C#, or Java. Good luck with that. The author is switching to Unity for a very good reason. It turns out a commercial product made by 6000 people delivers value…

You use a systems programming language to write your engine. And then a scripting language to write your game. Everybody in gamedev knows this, I thought.