[Begin Soapbox]
- If your idea of demonstrating your programming creds online is bashing Python for being “too slow”, you’re just revealing that you don’t understand your job as a programmer.
- A programmer’s job is to figure out a good language to use for the application. Notice I didn’t say, “the best language”; because there isn’t one.
- Python too slow for your application? Great. Uncheck that box and investigate any of the innumerable other languages out there.
- There’s not a good language for your application? Some Really Good programmers create their own language. Other Really Good programmers just use assembly for fuck’s sake. If Margaret Hamilton can land people on the Moon in 1969 using 16kB of government hardware, you should be able to code a video game with computers several billion times more powerful. Or just ask ChatGPT to do it for you. I’ve read good things about it online.
- Never underestimate the utility of just requiring everyone to buy faster hardware to cover up crappy programming/business decisions. It’s been done since the first caveman programmed a computer by striking two transistors together.
- Most programmers have to make due with what they’re provided with at work. If you’re at work, get back to it and figure out how to solve the problem. That means stop your posing online about “there’s no programming language good enough for my application”. If explaining to your boss that you need a different approach didn’t work, work on your resume instead.
[End Soapbox]
OP wants to build a game. When I build games, I start high level (Python, Lua, GDScript, etc), then move the slow, stable bits to something faster. That’s a really effective flow, and at the end, I get a great scripting interface for my game.
But then, given the complaints, I’m not actually sure they do want to build a game, I think they really want to build a language, and maybe an engine.
… I start high level (Python, Lua, GDScript, etc), then move the slow, stable bits to something faster. That’s a really effective flow, and at the end, I get a great scripting interface for my game.
That’s the way to do it. “Premature optimization being the root of all evil” and all. Something that is slow but works is always better than something fast that doesn’t.”
But then, given the complaints, I’m not actually sure they do want to build a game, I think they really want to build a language, and maybe an engine.
And there’s nothing wrong with that. I personally find no interest in programming for programming’s sake. I need a problem to solve first. But what if I don’t have a problem to solve? Create one! Generating a problem is a valid way to let myself “enjoy” the combined agony/pleasure of programming.
There is only one mention of Python being slow, and that’s in the form of a joke where Python is crossed out and replaced with “the wrong tool for the job.” Elsewhere in the post, Python is mentioned more positively; it just isn’t what’s needed for the kind of gamedev the author wants to do.
I mean, it’s kind of the whole point of this article, to explore why they felt it was a good idea to try to create a programming language. Bashing other languages and coming up with reasons why none of the existing ones would do, is kind of the whole point. And they do self-reflect and admit that their reasons were ultimately not good enough from a purely objective point of view.
Honestly, my whining isn’t aimed directly at this piece, but to vent my spleen about yet another “Python is slowwww…” missive that is filling the internet.
Theirs comes across to me as “Every language is not good enough for me” whine. Two whines passing in the night, mine and theirs.
Thanks for taking the time to make a good point and apologies for my hypocritical whine about whining.
TL;DR - I didn’t read the whole thing, but I couldn’t help but ask about the elephant in the room: Lua (or another fast scripting language).
Here’s the workflow:
- Write core logic in Rust, and use Lua for everything else
- As code stabilizes, port Lua code to Rust
- At the end, you have a nice modding API
You get most of the benefits of Rust, hot reloading, etc, precisely what OP was asking for. You can even use Lua code to break the rules in Rust.
A good game development language would let me define the optimization level at the module, or even at the individual function level, and preserve as much debug information as possible for these half-optimized builds.
Yes please!
dreaded orphan rule
Yeah, that always struck me as stupid.
any attempts to make life better for programmers via tools like Casey’s DLL trick—the only tool available, really—are met with the knee-jerk reaction of: That’s unsafe, sounds cursed, and I don’t like it
As long as it’s not allowed for “production” builds, I don’t see an issue. Why not just have a compiler flag or something that turns it on or off? Then you can be ergonomic in development and principled in production.
The note about WebAssembly is odd, it’s just slapping a fresh coat of paint over the same abstraction. If you’re communicating with part of your app in WA, congrats, you have a crappier version of the same thing. WA is cool and can be part of the solution, but let’s not clutch our pearls here.
the focus should be on value types, not memory allocation
Isn’t that what lifetimes are? You’re proving to the compiler that this can be a value type given it’s known lifetime. If you don’t know how long something will live, it has to go on the heap or you can have memory safety issues.
async
I agree and disagree here. On one hand, I do a lot of web dev, so async is really nice in keeping things fast. On the other hand, mixing the two sucks.
Here’s my wishlist:
- split stdlib into three parts - core (nostd) , sync, async
- build the runtime into the stdlib - it’s weird to me that I need a third party lib to use async; let me replace it like I can w/ the memory allocator
borrow checker
Yeah, the borrow checker is a bit too strict IMO. Ideally, the borrow checker would only trigger on things that could be run in parallel, such as with threads or async.
That said, I haven’t had many issues, but I also don’t make games. Generally speaking, copying is fine, which lets you have one place for doing modifications if you can send modifications to some kind of store.
All that being said, I feel like the real problem here is that OP wants one tool to solve the complete problem. They brush off WebAssembly for some reason. They don’t consider writing a portion in a scripting language. They don’t consider a microservice architecture, where parts can be hot swapped. Etc.
Rust is great at things it’s great at, so use it for those. Build a system that has stable parts in Rust and unstable parts in something easier to iterate on.
I didn’t read the whole thing, bit I got pretty far. Maybe I’ll finish later, idk.
dreaded orphan rule
Yeah, that always struck me as stupid.
It is necessary to guarantee consistency in the trait system, otherwise it could lead to memory unsafety. Even relaxing it in cases where overlapping implementations could always be catched is still problematic because the compiler sometimes performs negative reasoning about traits that it know cannot be implemented downstream due to the the orphan rule.
And if you think about it the orphan rule is not worse than what other languages allow. For example C# only allow implementing an interface when defining a type, while the orphan rule also allows you to implement a trait when defining the trait itself. Not to mention being able to implement a trait only when a generic parameter implements another trait.
Yeah, the borrow checker is a bit too strict IMO. Ideally, the borrow checker would only trigger on things that could be run in parallel, such as with threads or async.
You can still trivially violate memory safety without multithreading or concurrency. The article touches on this a bit (they mention e.g. iterator invalidation) but they fail to address all issues.
https://manishearth.github.io/blog/2015/05/17/the-problem-with-shared-mutability/
the orphan rule is not worse than what other languages allow
Sure, but that doesn’t mean it can’t be better.
Surely the compiler could delay optimizations until the entire project is built, no? Then it knows what implementations exist, and the developer could then decide how to deal with that. Perhaps the dev could decorate the trait impl as overriding all others, overriding one specific impl, etc.
The orphan rule feels like throwing the baby out with the bathwater.
You can still trivially violate memory safety without multithreading or concurrency
Sure, and ideally those cases would be accounted for, or at the very least the dev could annotate each use to turn the borrow checker off for each instance, and that could print something at build time and a linter could flag over it. Unsafe blocks aren’t feasible for everything here.
A lot of these situations are fine in practice. Give devs the ability to sidestep the rules and take responsibility for the outcome.
Sure, but that doesn’t mean it can’t be better.
It’s surely interesting though that people continuously complain about them and then praise a language whose equivalent feature is much more restrictive!
Surely the compiler could delay optimizations until the entire project is built, no? Then it knows what implementations exist, and the developer could then decide how to deal with that
It’s not really about optimizations but rather:
-
when checking some impls for overlap, the compiler assumes that impls that the orphan rules block will never exist. You thus need to either disallow them (which would make the compiler more restrictive for non-application crates!) or a way to track them (which is easier said than done since coherence and trait checking is very complex)
-
when generating code where specialization and/or vtables are involved. This could be delayed until the last crate is compiled, but at the expense of longer compile times and worse incremental compilation performance.
Sure, and ideally those cases would be accounted for,
AFAIK there’s nothing yet that can account for them without allocating everything on the heap.
or at the very least the dev could annotate each use to turn the borrow checker off for each instance, and that could print something at build time and a linter could flag over it. Unsafe blocks aren’t feasible for everything here.
You want some annotations to break out of the safe subset of the language but aren’t unsafe blocks basically that? Or perhaps you want something more ergonomic, at the expense of safety?
@sugar_in_your_tea @SorteKanin Tried to script with Rhai. Got bitten by the fact it doesn’t support async.
Long but a very good blog post. I largely agree with all the conclusions and similarly wish Rust would go in a better direction with regards to certain features, especially compile-time reflection.
I also sadly agree with the comments on the Rust leadership. My personal experience with contributing to Rust has not been great, though I haven’t tried very hard (but exactly because the initial feeling was not great).
