Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

A Minecraft server written in COBOL

github.com

Post reply on HN
Print view View original

101–110 of 127 posts

Re: A Minecraft server written in COBOL

#101

Post by shiroiushi »

userbinator wrote: post #82
082349872349872 wrote: post #11

Earlier quoted context omitted.

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

No one seems to have written a Minecraft server in FORTRAN yet... but I think your comment just gave some people here ideas.

Instead of FORTRAN, someone should try writing a Minecraft server in something like ALGOL or FORTH.

Re: A Minecraft server written in COBOL

#102

Post by martin-t »

voxl wrote: post #96
martin-t wrote: post #92

Earlier quoted context omitted.

Isn't Tinyglade mostly custom code including the renderer, just using bevy_ecs as data storage?

[flagged]

You can't mix and match, you're still tied to bevy_ecs if you use any level of abstraction above it.

I also didn't say it was a bad things. I just pointed out that everyone's goto example of bevy's commercial success (not even quality, just success) doesn't in fact use large chunks of bevy.

I am sure bevy's ECS is the best in the rust ecosystem. ECS doesn't meet the requirements of my games so i rejected it but if it works for other people who made an informed decision (i.e. they knew about generational arenas) that's perfectly OK with me.

In fact, I evaluated bevy along with fyrox (back then rg3d) and macroquad for my games before bevy got popular. I chose the other two engines based on their features and quality of implementation. I also happily advised cart about some community management things i learned from other OSS projects and had a reasonably discussion with him about ECS vs gen arenas when i got somewhat angrily pinged from his discord after he mistakenly assumed i was writing a competing non-ecs engine.

I had no issue with bevy until it started making false promises ("editor this year, pinky swear", "we will distribute donations fairly, not just into cart's pocket, just give us another 6 months for the third time") and until (some of) its most zealous fanboys started harassing people for not using bevy.

---

My fundamental point still stands, read what I was replying to - some languages lead to an order of magnitude more code with fewer features and worse results than simple approaches. I said it's not just languages but can happen with projects within a language.

The fact that after several years, dozens of contributors and probably several hundred thousand dollars (!) got poured into bevy it's still chasing fyrox made by one guy is all that needs to be said.

Re: A Minecraft server written in COBOL

#103

Post by reactordev »

glimshe wrote: post #27
owenthejumper wrote: post #22

Roast me but the code is very readable. Compare with some modern languages where you have to stare at it for minutes to understand what's going on.

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 s…

That’s every language. Experts will argue and pontificate the nuances of each branching instruction.

Re: A Minecraft server written in COBOL

#104

Post by zozbot234 »

troad wrote: post #97
heavensteeth wrote: post #42

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,…

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 rapid…

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

Re: A Minecraft server written in COBOL

#105

Post by glimshe »

reactordev wrote: post #103
glimshe wrote: post #27

Earlier quoted context omitted.

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 s…

That’s every language. Experts will argue and pontificate the nuances of each branching instruction.

But they all should agree on whether a certain line is correct (ie causes a memory leak).

Re: A Minecraft server written in COBOL

#106

Post by theoldgit »

owenthejumper wrote: post #22

Roast me but the code is very readable. Compare with some modern languages where you have to stare at it for minutes to understand what's going on.

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.

Re: A Minecraft server written in COBOL

#107

Post by pjmlp »

PaulHoule wrote: post #86
pjmlp wrote: post #81

Earlier quoted context omitted.

I would assess C++ has already outpaced PL/I complexity, and I do enjoy using C++.

You can get a C++ compiler which is (more or less) correct, I'm not sure that was ever quite true of PL/I.

It was for IBM and Unisys, I imagine.

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.

Re: A Minecraft server written in COBOL

#108

Post by thrw42A8N »

bitfilped wrote: post #84
thrw42A8N wrote: post #16

Earlier quoted context omitted.

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

There are more OSs than Windows and Linux :)

What other portability platform supports all of them? Only the browser if anything, so we build everything in Node and Electron?

Re: A Minecraft server written in COBOL

#109

Post by troad »

zozbot234 wrote: post #104
troad wrote: post #97

Earlier quoted context omitted.

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 rapid…

> 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, t…

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

Re: A Minecraft server written in COBOL

#110

Post by neonsunset »

troad wrote: post #109
zozbot234 wrote: post #104

Earlier quoted context omitted.

> 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, t…

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…

Being productive with C++ tools and dependencies has much steeper learning curve than Rust as a language, and has you spend way more effort on a constant basis.

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.

Post reply on HN