A Minecraft server written in COBOL(github.com) |
A Minecraft server written in COBOL(github.com) |
I hope they'd write an article about any insights they gained. Like them, I hear of these rumors and stigma, and would be intrigued to learn what a new person to COBOL encountered while implementing this rather complex first project.
At least it doesn't have the unrumoured stigma of older FORTRANs, which ignored whitespace, allowing:
DO 10 I=1.10
DO10I = 1.10
DO 10 I=1,10Which is a joke. Rather than an extension, the COBOL standard itself incorporates OO support, since COBOL 2002. The COBOL standards committee began work on the object-oriented features in the early 1990s, and by the mid-1990s some vendors (Micro Focus, Fujitsu, IBM) were already shipping OO support based on drafts of the COBOL 2002 standard. Unfortunately, one problem with all the COBOL standards since COBOL 85 (2002, 2014 and 2023), is no vendor ever fully implements them. In part that is due to lack of market demand, in part it is because NIST stopped funding its freely available test suite after COBOL 85, which removed a lot of the pressure on vendors to conform to the standard.
If you are interested, here are insights from making a COBOL to C# compiler: https://github.com/otterkit/otterkit-cobol/issues/40
I am now convinced that COBOL is just a high level assembler.
In fairness, I think to some extent everything was just a high level assembler in its day, and then it never changed:)
For my high school graduation project, I wrote a full COBOL system to automate soccer betting odds. Long past its prime, but my school hadn’t quite caught up with the times.
It was hilariously out of place, but I loved every line of it. There’s something oddly satisfying about a language that whispers, “Remember punched cards?” as you type.
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.
It's actually not too difficult to understand for anyone with a background in procedural languages, and reminds me somewhat about some game servers written in VB that I saw ~2 decades ago.
(impressive that you did this)
This true little story says everything about C++. JavaScript is full of these things too.
It was okay -- did a project that simulated some financial statements. I recall it being quirky but, to most humans (i.e. non-programmers), any programming language would be quite quirky so I don't understand the stigma around it.
I also learned C around the same time and that one stuck. :-)
Did this project generate any flood of offers for work?
Honestly just knowing COBOL is how you get your foot into a well paying job where you learn that stuff from the old timers.
Note that blocks with multiple states, orientations, or interactive blocks require large amounts of specialized code to make them behave properly, which is way beyond the scope of this project. Some are supported, however:
torches (all variants)
slabs (all variants)
stairs (non-connecting)
rotated pillars, such as logs or basalt
buttons (non-interactive)
doors (including interaction)
trapdoors (including interaction)
beds
Edit: I don’t currently play, which is why I’m not familiar with what’s out there
Nevertheless, congrats to this achievement.
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.
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.
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.
Had they built something outside of their comfort zone, the results would probably be a lot more messy.
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.
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.
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.
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.
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.
Many years have passed since but C++ with its overloads and macro system is still largely noise to me.
Java Edition is the original game and it's fairly easy to either host your own server (The dedicated server is just a .jar you run) or pay for a server ($10-40/mo) using a game server host.
Unsure about bedrock, there's some instructions here (https://www.reddit.com/r/Minecraft/wiki/bds/#wiki_bedrock_de...).
(Plus Floodgate so they don't need a Java account)
I just setup a new family minecraft server last week and have successfully hosted java and bedrock players simultaneously (one coming in from a Nintendo switch, another from their phone and several from Java clients).
There are also plug-ins allowing older (or newer) client versions to connect to your server as well (ViaVersion, ViaBackwards).
https://help.minecraft.net/hc/en-us/articles/4410317081741-H...
EDIT: I just realized this works on Bedrock too, but don't know how the support on the Switch is
https://help.minecraft.net/hc/en-us/articles/4410316619533-H...
They're pre-compiled Windows and Linux binaries, but if I'm remembering correctly, I think they're statically linked, and I had no trouble running the Ubuntu one on my Fedora system.
I used to keep a Bedrock server running on my desktop, and my son and I could pop in from a phone, tablet, or laptop whenever we wanted to.
Easiest way to get a server is to pay Minecraft (Microsoft) to host it for you via realms: https://www.minecraft.net/en-us/realms
But self hosting is supported too, there are official server binaries you can download from Minecraft here: https://www.minecraft.net/en-us/download/server/bedrock
You also need the paid switch online for any sort of network play.
Rather than spend my time fucking around with setting up a server, I just gave Microsoft $3 a month to use Realms.
I've got enough chores.
A quick turned up https://www.dbi-services.com/blog/freebsd-basics-8-running-l... which seems to confirm.
It took me 10 years to get to this point, it is not a reasonable expectation to have of others.
It's also becoming more and more "not just Minecraft". For instance this entry from the latest GameJam, which is a nice little shooter [2]
[2] https://content.luanti.org/packages/Sumianvoice/extra_ordina...
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.)
I can be productive in C#/F#, Rust, Go or TypeScript in a fraction of time it takes to accomplish so in C++ the moment you go beyond something trivial. It’s not the fault of the language per se but of everything around it.
It’s one of the reasons some people are so upset about C++ and Rust, in my opinion. Working with C and C++ involves huge amount of pain and hassle that is absolutely not required to accomplish whatever task you are dealing with.
It absolutely is. Your linked thread has people describing the 3D- or 2D-rendering stacks available in Rust as half-baked in some way or other, with other folks saying that it's hard or infeasible to get Rust code on consoles where the manufacturer forces you to use their dev SDK. This is what a smaller community looks like in practical terms.
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.
Oh god, look at the authors contribution graph from last year. He is the living meme.
He used to have a Patreon with a modest goal of $1000 per month and was making decent progress towards it but then the war started and after it was clear he was not getting any of the money any time seen, he had to switch to other platforms but by then the opportunity was gone.
He worked for a while for another big game studio to save up and then went back to Fyrox.
In scientific/technical computing you have frequently, even in the same expression, dozens of different kinds of additions, multiplications, divisions, etc., between scalars, vectors, matrices, tensors, complex numbers, various kinds of physical quantities, and so on. Without operator overloading the expressions can become huge, extending on a great number of program lines and they can be very difficult to understand.
Also, Pascal's method of using a single kind of statement brackets, i.e. "begin" and "end" (renamed in C as "{" and "}"), which has been inherited from Algol 60, is wrong for program readability.
The right method has been introduced by Algol 68 and it was inherited by languages like Ada. In such languages there are several kinds of statement brackets, like in the UNIX shell, where "if" and "fi" are brackets for conditional statements, "do" and "done" are brackets for loops and "case" and "esac" are brackets for selection statements. This is much more readable, especially when there is a big loop that can not be seen in a single page of code, so you see only its end, which is also the end of many other kinds of program structures, like nested loops, conditional statements or selection statements.
To get the same readability in languages like Pascal and C, you can add comments to the final braces or "end" of the program structures, but this is much more cumbersome than in a language with several kinds of statement brackets, where the bracket pairs will normally be added automatically by your text editor.
Agda is my favorite example of a language that _judiciously_ uses Unicode symbols to express "concepts similar to something but is actually substantially different so let's not get them confused"... as opposed to other theorem proving languages of its time [1]
[1] https://people.inf.elte.hu/divip/AgdaTutorial/Functions.Equa...
“do” and “od” IIRC
And then there is the whole DoD security assessment of Multics versus UNIX, where PL/I did play a major role versus C, so the compiler did work correctly enough.
Just this week we're discussing a VC++ miscompilation on Reddit.