baszalmstra

Really? That is your response? This is an high quality article from someone who spend a lot of time implementing a cool tool and also sharing the intricate inner workings of it. And your response is, "eh there are no official binaries for my platform". Give them some credit! Be a little more constructive!

Jep! Pixi works on any linux distribution. The ros packages only require glibc to be available, the rest is installed by pixi. This means you can run any ros distro on any version of ubuntu (or any other glibc based linux for that matter). Including ros1 noetic!

Great to hear! You peaked my interest now! I would love to know more about your usecase! Would you be open to join our discord to talk about it?

Rattler author here! I just published v0.1.0 to crates.

That's too bad, I would've loved to do this from a docker container.

Jai is actually closed source, so that was not an option. But in general there are no predefined best practices for achieving hot reloading of both functions and data. Experimenting with those while also fighting with complex compilers makes the problem space exponentially more intractable.

like sun and mundane

Thank you, we will incorporate that. Can you elaborate on what the things are you are seeking about who we are?

In theory yes, but we have to look into that some more. At this point we only target Windows, MacOS and Linux but WASM is definitely on our list.

Mun is primarily focused on hotloading, the ability to change your code while its running. Our goal is to enable hotloading of all constructs including structs (similar to how Lua works) and without having to annotate anything.

LuaJIT performance on PC is very fast when its using the JIT. However, on consoles and some mobile platforms JITing is not allowed due to not being allowed to write to executable memory for security reasons.

Mun compiles to machine code with LLVM so it should be very fast as well, hotloading overhead can be completely removed in builds where hotloading is not required (production builds for instance). Mun should therefor be able to run as fast as native code on all platforms.

Thats precisely the reason its written like that in Mun

Actually:

1. Mun exists because of frustrations with Lua.

2. Lua means "moon" in Portuguese.

3. The "moon" in KSP is named: Mun.

Voila

One of the creators here. I appreciate the upvotes but its way too soon for that. Mun is currently in the very very early stages of development. It originated out of frustrations with Lua game development at Abbey Games. Lua is a great language but lacks performance, refactoring functionality and doesn't scale well with modern technology. However, there is no real alternative when it comes to code iteration times.

I do understand some of the comments questioning the publication of a website for a programming language that isn't even finished. Our goal was to have a platform to share progress and gauge interest on the topic to further help us develop Mun. We feel like there is no point in developing a programming language in private. Instead we want to actively engage with the community while developing Mun.

The website does state that its still in very early development. Should we emphasize this more?

How do loot boxes compare to all the different kind of booster packs out there in terms of gambling? I feel there is little difference, should they then be banned too?

absolutely +1 for this

Can you comment on the problems you ran into with LFS?

We have tried out plastic but lost our changes on a few occusions because the tool came to a state where you simply couldnt merge. Stashing in those cases also failed. It was terrible. Losing your changes should never ever happen especially for a quite pricy solution.

We are now using git lfs which so far works like a charm.