Are there any benchmarks for it? How much faster is it than a vanilla server?
I know Minecraft servers tend to get extremely resource intensive as the player count creep and people run extremely beefy servers to handle the load and still offer poor TPS.
As someone who knew about this project from earlier (I had even joined their discord) (currently have just deleted my discord account for better state of mind)
Its really made me happy that hackernews really liked this project (140 upvotes is pretty good in my opinion)
From what I remember , there was one other server as well which also was written in rust but I am not exactly sure
Also , the last time I was at it , it was really really alpha software but it was getting developed at good rate , so I am not sure about its current state (I was there when the author had gone to take his exams IIRC)
> Be a drop-in replacement for vanilla or other servers
It seems to me that unless it's a drop-in replacement its not a Minecraft server? Akin to how say an Uno deck isn't a drop-in replacement for a Hearts deck but still both card games but not both Uno decks.
Or is it just meaning that Pumpkin (besides the network) do things differently than vanilla and so you might not be able to open a vanilla created world using Pumpkin?
The common problem with Minecraft server implementations is that they are not bug-for-bug compatible, which will lead to certain techniques (especially redstone contraptions) breaking. The technical Minecraft community depends on many implementation details which not all servers support
I edited in scare quotes for "complete" to make that clearer, but I mean in terms of at least having matching blocks/mobs despite many differing details.
Minecraft has a lot of bugs or otherwise surprising behaviours that parts of the community have come to rely upon. This means that most non-vanilla minecraft servers aren't 100% drop in replacements. You have to make a decision what behaviours you want vs the performance and simplicity gains you will gain.
For example there there are tricks that allow you to delete bedrock blocks. Which then lets you either get onto the roof of the nether, or drop below the bottom of the world. Not all of these tricks will then work depending upon the specific minecraft server.
Another example is that in vanilla you can "bomb" people with experience orbs, the sheer number of orbs on the screen will grind their game to a halt since there are too many objects to track and render. Some minecraft servers work around this by grouping up experience orbs into a single bigger orb. That way you have fewer orbs on screen at once.
Its written from the ground up and has a clean foundation (which is not the case in vanilla minecraft server code). We also want to use cool modern features like multi-threading or the rust language which is a modern language designed to fix mistakes from older languages
The limitation isn't the Java version, it's the way the MC code was architected.
Iirc part of original Minecraft's performance limitations were high object create/destroy rate leading to lots of garbage collection. With that in mind, picking a non-GCd language isn't completely crazy.
"Modern" seems to be used a loose adjective these days for "I rewrote $thing [in Rust]". Minecraft was created in 2011, and is Wikipedia says the last version of the 'classic' edition was released in 2017. So anything after 2017 is now defunct.
I don't mind people rewriting things in <insert-name-of-tech-I-like> but "modern" as a value seems pretty loose, and it's often at least arguable whether it's objectively better!
“Modern” more usually means some new JavaScript thing. In JS land, they consider anything that hasn’t had a commit on main branch in over 3 days to be a dead old project in need of being replaced with something new and “modern” that is up to date with the latest trends and breaking changes from the previous 24 hours of their world.
Usually the hyperbolic superlative for Rust projects is “blazing fast”. Of course, any kind of benchmarks or comparisons with other implementations are completely optional. It is simply enough to “cargo init” and start hammering out code. You don’t even need to consider the characteristics of the algorithms you choose to use! If it’s Rust, it’s “blazing fast”.
Your most starred repo is inferior to a shell one-liner lol. Talk about pot calling the kettle black. Just use the system dict, shuf, grep, and head.
It’s bad form to badmouth someone’s earnest work for sure. I wouldn’t do it normally since I think it’s nice that you actually did something. But if you’re going to sit in a glass house and throw stones you should expect some back.
Fortunately, my house is an underground burrow so I can throw stones with impunity.
Hi, Valence is a framework (similar to Minestom in Java). You have to build everything you self. Pumpkin is not a framework :D. Also Valence is bit unactive (look commits)
It's pretty funny how many of these are "Is it a Minecraft server? No. It's a framework with which you can build your own rewrite of Minecraft server."
This got me thinking - is Rust really the right tool for the job? And I thought, Elixir/Erlang feels like the perfect tool. Sure enough, someone did it! Great reference material for someone learning how to do things on the beam https://github.com/thecodeboss/minecraft
Compatibility: refers to the ability for client of the latest mincraft server version to be able to connect to the server (pumpkin) unmodified with all mechanics working.
Drop-in replacement: refer to the ability of a server operator to simply exchange the current installation/executable of the server (be vanilla, paper, cuberite, etc...) for pumpkin while maintaining data, configuration, scripts and mods installed.
Tell you the truth, that doesn't help clarify to me much.
If it is compatible, then can't I 'drop it in'.
They sound like they are saying the same thing.
It is compatible so clients can connect to the server and be fully operational, and thus, I should be able to drop in this server, and use it as a server?
How can it be compatible if it doesn't maintain data, configuration, etc..
Edit:
or is this about Pumpkin files. Pumpkin will maintain it's own files, data, configuration. So it can't just use existing Minecraft data files.
So if it was a new world, Pumpkin would generate new pumpkin formatted files. But couldn't just 'drop it in' on an existing world and use the existing Minecraft data files.
Not sure of long term viability as far as effort, but if it is files, couldn't a converter from MineCraft to Pumpkin file structure, make the server 'drop in'?
"But from a client perspective, both implement HTTP/1.1."
This seems too low level example to apply for Minecraft.
Minecraft has a lot going on, back and forth. For something to be 'compatible' it would need to be so detailed an implementation of the server, that it could potentially also be a 'drop in'.
Drop-in means replacing an existing thing with a new one without changing anything.
This is not compatible with other servers plugins/data/configurations, so just replacing the binary and expecting to continue where you left off is not possible.
I would say that Minecraft servers by some qualities are really hard to implement (for example generate world as Java would - using Java's random number generator to generate exactly the same world in Rust) or even impossible. But other usages, like walking through existing world with 1000 of your colleagues might be worth of writing a very fast but not a "drop in replacement" server. Or a massive minigame maybe?
"Drop-in" is what enterprise software calls "bug-for-bug compatible" - e.g., replacing RedHat with CentOS (RIP) should work exactly the same, even if the CentOS team found bugs - they report them upstream and do NOT fix them themselves, because code may be relying on the bugs.
This is especially true with complicated vanilla Minecraft setups and red stone machines (Java Minecraft red stone has "bugs" that "shouldn't be there" but cannot be removed now since so much depends on it).
Hey, With Compatibility i mean be compatible with existing Minecraft vanilla client's and also use vanilla logic.
With "Be a drop-in replacement for vanilla or other servers" i mean that if you just replace the existing server file with pumpkin, pumpkin will not load configs/plugins from vanilla/other servers
Are there any benchmarks for it? How much faster is it than a vanilla server?
I know Minecraft servers tend to get extremely resource intensive as the player count creep and people run extremely beefy servers to handle the load and still offer poor TPS.
Hey, Your lucky, i just made benchmarks all this time :D. Check them out https://snowiiii.github.io/Pumpkin/about/benchmarks.html
As someone who knew about this project from earlier (I had even joined their discord) (currently have just deleted my discord account for better state of mind) Its really made me happy that hackernews really liked this project (140 upvotes is pretty good in my opinion)
From what I remember , there was one other server as well which also was written in rust but I am not exactly sure
Also , the last time I was at it , it was really really alpha software but it was getting developed at good rate , so I am not sure about its current state (I was there when the author had gone to take his exams IIRC)
Are you sharding the main thread into regions (ie. Like paper folia) or is this just breaking of non block-entities to their own threads.
Hello. I recently developed Pumpkin, Its a efficent and fast Minecraft server completely written in Rust from the ground up, Check it out :D
Cool! Would be interesting to understand how to multithreading works? Is it just the "easy" parts or actual operations related to the world as well?
> What Pumpkin will not
> Be a drop-in replacement for vanilla or other servers
It seems to me that unless it's a drop-in replacement its not a Minecraft server? Akin to how say an Uno deck isn't a drop-in replacement for a Hearts deck but still both card games but not both Uno decks.
Or is it just meaning that Pumpkin (besides the network) do things differently than vanilla and so you might not be able to open a vanilla created world using Pumpkin?
The common problem with Minecraft server implementations is that they are not bug-for-bug compatible, which will lead to certain techniques (especially redstone contraptions) breaking. The technical Minecraft community depends on many implementation details which not all servers support
In addition to the hundreds of blocks and mobs that would need to be implemented properly and rarely are, the lack of mod support is a killer.
The only "complete" reimplementation of Java Minecraft that I'm aware of is Bedrock.
Far from it. The versions lack a lot of parity and Bedrock is called "bugrock" by the community for a reason
I edited in scare quotes for "complete" to make that clearer, but I mean in terms of at least having matching blocks/mobs despite many differing details.
There are no bugs in Minecraft, only features that have yet to be fully documented.
Minecraft has a lot of bugs or otherwise surprising behaviours that parts of the community have come to rely upon. This means that most non-vanilla minecraft servers aren't 100% drop in replacements. You have to make a decision what behaviours you want vs the performance and simplicity gains you will gain.
For example there there are tricks that allow you to delete bedrock blocks. Which then lets you either get onto the roof of the nether, or drop below the bottom of the world. Not all of these tricks will then work depending upon the specific minecraft server.
Another example is that in vanilla you can "bomb" people with experience orbs, the sheer number of orbs on the screen will grind their game to a halt since there are too many objects to track and render. Some minecraft servers work around this by grouping up experience orbs into a single bigger orb. That way you have fewer orbs on screen at once.
What does "modern" mean in this context?
Its written from the ground up and has a clean foundation (which is not the case in vanilla minecraft server code). We also want to use cool modern features like multi-threading or the rust language which is a modern language designed to fix mistakes from older languages
> cool modern features like multi-threading
Java 6 had multi-threading
The limitation isn't the Java version, it's the way the MC code was architected.
Iirc part of original Minecraft's performance limitations were high object create/destroy rate leading to lots of garbage collection. With that in mind, picking a non-GCd language isn't completely crazy.
While Java does, the Minecraft server architecture does not.
I read this in the most satirical way possible like as if a godly narrator said it calmly.
It was really funny. It felt like a Satire LMAO
"Modern" seems to be used a loose adjective these days for "I rewrote $thing [in Rust]". Minecraft was created in 2011, and is Wikipedia says the last version of the 'classic' edition was released in 2017. So anything after 2017 is now defunct.
I don't mind people rewriting things in <insert-name-of-tech-I-like> but "modern" as a value seems pretty loose, and it's often at least arguable whether it's objectively better!
“Modern” more usually means some new JavaScript thing. In JS land, they consider anything that hasn’t had a commit on main branch in over 3 days to be a dead old project in need of being replaced with something new and “modern” that is up to date with the latest trends and breaking changes from the previous 24 hours of their world.
Usually the hyperbolic superlative for Rust projects is “blazing fast”. Of course, any kind of benchmarks or comparisons with other implementations are completely optional. It is simply enough to “cargo init” and start hammering out code. You don’t even need to consider the characteristics of the algorithms you choose to use! If it’s Rust, it’s “blazing fast”.
Your most starred repo is inferior to a shell one-liner lol. Talk about pot calling the kettle black. Just use the system dict, shuf, grep, and head.
It’s bad form to badmouth someone’s earnest work for sure. I wouldn’t do it normally since I think it’s nice that you actually did something. But if you’re going to sit in a glass house and throw stones you should expect some back.
Fortunately, my house is an underground burrow so I can throw stones with impunity.
Where's that meme of the guy painting demons then laying down on the floor in fear when you need it.
See also https://github.com/valence-rs/valence A "clean room" implementation of the Minecraft server written in Rust
Hi, Valence is a framework (similar to Minestom in Java). You have to build everything you self. Pumpkin is not a framework :D. Also Valence is bit unactive (look commits)
yes , I was also thinking about this . +1
It has now been 0 days since a new minecraft server was written in Rust https://dayssincelastrustmcserver.com/
It's pretty funny how many of these are "Is it a Minecraft server? No. It's a framework with which you can build your own rewrite of Minecraft server."
This got me thinking - is Rust really the right tool for the job? And I thought, Elixir/Erlang feels like the perfect tool. Sure enough, someone did it! Great reference material for someone learning how to do things on the beam https://github.com/thecodeboss/minecraft
Pumpkin is already on that list.
I was thinking it would be cool to have a Minecraft server built with Bevy, but that has also already been done: https://github.com/valence-rs/valence
Lmao it is funny how we have daysinceX websites. is there a list of all such websites of daysinceXofY like dayssincelatestframeworkofnode I guess?
Love the idea. Especially as a learning example. Always fun to learn a language by implementing a popular game.
Am confused by these two lines. Maybe it is just difference between the 'goal' and the 'current state'.
Goal:
"Compatibility: Supports the latest Minecraft server version and adheres to vanilla game mechanics. "
But NOT:
"Be a drop-in replacement for vanilla or other servers "
Will it be a replacement for Vanilla or not?
Compatibility: refers to the ability for client of the latest mincraft server version to be able to connect to the server (pumpkin) unmodified with all mechanics working.
Drop-in replacement: refer to the ability of a server operator to simply exchange the current installation/executable of the server (be vanilla, paper, cuberite, etc...) for pumpkin while maintaining data, configuration, scripts and mods installed.
edit: grammar
Tell you the truth, that doesn't help clarify to me much.
If it is compatible, then can't I 'drop it in'.
They sound like they are saying the same thing.
It is compatible so clients can connect to the server and be fully operational, and thus, I should be able to drop in this server, and use it as a server?
How can it be compatible if it doesn't maintain data, configuration, etc..
Edit: or is this about Pumpkin files. Pumpkin will maintain it's own files, data, configuration. So it can't just use existing Minecraft data files.
So if it was a new world, Pumpkin would generate new pumpkin formatted files. But couldn't just 'drop it in' on an existing world and use the existing Minecraft data files.
Not sure of long term viability as far as effort, but if it is files, couldn't a converter from MineCraft to Pumpkin file structure, make the server 'drop in'?
Maybe some more concrete examples may help:
* nginx is not a drop in replacement for apache
But from a client perspective, both implement HTTP/1.1.
* podman is not a drop in replacement for docker
But from a client perspective connecting to a service hosted in docker, that connection can still occur over TCP.
On the other hand:
* pkgconf is a drop in replacement for pkg-config
* cronie is a drop in replacement for vixie-cron
"But from a client perspective, both implement HTTP/1.1."
This seems too low level example to apply for Minecraft.
Minecraft has a lot going on, back and forth. For something to be 'compatible' it would need to be so detailed an implementation of the server, that it could potentially also be a 'drop in'.
Drop-in means replacing an existing thing with a new one without changing anything.
This is not compatible with other servers plugins/data/configurations, so just replacing the binary and expecting to continue where you left off is not possible.
I would say that Minecraft servers by some qualities are really hard to implement (for example generate world as Java would - using Java's random number generator to generate exactly the same world in Rust) or even impossible. But other usages, like walking through existing world with 1000 of your colleagues might be worth of writing a very fast but not a "drop in replacement" server. Or a massive minigame maybe?
But the world generation is already deterministic with seeds
Compatible: You start a Pumpkin server, vanilla clients can join and play.
Drop-in: You run a server for some time. You decide to switch the software by replacing the executable. Everything works as before.
"Drop-in" is what enterprise software calls "bug-for-bug compatible" - e.g., replacing RedHat with CentOS (RIP) should work exactly the same, even if the CentOS team found bugs - they report them upstream and do NOT fix them themselves, because code may be relying on the bugs.
This is especially true with complicated vanilla Minecraft setups and red stone machines (Java Minecraft red stone has "bugs" that "shouldn't be there" but cannot be removed now since so much depends on it).
Guess this gets to my other point.
By the time you are 'compatible' then you have implemented everything needed to also be a 'drop-in' but data file formats might need a conversion.
So convert from Minecraft data files to Pumpkin data files. Then it could drop in.
Hey, With Compatibility i mean be compatible with existing Minecraft vanilla client's and also use vanilla logic. With "Be a drop-in replacement for vanilla or other servers" i mean that if you just replace the existing server file with pumpkin, pumpkin will not load configs/plugins from vanilla/other servers
This looks great! Can't wait to check out the code in detail.
I would love to hear some feedback, tried my best so code is clean :D
i wish minecraft was open source, i'd be able to fix their inefficient protocol
Downvoter, go check this: https://wiki.vg/Protocol, let me know if that's a good way to sync a lot of fast moving entities across a TCP network
This is why people struggle with their servers, not because the game was written in java
looks good
thank you :3
Reminded me of this existing https://dayssincelastrustmcserver.com/
Similar projects:
- Feather (Rust, abandoned) https://github.com/feather-rs/feather
- Valence (Rust) https://github.com/valence-rs/valence
- Cuberite (C++) https://github.com/cuberite/cuberite
Minecraft Server (Zig) https://github.com/regenerativep/zig-mc-server
this person is going gods work
This weeks Minecraft server! Nice!