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!
Yay! :) Thanks heaps! It's funny, 'rattler' is exactly what I need at the moment. I was about to write a rust app that downloads 'micromamba' and runs it as a subprocess. But this is so much better for what I try to do, being able to include everything in a single binary and calling rust code directly...
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.
So, why do we need yet another language to reap hot-reloading, instead of adding it to say Rust, Zig or (blow me) Jai? Is there something about those languages that complicates hot-reloading?
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.
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?
> We take inspiration from a scala of application, scripting, and systems programming languages
The word "scala" reads really oddly in that sentence; none of the English-language meanings of the word [1] fits, and to a technical reader it's just asking for confusion with the Scala language. Maybe replace with a clearer and less formal "bunch"?
The syntax shown looks very Rusty, and I believe this started as a thought experiment for Rust. Do you see value in keeping that link explicit? That is, using Mun as a prototyping language for early iteration, then "freezing" it to vanilla Rust with minimal syntax changes once happy with the result?
Also, if the goal here is fast iteration, it'd be interesting to see some ballpark figures for compilation times, which is one of Rust's major Achilles heels today.
Can I suggest that what you wrote here is actually a much better opening motivation than what’s on your site?
1) We like this thing that fits into the following use case
2) But we feel it has the following limitations
3) Which we’re planning to address like this.
I think it’s really important to establish what ecosystem slot you’re aiming at. If it makes it to others, fine.
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.
LuaJIT is not available on every platform. Love2D for example is pretty slow on iOS, especially at computing paths etc for custom draw calls.
Defold is slightly different, still allowing Lua scripting, but not more than that, which is the appropriate place for Lua in a mobile-dominated market.
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?
Gambling is not banned in Belgium, it is regulated. There is a state-owned lottery, plenty of casino's, sportsbetting companies etc. One thing that is banned is selling gambling products to minors.
You are right that booster-pack based collectible card games are basically gambling (and they are definitely also targeting minors). However, there is also a significant difference between a game that front-loads this gambling (you know what you are getting into, and you buy and construct your card deck before a game) and a game that tacks it on an existing game. It a gray zone if the loot box contents offer no in-game advantage (e.g. Valve sticks to purely cosmetic items for their games), but is pretty sinister from both the game design and ethical perspective if it offers an edge in the game. It's back-loaded gambling, where a pay-gamble-to-win scenario is dangled in front of the player after getting killed in a shooter.
