| Time |
Nick |
Message |
| 00:02 |
|
sparky4 joined #minetest |
| 00:44 |
|
khimaros_ joined #minetest |
| 01:25 |
|
smk joined #minetest |
| 02:25 |
|
skeletronix2 joined #minetest |
| 03:18 |
|
YuGiOhJCJ joined #minetest |
| 03:22 |
|
sid0 joined #minetest |
| 04:14 |
|
sys4 joined #minetest |
| 04:16 |
|
calculon joined #minetest |
| 05:00 |
|
MTDiscord joined #minetest |
| 05:04 |
|
sometalgoo joined #minetest |
| 05:09 |
|
dabbill_ joined #minetest |
| 05:32 |
|
sometalgoo joined #minetest |
| 05:49 |
|
est31 joined #minetest |
| 05:59 |
|
sys4 joined #minetest |
| 05:59 |
|
YuGiOhJCJ joined #minetest |
| 06:12 |
|
diceLibrarian2 joined #minetest |
| 06:26 |
|
rdrg109 joined #minetest |
| 07:18 |
|
TomTom joined #minetest |
| 07:30 |
|
xer69 joined #minetest |
| 07:31 |
xer69 |
Is OSX 10.14.6 still supported? I tried downloading 5.8.0 but it crashes when I try to open it, something about 'libjsoncpp.25.dylib' |
| 07:36 |
|
vampi joined #minetest |
| 07:38 |
|
calcul0n_ joined #minetest |
| 07:40 |
|
meldrian joined #minetest |
| 07:40 |
|
meldrian joined #minetest |
| 08:29 |
|
mrkubax10 joined #minetest |
| 09:28 |
|
Leopold joined #minetest |
| 09:50 |
|
qqq joined #minetest |
| 10:20 |
|
appguru joined #minetest |
| 11:05 |
sfan5 |
not sure, we don't have anyone to test the builds before release |
| 11:08 |
|
s20 joined #minetest |
| 11:58 |
|
s20 joined #minetest |
| 13:06 |
|
appguru joined #minetest |
| 13:13 |
|
definitelya joined #minetest |
| 14:22 |
|
gxt joined #minetest |
| 14:25 |
|
sys4 joined #minetest |
| 14:30 |
|
Niklp joined #minetest |
| 15:32 |
|
s20 joined #minetest |
| 16:36 |
|
mrkubax10 joined #minetest |
| 16:36 |
|
mrkubax10 joined #minetest |
| 16:49 |
|
jaca122 joined #minetest |
| 18:15 |
|
Talkless joined #minetest |
| 18:27 |
|
CRISPR joined #minetest |
| 18:39 |
|
sparky4 joined #minetest |
| 18:47 |
MTDiscord |
<jordan4ibanez> We should have minetest/minetest-rust as a blank rust project to see who bites it as a test |
| 18:47 |
ROllerozxa |
https://github.com/minetest-rust |
| 18:47 |
MTDiscord |
<jordan4ibanez> No not that one, I mean, an official one |
| 18:48 |
MTDiscord |
<jordan4ibanez> Also that one is ded |
| 18:51 |
celeron55 |
i'm not saying it's a good idea, but if it existed it would have to have at least some written goals, and a roadmap would be a nice bonus. the reason for this is that such a thing would be bound to have other changes in it than just being a plain port from C++ to Rust |
| 18:53 |
mrkubax10 |
you can say that that project is little... *rusty* (because it wasn't updated for long time) |
| 18:53 |
celeron55 |
(i'm of course open to reading a proposal which contains a list of goals, and seeing the reactions from people to such a thing wouldn't hurt) |
| 18:54 |
MTDiscord |
<jordan4ibanez> "A complete redesign of minetest from the ground up with focus on memory safety, performant execution, and modularity" goals 0.0-prototype: 1.) A basic solid infrastructure to build upon 2.) Solid libraries to build upon. 3.) NO unsafe |
| 18:55 |
MTDiscord |
<jordan4ibanez> We start very basic because this project is still words on an irc & discord |
| 18:55 |
|
CRISPR joined #minetest |
| 18:56 |
MTDiscord |
<luatic> I don't really think we have any experienced Rust devs willing to commit to such an "official" project yet. |
| 18:56 |
celeron55 |
what about the lua api? does minetest to you mean "lua api compatible"? what about network? what about disk? should it have the same settings? it needs to be defined quite thoroughly what stays the same and what differsa |
| 18:56 |
celeron55 |
-a |
| 18:57 |
|
linus joined #minetest |
| 18:57 |
|
doseijin joined #minetest |
| 18:58 |
MTDiscord |
<jordan4ibanez> Well I'm not even a C++ dev but because of the GLTF PR now I am apparently |
| 18:58 |
celeron55 |
using rust all the way throughout it would give some benefits in sandboxing server-sent code. i don't think there's a rust lua port though, and luajit is another story, you can't jit safely (safely as rust considers it) |
| 18:59 |
MTDiscord |
<jordan4ibanez> Yes there is a safe luajit library actually, I built crafter in rust with it |
| 18:59 |
MTDiscord |
<jordan4ibanez> Let me go find it |
| 18:59 |
MTDiscord |
<paradust> luajit itself is hardly safe |
| 19:00 |
MTDiscord |
<paradust> lua to wasm transpiler would be nice |
| 19:00 |
mrkubax10 |
WASM is becoming some sort of universal virtual machine |
| 19:00 |
MTDiscord |
<jordan4ibanez> https://crates.io/crates/mlua/ |
| 19:01 |
MTDiscord |
<paradust> there's a strong need for a universal vm with native performance and sandboxing |
| 19:02 |
MTDiscord |
<paradust> wasm is the closest thing we got |
| 19:03 |
mrkubax10 |
native performance is debatable because it's still VM but overall true |
| 19:03 |
MTDiscord |
<jordan4ibanez> Now I'm going to show you this, but keep in mind this was hardcoded specifically for my needs and can be made more dynamic than this https://github.com/jordan4ibanez/Crafter-Rust/blob/master/src/lua/lua_intake_api.rs#L68 |
| 19:04 |
MTDiscord |
<jordan4ibanez> You can also peak/grab/mod the luajit vm as it's running as needed |
| 19:11 |
|
appguru joined #minetest |
| 19:12 |
MTDiscord |
<jordan4ibanez> Now also also, keep in mind that we actually don't have to use lua because there are quite a few script languages available |
| 19:13 |
MTDiscord |
<jordan4ibanez> We can even go as far as to dynamically link/load compiled rust mods |
| 19:18 |
|
___nick___ joined #minetest |
| 19:20 |
|
Thelie joined #minetest |
| 19:25 |
|
___nick___ joined #minetest |
| 19:27 |
MTDiscord |
<jordan4ibanez> - what about the lua api? does minetest to you mean "lua api compatible"? minetest means a game dev environment with a scripting language and blocks https://github.com/rust-unofficial/awesome-rust#scripting https://github.com/swc-project/swc swc is stuck on nightly atm - what about network? There are quite a few networking libraries https://github.com/rust-unofficial/awesome-rust#network-programming - what about disk? On the |
| 19:27 |
MTDiscord |
awesome rust page we have Logging libs, and A LOT of database libraries to choose from - should it have the same settings? I honestly don't think so. I think that these settings will evolve over the lifetime (heh heh) of the development, with a focus on not hardcoding crucial elements this would become a phoenix out of the ashes |
| 19:29 |
|
___nick___ joined #minetest |
| 19:29 |
jonadab |
"Experienced rust devs" don't really exist yet. Rust is too new to have experienced developers. |
| 19:30 |
jonadab |
It barely has any _proficient_ developers yet. Although it does seem to be gaining. |
| 19:31 |
MTDiscord |
<luatic> jonadab: That depends on your definition of "experienced". Rust has been around for more than a decade now. |
| 19:32 |
jonadab |
Ok, yes, but for the first several years it was too new to have any substantial number of developers at all. It's only been in the last five or six years that significant numbers of developers have started to use it. |
| 19:33 |
jonadab |
Its uptake curve has been more than linear though. |
| 19:33 |
jonadab |
So that is changing over time. |
| 19:34 |
jonadab |
Note that the central core of people who _created_ the language, don't really count; they're too busy to do most other projects. |
| 19:40 |
|
sofar joined #minetest |
| 19:43 |
|
TheSilentLink joined #minetest |
| 19:46 |
MTDiscord |
<jordan4ibanez> I wish that other core devs would break the seriousness and either just completely poop on rust or express their approval so we can grapple with how the core dev team feels about rust |
| 19:50 |
|
v-rob joined #minetest |
| 19:56 |
muurkha |
jonadab: Rust had thousands of developers five years ago, and its core developers certainly do count |
| 19:57 |
muurkha |
wasm can't really support JIT |
| 19:57 |
muurkha |
in its current form |
| 20:06 |
rubenwardy |
Rust is cool but there's no chance of Minetest switching to rust at this stage. It would be a huge amount of effort |
| 20:07 |
|
Desour joined #minetest |
| 20:12 |
muurkha |
you can probably generalize that to just about any existing piece of software |
| 20:12 |
muurkha |
as https://www.joelonsoftware.com/2000/04/06/things-you-should-never-do-part-i/ says: |
| 20:13 |
muurkha |
"They [waited three years between releases] by making the single worst strategic mistake that any software company can make: / Tey decided to rewrite the code from scratch." |
| 20:13 |
muurkha |
*They |
| 20:15 |
MTDiscord |
<jordan4ibanez> Yeah I think it's much harder at the moment. Memory safety is an ultra-extreme majority of the current issues. That's probably why there are currently 3,529 unmerged closed commits |
| 20:15 |
muurkha |
oh, the potential benefit of Rust isn't that you spend less time fixing segfaults, mostly |
| 20:16 |
muurkha |
it's that you can more easily get scalability across an 8-core or 16-core or 64-core CPU |
| 20:16 |
MTDiscord |
<jordan4ibanez> That's a majority of our current problem, touch a brick and the wall not only collapses, it turns out it was made out of nitroglycerin and just explodes |
| 20:18 |
MTDiscord |
<warr1024> Rewrites are actually perfectly fine as long as you don't rewrite the actual code 😏 |
| 20:19 |
MTDiscord |
<warr1024> I've done quite a few "rewrites" where you start the project over from scratch and then about 5% of the way in, you reach that point where you've fixed the real problems and you can just copy in all the rest of the old code into its new places and it works fine. |
| 20:20 |
MTDiscord |
<warr1024> You could get away with it if the languages are directly analogous, so rewriting MT in Rust would be pretty hard, but in C++ it'd be fine. |
| 20:23 |
jonadab |
I'm not sure I see the _point_ of rewriting in C++. |
| 20:23 |
jonadab |
But yes, the correct way to rewrite a codebase is to refactor it a piece at a time. |
| 20:24 |
MTDiscord |
<jordan4ibanez> It's only hard because you must simply break it down into stages, a big picture outlook is not a good idea. The current state is like someone that broke their leg and we just used 5 rolls of duct tape so they can walk to the nearest hospital |
| 20:24 |
jonadab |
A "piece" can be a function, or it can be a data structure that many functions use, or it can be some other interaction . |
| 20:25 |
jonadab |
C is admittedly a harder language to work in than a lot of more modern ones. |
| 20:29 |
|
amfl2 joined #minetest |
| 20:33 |
MTDiscord |
<jordan4ibanez> muurkha I think my favorite part of that article which is also probably around the same time that irrlicht was first created is: netscape was also written in C++ |
| 20:45 |
muurkha |
jonadab: dunno. it does take more effort to get stuff working in C than in JS or Python or whatever |
| 20:45 |
muurkha |
but that doesn't seem to pay off in an overwhelming project-scale advantage |
| 20:45 |
muurkha |
if we're talking about Golang I think the case is a little clearer |
| 20:46 |
muurkha |
my guess is that because C is less flexible it is easier to modify because it's easier to tell what the effects of your modification will be |
| 21:26 |
|
imi joined #minetest |
| 21:39 |
jonadab |
My biggest annoyances with C are 1) it's a pain to learn and 2) your code has no choice but to micromanage stuff like data structures and memory allocation. |
| 21:40 |
jonadab |
1) is less important, because there are a lot of people who already know the language. It's mostly caused by the standard library functions being named things like xnstrncmpli(), which makes it gratuitously hard to figure out what function you need to research to accomplish a thing. |
| 21:42 |
muurkha |
it's a small, simple language that is pretty easy to learn, but #2 seems to just be saying that it's a low-level language, which is true |
| 21:42 |
ShadowBot |
https://github.com/minetest/minetest/issues/2 -- Burned wood |
| 21:43 |
muurkha |
xnstrncmpli is not a standard library function; all the standard library functions (at least until recent versions) are unique in the first 6 characters |
| 21:44 |
muurkha |
because until I think C99 that was all that was guaranteed to be significant, due to limitations of old mainframe linkers |
| 21:45 |
jonadab |
I did not know that about C standard library function names. |
| 21:45 |
jonadab |
That explains why they're so cryptic. |
| 21:45 |
muurkha |
yes. also its designers didn't know how to touch-type |
| 21:46 |
muurkha |
what makes it gratuitously hard to figure out what function you need is the lack of standard data structures. but that's mostly a problem when you're first picking up an unfamiliar library |
| 21:46 |
jonadab |
I suppose somebody somewhere has made a list of which functions to use for each thing you might want to accomplish, written in plain English; but I have never found it. I think most programmers learn by looking at existing code, which is problematic because C has some old highly-deprecated standard library functions that should not be used. |
| 21:47 |
muurkha |
if I type `man -k compare` I get output reading in part |
| 21:47 |
muurkha |
strcasecmp (3) - compare two strings ignoring case |
| 21:47 |
muurkha |
strcmp (3) - compare two strings |
| 21:47 |
muurkha |
strcoll (3) - compare two strings using the current locale |
| 21:47 |
muurkha |
strncasecmp (3) - compare two strings ignoring case |
| 21:47 |
muurkha |
strncmp (3) - compare two strings |
| 21:47 |
muurkha |
strverscmp (3) - compare two version strings |
| 21:47 |
|
muurkha was kicked by ShadowBot: Message flood detected. Use a pastebin like paste.ubuntu.com. |
| 21:47 |
jonadab |
And yes, pretty much all data structures in C are "this is an array of integers, but if you play your cards right you can get the compiler to pretend it's something else." |
| 21:47 |
MTDiscord |
<jordan4ibanez> char* word = "hi there"; |
| 21:47 |
|
muurkha joined #minetest |
| 21:47 |
muurkha |
oops! |
| 21:48 |
muurkha |
anyway you get the idea |
| 21:48 |
MTDiscord |
<jordan4ibanez> C is the wild west, you can have your entire program logic encoded into a char* then have a compiler run it as interpreted |
| 21:48 |
MTDiscord |
<jordan4ibanez> Did I just describe lua? |
| 21:49 |
muurkha |
anyway most of this stuff is about writing new code, not modifying old code |
| 21:49 |
jonadab |
lua has its *own* problems. |
| 21:49 |
MTDiscord |
<jordan4ibanez> Lua is making them YOUR problem now >:D |
| 21:50 |
muurkha |
I don't want to oversell C's maintainability but it doesn't seem to be as bad as you might think from the napalm exploding wall problem |
| 21:50 |
muurkha |
jordan4ibanez: you can do that in any programming language? |
| 21:50 |
jonadab |
YOu can write bad code in any language, yes. |
| 21:51 |
muurkha |
I mean that's pretty much the definition of Turing-completeness |
| 21:51 |
MTDiscord |
<jordan4ibanez> Of course not, but when you have a million C strings like we do and all of a sudden there's a random non \0 terminated string you will never find out why |
| 21:51 |
MTDiscord |
<jordan4ibanez> joadab: Who told you about my bad coding policy? |
| 21:51 |
muurkha |
I take issue with this apparent idea that making your logic data-driven necessarily makes it worse |
| 21:52 |
muurkha |
very often putting your program logic into data structures makes the program better |
| 21:52 |
MTDiscord |
<jordan4ibanez> No, I'm not talking about logic driven data, I'm talking about working with raw pointers like we're cavemen on an old ibm mainframe |
| 21:52 |
jonadab |
And yes, a proper string data type is one of the things I miss in C. Although associative arrays (like e.g. Perl's hashes) are the *big* ticket data structure IMO. |
| 21:52 |
muurkha |
you might be interested in reading https://nullprogram.com/blog/2023/09/30/ |
| 21:53 |
muurkha |
writing a hash table in C is not such a huge magilla |
| 21:53 |
muurkha |
it's the kind of thing you can do as a coding exercise during a job interview |
| 21:53 |
MTDiscord |
<jordan4ibanez> Your code is only smart and clever until it's not, memory safety as optional can lead to things like this https://youtu.be/I86d0QhaW0s?feature=shared in which I really which I had a unique pointer but it's lua |
| 21:54 |
jonadab |
Of course you *can* write it in C. Perl is written in C. It's Turing complete, you can write anything in it. That's missing the point. |
| 21:54 |
jonadab |
C doesn't have baked-in syntax and compile-time safety checks for such data structures. |
| 21:54 |
jonadab |
Well, it sort of has baked-in syntax for strings, but. |
| 21:54 |
muurkha |
yeah, just, bad strings. |
| 21:54 |
jonadab |
Yes. |
| 21:55 |
jonadab |
Strings that, if they might change in length, your code has to manually handle memory allocation for that, and also keep track of how much space is currently allocated, and ... |
| 21:56 |
MTDiscord |
<jordan4ibanez> { char* hello = "hello, world"; } Memory leak |
| 21:56 |
muurkha |
that's not a memory leak |
| 21:56 |
jonadab |
It's possible to design a language that allows the programmer to do low-level things, without *forcing* the programmer to *constantly* micromanage a ton of low-level things when it isn't necessary. |
| 21:56 |
muurkha |
jonadab: sure, but in some contexts that's not a big problem. in the contexts where it is you can use stralloc oor |
| 21:56 |
MTDiscord |
<jordan4ibanez> where is my pointer freed? This is not a unique pointer, and if you're counting the program closing as a free that's a problem |
| 21:57 |
muurkha |
*stralloc or APR |
| 21:57 |
muurkha |
jordan4ibanez: that pointer points to statically allocated, read-only memory |
| 21:57 |
jonadab |
Doesn't the compiler use the same memory address for the constant string every time that function runs? |
| 21:57 |
muurkha |
yes |
| 21:57 |
muurkha |
so it doesn't need to be freed |
| 21:58 |
jonadab |
Memory leaks can be a thing in C, but they require more tom-foolery than that. |
| 21:58 |
MTDiscord |
<jordan4ibanez> Well okay fine fine { char* str = new char[5]; } semantics, semantics |
| 21:58 |
muurkha |
it's probably unsurprising that the people who are least enthusiastic about C are the ones who have fundamental misconceptions about it :) |
| 21:58 |
muurkha |
jordan4ibanez: that's not even C |
| 21:59 |
MTDiscord |
<jordan4ibanez> C, C++, C is just procedural C++ at this point |
| 21:59 |
muurkha |
nope, they're totally different languages |
| 21:59 |
|
e1z0 joined #minetest |
| 21:59 |
MTDiscord |
<jordan4ibanez> It's like C++ if you wanted to have a good cry after having vscode open |
| 21:59 |
jonadab |
For varying values of "totally" |
| 21:59 |
muurkha |
C++ lacks most of C's good points |
| 22:00 |
jonadab |
C and C++ are *distinct* languages, but they have quite a lot in common. |
| 22:00 |
Desour |
C is to C++ like lying on the floor is to driving a one-wheel bike |
| 22:00 |
muurkha |
...which doesn't prevent C++ from being the only viable language choice in some environments, but I digress |
| 22:00 |
muurkha |
hahaha |
| 22:00 |
Desour |
(bad comparison) |
| 22:01 |
celeron55 |
C is a cross-platform macroassembler |
| 22:01 |
celeron55 |
C++ is a high level language |
| 22:01 |
celeron55 |
8) |
| 22:01 |
jonadab |
C++ inherits a lot of C's weaknesses, and adds some issues of its own. Also, its way of being object-oriented is fundamentally terrible. |
| 22:01 |
muurkha |
C++ is a cross-platform macroassembler that thinks it's a high level language |
| 22:01 |
MTDiscord |
<jordan4ibanez> So you're saying we should use Rust? |
| 22:02 |
muurkha |
Rust is pretty nice |
| 22:02 |
Desour |
jordan4ibanez: so I guess this is why you get issues with [png leaks x) https://www.youtube.com/watch?v=H80vlVfVZHQ |
| 22:02 |
celeron55 |
well, C++ mostly supports C, so it just adds stuff really. it's the programmer's choice how much of the C stuff and the added stuff they use |
| 22:02 |
muurkha |
but it certainly isn't a small, simple language like C |
| 22:02 |
celeron55 |
as a result, C++ isn't really even a single language. what kind of language it is depends on how you use it |
| 22:02 |
muurkha |
celeron55: you're talking about writing new code, but maintenance is the real key |
| 22:02 |
jonadab |
Do we have enough Rust programmers, and a reasonable path to phase it in a bit at a time so the rewrite doesn't have to happen all at once from one release to the next? |
| 22:02 |
MTDiscord |
<jordan4ibanez> Yes hahaha, it's crazy. 32 GB of ram and I watch it all go away slowly |
| 22:03 |
jonadab |
I have nothing especially against Rust, but I don't know how practicable moving to it would be at the moment. |
| 22:03 |
jonadab |
For reasons that don't involve flaws in the language iteself. |
| 22:04 |
|
v-rob joined #minetest |
| 22:04 |
muurkha |
celeron55: when you're maintaining someone else's code you don't get to choose which of C++'s numerous footguns they loaded |
| 22:04 |
Desour |
Rust is too easy. it removes the fun and stockholm syndrome |
| 22:04 |
muurkha |
I wouldn't describe Rust as "easy" |
| 22:04 |
MTDiscord |
<jordan4ibanez> I think it's the equivalent to trying to race a citroen 2cv (c++ maintain) against a buggati eb 110 (rust dev) |
| 22:05 |
jonadab |
If we wanted easy, we'd write everything in Perl. Ahem. |
| 22:05 |
muurkha |
rather, it frontloads the pain |
| 22:05 |
celeron55 |
i've been trying to learn some rust, but i have very little time for that, an MT rewrite is out of scope for me. but if some crazy people are doing such a rewrite and for some reason ask me for opinions about the design, i'm not a total dummy in that subject |
| 22:05 |
Desour |
(but on a serious note, rewriting in rust would take up too many development resources, resources that we need elsewhere) |
| 22:05 |
celeron55 |
muurkha: of course as a maintainer you're not the one who chooses the language |
| 22:05 |
jonadab |
(The performance might even be ok, as long as everyone agrees to install ten times as much RAM.) |
| 22:05 |
muurkha |
celeron55: true! |
| 22:05 |
MTDiscord |
<jordan4ibanez> Well if the project suddenly appears in the minetest github group thing I'll shift into 10th gear real quick |
| 22:06 |
muurkha |
celeron55: but you get to choose which projects too work oon |
| 22:06 |
muurkha |
Desour: once your Rust code compiles it is a lot more likely to work than Lua or C code |
| 22:06 |
celeron55 |
muurkha: well, depends |
| 22:06 |
MTDiscord |
<jordan4ibanez> In rust we have 128 bits so the world can be 32 bit in all directions |
| 22:06 |
jonadab |
Yes, but you can only maintain code that has been written. |
| 22:06 |
muurkha |
but getting to that point can be immense pain |
| 22:07 |
MTDiscord |
<jordan4ibanez> Or maybe that's 128 -> 64 bit, I forgot how we cache positions |
| 22:07 |
muurkha |
jordan4ibanez: you can use 128-bit data types in C too |
| 22:07 |
MTDiscord |
<jordan4ibanez> I C what you mean but good luck converting minetest to that |
| 22:07 |
MTDiscord |
<jordan4ibanez> framework, infrastructure, buzzwords, |
| 22:08 |
celeron55 |
if you use excessively large data types for everything, you end up using lots of memory. low memory usage doesn't come for free |
| 22:08 |
jonadab |
Speaking of bit size, when are MT coords going to be 64-bit? |
| 22:08 |
* jonadab |
hides. |
| 22:08 |
muurkha |
Desour: I don't think there's anybody choosing what "development resources" to assign to things in Minetest |
| 22:08 |
Desour |
128 bit integers aren't as fast on my cpu as 64 integers, fyi jordan4ibanez. |
| 22:09 |
MTDiscord |
<jordan4ibanez> So that would be 128 bits 32 bytes taking up 2 ram cells next to eachother hmm, that's pretty smart |
| 22:09 |
celeron55 |
also if you use big data types, you end up filling the cpu cache early and cause cache misses, and those make everything super slow. again one reason to use as small data types as possible |
| 22:10 |
MTDiscord |
<jordan4ibanez> So what if we have a hardcoded type so people can make the game as big or smol as desired? This is a horrible idea but it is an idea |
| 22:10 |
celeron55 |
once you get a cache miss, it doesn't matter how fast a cpu you have |
| 22:10 |
muurkha |
Desour: like, if erle is writing a camera mod, and you tell him "don't write a camera mod, fixing mobs_redo is more important", you might discourage him from writing the camera mod but you probably won't get him to work on fixing mobs_redo |
| 22:10 |
Desour |
muurkha: what I meant is that doing the transformation would take months or years. and if we do it partly, development becomes really hard in that period. we'd also have to fix bugs and whatnot that we introduce. instead of all that we could also work on practical features |
| 22:11 |
MTDiscord |
<jordan4ibanez> mt32 (not roland) mt64 mt128 maybe, but probably not, we can probably just go with 64 bit cap and raise it up, but also not hardcode it, we can instead use usize so it's automated |
| 22:11 |
muurkha |
it might be possible to rewrite parts of Irrlicht or MT in Rust without making development really hard |
| 22:11 |
MTDiscord |
<jordan4ibanez> Absolutely not |
| 22:12 |
MTDiscord |
<jordan4ibanez> The entirety of irrlicht is an unsafe block |
| 22:12 |
celeron55 |
there's not a single written and signed agreement within the entire official MT development or maintenance people. everyone can literally do whatever they want. it's just that if someone wants to use official technical resources (like the organization repos on github, or the domain), it's going to take either convincing me or doing a majority vote within core devs. that's all there is |
| 22:12 |
muurkha |
I mean you'd need a Rust compiler installed to build |
| 22:12 |
muurkha |
but otherwise I think the impact is probably pretty small. the benefit, too, though :) |
| 22:13 |
MTDiscord |
<jordan4ibanez> Okay fine |
| 22:13 |
MTDiscord |
<jordan4ibanez> I want to be the first core dev on the rust branch |
| 22:13 |
MTDiscord |
<jordan4ibanez> "branch" is a subjective word. "campsite" is probably better at this point |
| 22:15 |
celeron55 |
the rust version is probably best started as a personal repo by someone, and if it goes well, then it can be moved and made official. surviving in the wild outside of the official organization is a fairly good test in terms of whether people dedicated to the particular cause are easy enough to come by |
| 22:15 |
muurkha |
yes |
| 22:15 |
MTDiscord |
<jordan4ibanez> Time to get started then |
| 22:16 |
|
YuGiOhJCJ joined #minetest |
| 22:17 |
celeron55 |
and, it's also about being able to assign roles based on merit |
| 22:19 |
celeron55 |
when assigning a role to someone just based on them wanting the role, it generally doesn't work out. but when you assign a role based on what they actually did, that works much better - then you match a role with someone capable of fulfilling that role, and it even works as public recognition of what they've achieved |
| 22:19 |
v-rob |
It seems halfway funny to me that people think that Rust is some sort of silver bullet that will fix every problem that C++ has |
| 22:20 |
v-rob |
I'm no expert, but Rust looks just as bloated and over-feature-filled as C++. At least it has memory safety though. |
| 22:21 |
celeron55 |
it's almost as different as it can be, while still fulfilling essentially the same role |
| 22:22 |
celeron55 |
maybe like minetest vs. minecraft (ok maybe i'm stretching it) |
| 22:22 |
MTDiscord |
<jordan4ibanez> No no that sounds about right |
| 22:23 |
v-rob |
Oh, they're absolutely different. I'm just not convinced if "different" means "overwhelmingly better" in this case |
| 22:24 |
v-rob |
In safety, yes. In overall usability and maintainability of code written in the language? *shrug* |
| 22:26 |
v-rob |
Of course, I may be somewhat biased as someone who likes C++ for entirely inexplicable reasons. |
| 22:27 |
v-rob |
One thing's for sure: if anyone tried to undertake rewriting Minetest in Rust, they'd have to make sure that there are stable and mature Rust libraries to replace the C++ ones we use |
| 22:29 |
|
Desour_ joined #minetest |
| 22:29 |
|
sparky4 joined #minetest |
| 22:30 |
muurkha |
v-rob: Rust is pretty bloated, yeah, but much less error-prone |
| 22:32 |
muurkha |
I feel like it's better at higher-order programming, but recent C++ has improved a lot there, and Rust's lifetime inference makes HOP harder in Rust than in things like ML (even MLKit, which also uses lifetime inference) |
| 22:33 |
muurkha |
in a lot of cases you don't need to replace C++ libraries with Rust libraries; you can just call the C++ libraries from Rust. not, say, most of Boost, but things like Irrlicht |
| 22:46 |
celeron55 |
minetest wouldn't really benefit from rust's package ecosystem as a larger project like this can relatively easily manage dependencies and build systems on its own |
| 22:47 |
celeron55 |
for smaller projects and new projects it makes a difference though |
| 22:54 |
muurkha |
maybe. Rust without Cargo is a substantially poorer language |
| 22:58 |
celeron55 |
rust would go absolutely nowhere if it didn't have cargo |
| 22:58 |
celeron55 |
and crates.io |
| 22:58 |
celeron55 |
those set it apart just as much as the actual language features do |
| 22:59 |
celeron55 |
frankly it's easy to compete with C++ in build systems and packaging, but it is what it is |
| 23:03 |
muurkha |
error, tautology detected |
| 23:03 |
muurkha |
Gricean violation |
| 23:06 |
celeron55 |
not sure what you mean but i'm going to sleep now |
| 23:07 |
rubenwardy |
<celeron55> minetest wouldn't really benefit from rust's package ecosystem as a larger project like this can relatively easily manage dependencies and build systems on its own |
| 23:07 |
rubenwardy |
yet we use vcpkg and system package managers |
| 23:07 |
rubenwardy |
we probably wouldn't NIH so much if C++ came with a functional package system |
| 23:08 |
celeron55 |
it sounds easy until you realize you kind of don't want to produce statically linked binaries for linux distros |
| 23:08 |
celeron55 |
and android will probably still require android studio |
| 23:08 |
celeron55 |
and so on |
| 23:08 |
celeron55 |
it would help, but some of this is quite the perma-disaster |
| 23:08 |
rubenwardy |
android studio would hypothetically support this C++ package manager |
| 23:08 |
rubenwardy |
it supports cmake |
| 23:09 |
|
YuGiOhJCJ joined #minetest |
| 23:09 |
celeron55 |
i'm hoping C++ eventually gets there |
| 23:09 |
rubenwardy |
as for Linux, perhaps there would be integration with linux distros. So it would use dyamic binaries. But imo dynamic libraries are a source of a lot of pain on Linux, user applications like minetest might as well bundle most of them |
| 23:09 |
celeron55 |
but it might be too late already by then |
| 23:10 |
celeron55 |
does anyone have opinion about c++20 modules? if they were perfectly implemented by all compilers and platforms, would it help, or are we looking to see what the next C++ version contains? |
| 23:11 |
rubenwardy |
is there an automated way to switch to them? |
| 23:11 |
muurkha |
celeron55: it was sort of a joke |
| 23:11 |
rubenwardy |
are modules interoperable with headers? |
| 23:11 |
muurkha |
sleep well |
| 23:12 |
rubenwardy |
sleep well though |
| 23:12 |
muurkha |
it's not too far from the truth to consider Debian's apt and dpkg as a usable package system for C libraries |
| 23:12 |
Desour_ |
I haven't used modules yet, but we definitely want them for build speed |
| 23:12 |
rubenwardy |
I tried to use C++20 modules in like 2021, compiler support wasn't there yet. Gave up on C++ (mostly) for personal stuff soon afterwards |
| 23:13 |
muurkha |
what are you using instead, rubenwardy? |
| 23:13 |
rubenwardy |
Godot, with GDScript but will probably use C# for larger projects |
| 23:13 |
rubenwardy |
I still use C++ for embedded |
| 23:14 |
Desour_ |
using a different game engine... traitor! get the pitchforks! |
| 23:14 |
muurkha |
Godot is pretty nice from what I've seen |
| 23:14 |
rubenwardy |
I occasionally want to make non-blocky games |
| 23:15 |
rubenwardy |
shocking |
| 23:15 |
muurkha |
my wife used it in a game jam with her boyfriend and his girlfriend a couple years back |
| 23:15 |
muurkha |
they were one of the few teams to ship a playable game |
| 23:15 |
rubenwardy |
ah cool |
| 23:15 |
rubenwardy |
I wrote about it here: https://blog.rubenwardy.com/2023/07/14/make-games-not-game-engines/ |
| 23:16 |
muurkha |
I like making engines, don't hold it against me |
| 23:16 |
rubenwardy |
that's fine, that's fun too! |
| 23:19 |
muurkha |
haha, "not as much of a problem with Godot, as it has zero bugs" |
| 23:23 |
rubenwardy |
Anyone remember that really old bug that spawned hands everywhere? It think it was something to do with static data being lost. Can't find the issue / screenshots right now |
| 23:25 |
sfan5 |
I can vaguely recall that |
| 23:25 |
Desour_ |
oh, you mean the feature where tnt teared off your hand? |
| 23:27 |
MTDiscord |
<rollerozxa> rubenwardy: like, registering the hand item as a node and then have it get splattered on every biome without a dust node? |
| 23:27 |
rubenwardy |
I think it was something to do with dropped items. Loads of hands just appeared in the world |
| 23:31 |
Mantar |
this justs in: minetest supports hands-free gaming |
| 23:32 |
|
panwolfram joined #minetest |
