A Minecraft server written in COBOL (opens in new tab)

One of the rumoured stigma is that the object-oriented flavour of COBOL goes by the unwieldy name of ADD ONE TO COBOL YIELDING COBOL.

At least it doesn't have the unrumoured stigma of older FORTRANs, which ignored whitespace, allowing:

    DO 10 I=1.10

to silently compile an assignment:

    DO10I = 1.10

instead of signalling an error for the syntax of the loop the flight software programmer had intended:

    DO 10 I=1,10

Yeah, I love these insights.

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.

It's really type resonant that you used COBOL (IN ALL CAPS) for your high school project. Makes for good high school memorabilia. I hope you used Greek gods for all of your variable names.

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.

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

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.)

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.

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.

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.

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.

I once worked at a FAANG company where I had access to some of the leading C++ experts in the world (some were part of the international language committee). I emailed an internal C++ list asking whether a certain line of code would create a memory leak. It was a pure use of STL templates and casting. The experts could NOT agree whether I was doing it correctly. Some expected a leak, others didn't.

This true little story says everything about C++. JavaScript is full of these things too.

That was always it's strength. I started programming in 1976, trained in COBOL and ICL PLAN, used punched cards, and mop terminals once we got out of training. 100% of our programs were batch programs. There was a huge bias towards readability, so that anyone of us could read the source code and understand it. That readability was offset somewhat by the necessity to read and understand the core dumps produced when a program failed. At best you would be able to trace a failure to a specific line of code. Thus the habit of dry running programs was hard wired into you. When I left the government institution to move into commercial programming,it was still COBOL and batch programs until the early 80s.I spent 3 years on overnight support and that was when COBOL proved it's worth, you could pick up any previously unseen listing and the core dump and usually fix it pretty quickly, caveat it was always a tactical fix.

That’s why I like Ada (and VHDL). Somewhat verbose, perhaps, but much more readable than more “modern” languages.

COBOL was designed to be written and read by non-programmers. That was the theory, at least.

MOVE FUNCTION MIN(BLOCK-ENTRY-MINIMUM-STATE-ID(LK-BLOCK), STATE-ID) TO BLOCK-ENTRY-MINIMUM-STATE-ID(LK-BLOCK)

It's not Cobol programmers that are rare, it's a shortage of people that can understand the business logic. Cobol is often used in very complicated business operations.

As others have pointed out, probably more the intricacies of the existing business logic, plus the understanding of the mainframe systems that it usually runs on. Otherwise you could just build a cross compiler and call it day.

Those who do are valued not for their programming skills but their knowledge of the (very complex, largely undocumented) system and its business environment.

I think the README tacitly says "redstone is not supported" since those blocks have multiple states:

  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

In particular, it seems buttons don't emit redstone signals.

There's actually two completely separate games (Java edition and Bedrock) that can't cross-play with each other. You can buy a Bedrock edition Minecraft for Windows that should be able to cross-play with the switch.

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...).

Cross-play between the PC "Java" edition and the console "Bedrock" edition is not really possible, so the best option is to play it on Bedrock on both platforms. On Windows you can download the Bedrock edition and play it there, it seems technically possible but a little complicated to play Bedrock edition on Mac / Linux too. (Some Google searching suggests you'll need to run it in a VM on those OSs)

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

I think options are limited from the switch. You can't connect to arbitrary servers from the console version - just some curated public servers or by paying for Realms. You can hack around this with a DNS server that redirects the curated servers, but starts to get sketchy.

You also need the paid switch online for any sort of network play.

Check out minetest open source too, which is similar but separate game like minecraft. You can self-host the server.

I got a Java server running on my ubuntu machine in the basement, but the child prefers to play on XBox.

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.

You have to play the Java version on pc to connect to your own server software.

Because both COBOL and SQL originate with the same design school of "try to make syntax look more like natural English" that was in vogue at the time, with the idea that it'd let non-programmers write code.

Would probably take a few hours to get Hercules and some old z/OS and check, but it's doable.

Your Linux based docker containers can work on all major platforms, how is that not a portable experience?

What platform are you thinking you'd want to use this on that docker doesn't support