[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]
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.
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/
@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).
