Time Nick Message 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' 11:05 sfan5 not sure, we don't have anyone to test the builds before release 18:47 MTDiscord 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 No not that one, I mean, an official one 18:48 MTDiscord 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 "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 We start very basic because this project is still words on an irc & discord 18:56 MTDiscord 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:58 MTDiscord 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 Yes there is a safe luajit library actually, I built crafter in rust with it 18:59 MTDiscord Let me go find it 18:59 MTDiscord luajit itself is hardly safe 19:00 MTDiscord lua to wasm transpiler would be nice 19:00 mrkubax10 WASM is becoming some sort of universal virtual machine 19:00 MTDiscord https://crates.io/crates/mlua/ 19:01 MTDiscord there's a strong need for a universal vm with native performance and sandboxing 19:02 MTDiscord 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 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 You can also peak/grab/mod the luajit vm as it's running as needed 19:12 MTDiscord 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 We can even go as far as to dynamically link/load compiled rust mods 19:27 MTDiscord - 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 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 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:46 MTDiscord 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: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: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 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 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 Rewrites are actually perfectly fine as long as you don't rewrite the actual code 😏 20:19 MTDiscord 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 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 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:33 MTDiscord 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: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 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 char* word = "hi there"; 21:47 muurkha oops! 21:48 muurkha anyway you get the idea 21:48 MTDiscord 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 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 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 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 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 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 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 { 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 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 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 C, C++, C is just procedural C++ at this point 21:59 muurkha nope, they're totally different languages 21:59 MTDiscord 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 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 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 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 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 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 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 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 I C what you mean but good luck converting minetest to that 22:07 MTDiscord 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 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 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 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 Absolutely not 22:12 MTDiscord 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 Okay fine 22:13 MTDiscord I want to be the first core dev on the rust branch 22:13 MTDiscord "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 Time to get started then 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 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: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 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 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 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