Comment by heavensteeth
23 days ago
I'm sure this is some kind of fallacy, but I feel I quite often see ostensibly impressive small side projects like this written in simple plain languages like C (or here COBOL). Every similar, e.g., Rust project I see seems almost non-functional despite having 10x the SLOC.
My working theory is that simpler languages lend themselves to blueprinting ideas and getting something working even with an ugly messy codebase, whereas modern languages force you to write code that will last longer. Or maybe modern languages are just doing something wrong.
A minecraft server isn't exactly a small side project. There are some in works for 3-5 years and they are not yet complete, some have very specific features (like https://github.com/MCHPR/MCHPRS which is meant for redstone showcases). This COBOL server doesn't yet implement lighting and that's one of the hardest parts since mob generation also depends on it. It also didn't fully implement some blocks. You need years to finish a minecraft server so getting something done fast isn't the best path along the way.
I don't think it's a fallacy.
As someone who has 2 WIP games in Rust, I noticed that getting a very minimal gameplay prototype was pretty easy (given a sane engine choice)* but then adding features made the code balloon in size. Switching from singleplayer to multiplayer was a mess. I also fell for some fads and had to waste time removing them.
And Rust really, really doesn't like heavily interconnected graphs of game objects where a game event can lead to updating multiple other types. There is friction in everything. One choice was to just live with it and write slightly more code. The other was trying to find some systematic solution that would take more code upfront and save me time later.
I chose the second options, went through some experiments but it feels like the breakeven point is way further than makes sense for a small one-person project.
*Even within one language, there can be order of magnitude differences. Rust has 2 usable 3D engines, one is well known, has dozens of contributors and gets donations that can supplant a Bay area salary. The other is written by mostly one guy who alternates between living from savings and working full time. The first engine heavily focuses on advertising and has been promising various features for years with little to show for it. The other is ahead in both number of features and implementation quality.
I think it's attitude. Some people code for the fun of it, some people have a clear goal in mind and focus on achieving it, some code for money, some code for public recognition, etc. I don't think an ugly messy codebase is necessary but there's a productive middle ground. People who focus on showmanship instead are more likely to chase fads and fancy architectures.
I know one of those two is Bevy, what is the other one?
Yes, the other is Fyrox. I don't think there are other viable 3D engines in Rust but at this point the hype surrounding Bevy is so large people wouldn't notice (and I stopped following the scene for the most part).
There are also bindings to Godot which is probably the way to go if you actually wanna get shit done. I talked to their authors and they avoided promoting it on Reddit for a while because the hype was bordering on harassment.
Likely Fyrox: https://github.com/FyroxEngine/Fyrox
Oh god, look at the authors contribution graph from last year. He is the living meme.
1 reply →
[flagged]
Isn't Tinyglade mostly custom code including the renderer, just using bevy_ecs as data storage?
6 replies →
Rust has really struggled to break through in gamedev. Rust's core premise is trading off dev speed and flexibility for memory safety, but it turns out that dev speed and flexibility is far more important in gamedev than memory safety.
If you have a formally specified microkernel that's already blueprinted to within an inch of its life, Rust is probably a great choice for you. If, on the other hand, you need to rapidly throw slime at a wall to see what sticks and makes for fun gameplay, Rust is going to make that much more challenging than virtually any other language, and the benefits are far from obvious (your quick and dirty gameplay slice that took much longer to make is slightly more memory safe?).
I'm not the only person who's done gamedev in Rust and has since definitely turned away from the language for that use case, see e.g. "Leaving Rust gamedev after 3 years" [0], which remains one of the most widely discussed and liked Hacker News posts about Rust to date.
More broadly, it's obvious that Rust is far more hyped than Cobol is. That means there are many examples of valiant attempts at OSS or hobby projects in Rust by the devs most susceptible to hype (generally enthusiastic beginners). Conversely, writing a Minecraft server in Cobol requires slightly more whimsy and derring-do, which tends to correlate with greater experience.
[0] https://news.ycombinator.com/item?id=40172033
> Rust's core premise is trading off dev speed and flexibility for memory safety
Rust's main competitor in gamedev is C++, which is not especially known for its "dev speed and flexibility". There are ways to do fast, iterative development in Rust, they just involve quite a bit of boilerplate (to mark all the places where you're giving up some amount of low-level performance in the name of flexibility). If anything, the main disadvantage of Rust is simply that its community, while highly committed to technical excellency, is nonetheless orders of magnitude smaller than the huge amount of C++ developers.
I respectfully disagree, emphasis on respectfully. C++ absolutely does have Rust beat on dev speed on flexibility. I would much rather prototype a quick and dirty gameplay slice in C++ over Rust, and I think so would most people. That flexibility comes at a cost, of course. C++ is three languages in a trenchcoat, waiting for you to turn away so it can bash you over the head and mug you.
There are ways to do anything in Rust, but that doesn't change the fact that it's a language less suited for fast iteration than many others. It's a good tool, just not the best tool for this particular job, and there's no obvious reason to use it over those tools that are a better fit. For the vast majority of games, something like C# is going to make rapid prototyping far easier than either Rust or C++, with far less overhead (overhead = time = money, and gamedev is a pretty cutthroat business).
Rust's community is not particularly small, all things considered, and even adjusting for size, Rust really does under-perform in gamedev. Rust's definition of 'technical excellence' often revolves largely around memory safety, which is something I definitely want from my air traffic control systems, but which barely matters in gamedev at all. There are other things that constitute technical excellence in gamedev, and these tend to be difficult or undesirable in idiomatic Rust (often precisely because they prioritise other goals over memory safety). Rust is a fine language, I'm fairly fond of it, but it's just not a good fit for this use case. And indeed, we see the consequences of that bear out in practice.
(I'd also encourage you to read the comment thread I link above - lots of experienced people agree on this one.)
2 replies →
I think it's just the difference between real hackers™ who often have a fancy for simpler languages and can write the whole universe in anything you give them, versus code monkeys chasing the latest hype cycle. (For reference, I put myself into the second category.)
The author is clearly talented and experienced building server-side systems. So while the language itself is new to the author, the design and architecture would be largely the same if this project were written in Ruby, C, Python, or Javascript.
Had they built something outside of their comfort zone, the results would probably be a lot more messy.
People that get things done usually don't care about code quality. I noticed myself in a place where I just never finished anything anymore by trying to write something to last. Over the years I've found a good balance, but I've found that iterating over garbage will eventually turn into something good and I've been doing so since.
My previous employer certainly got things done. They got so many things done, that I found it impossible to add features to their codebase.
I'd say it's a skill issue, but that's only because I've worked on decompiled applications and made it work. I've worked with assembly and made it work. I hook google chrome with pdb resolving and made it work.
It took me 10 years to get to this point, it is not a reasonable expectation to have of others.
Is good software a Dorodango? A pile of mud that has polished enough to be pretty.
Funny, but no. Software never becomes a smooth sphere, instead you keep adding more chunks to it that are barely holding on that somewhat resembles a sphere... eventually. Wireguard was great from the start.
I've sometimes thought perhaps coding would be much simpler if instead of creating a new programming language, we instead create a fantasy workstation akin to PICO-8/Picotron geared towards building business applications.
On the user interface side, you only have to code to the fantasy workstation's fixed UI and it can be smart enough to automatically be responsive for different screen sizes. Since it's geared towards business apps that are primarily forms, it doesn't have to care about all the edge cases of the web's presentation layer.
Concepts like durable messages queues (like Temporal.io) could be first class citizens so instead of the distributed mess of lambdas, queues, step functions, etc, you just have basic code that can be web scale.
I haven't given it too much thought. It just seemed like something interesting to explore.
There have many attempts to do something like this. I'm arguably working in one of them now, a so-called low code environment. Much of it amounts to storing functions in a database instead of in a file tree, and losing access to modern conveniences like a language server and revision control. The latter quite a bit like working in the PICO-8 editor, really.
I feel like this is a case of the no silver bullet principle. Like, going from a legacy/pre-modern/old language to modern, dynamic to static typed, etc. isn't going to magically make your projects succeed.
Maybe these failed projects in modern languages are the graveyards of those who believed that silver bullets exist.
Or maybe Rust projects are filled with people of first and foremost want to learn Rust, and the actual completion of the project is secondary.
It’s worth noting that a lot of rust frameworks have code generators and the like that emit a lot of lines quickly.
I’m working on a web app with Axum, Diesel (type-safety on my Postgres stuff), and Leptos (in “islands” mode, allows me to write my server side HTML using JSX-like syntax within Rust, and client side WASM). It’s actually incredible how much it can accomplish with a relatively simple file tree.
I originally started with Loco, which is rails-like. It spits out something like 80 files every time you make a scaffold. It felt exactly like what you describe — too much code to do something that should be simple.
I think what you have identified is a truism.
Simple languages present a very lean cognitive load.
They also do not offer a bazillion choices, and that is perhaps their greatest appeal! When the language is simple, a programmer can apply more brain power to actualize the idea.
You can't agonize on the best way to shave a yak if there's only one way to do it.
Bada boom! Correctamundo!
Same as dynamically typed vs statically typed languages.
I think the difference is that rust is hyped - so all you need to do to get attention is to start on it, since "rust" is kind of a selling point all by itself.
Nobody cares about c or cobol, so you have to do something useful to get attention.
In the end i suspect it is just survivorship bias.