Companies use the same kind of systems to (poorly) automate the search for candidates, which is also spammy, inefficient, and wastes job-seekers time. This just levels the playing field.

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.

Most large instances have a support community. That seems like the suitable place to raise a moderation issue with specific a community on the instance.

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.

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.

It is a general purpose language for me. I wrote lots of little (or not so little) scripts in Rust. I wrote high performance GPU kernels in Rust. I wrote web services in Rust. It’s less hard to read and write Rust than is often claimed. Imo.

No, I won’t give you my github.

Yeah Lemmy, besides news and technology, is very quiet and I think it suffers from having communities fractured between instances, so niche interests get even less traffic than they would on Reddit. But my Mastodon feed is always busy and interesting. If it isn’t you’re not following the right people yet. I recommend some hashtag searches for things you’re interested in.

Moderation tools on Lemmy are supposedly seriously lacking. Defederation may sometimes be the only practical option even if it’s not ideal.

The larger the group of people gets, the more likely it is to contain toxic people. Normal distributions and all that.

Mastodon is by far the largest Fedi platform, which the article points out. So it will unavoidably contain the largest number of toxic people. Also most likely the largest number of absolute saints but that’s hardly as obvious I suppose.