Due to potential new direction of D, I’m looking for some escape route just in case. I’m primarily a gamedev, so no functional programming languages like Rust or Haskell. Also one of the features I dislike the most in C/C++ is the super slow and super obsolete precompiler with its header files, so no zig, I don’t want to open two files for editing the same class/struct. Memory safety is nice to have, but not a requirement, at worst case scenario I’ll just create struct SafeArray<Type>. Also I need optional OOP features instead of reinventing OOP with all kinds of hacks many do when I would need it.
Yes I know about OpenD, and could be a candidate for such things, just looking into alternatives.
What?
Yeah, it’s got some features typically found in functional languages, like first-class functions (being able to pass around functions like values) and various list functions, e.g.
.map(),.filter()etc., but the basic control flow is very much imperative.you can even do
(a == b).then(
which turns a bool into an Option
I wouldn’t even call that a functional feature, that’s just the language being based on expressions and
boolhaving athenmethod. It’s more object-oriented in that sense if anything tbhYou forgot immutable by default.
Right. 😅
Apparently, we’re on different pages in this regard, but to me these are less functional language features and more just modern language features.
In my not-so-humble opinion, it was never a good idea to make everything mutable by default. It adds so much mental overhead to try to keep track of where your state could be getting modified, especially in multi-threaded scenarios.
We just didn’t have the type system expertise and compiler technology to enforce it without runtime overhead. Now that we have that, I don’t think any full-fledged programming language should be released with everything mutable by default.
I only had a bug once from unintended data mutation. In a GUI setting nonetheless, where state mutability is a must. The fix and tracking down the bug took 2-3 hours at max. No thanks, I’ll be staying with
datastruct.nextState()rather thanconst nextState = prevState.nextState()(which is even harder to from the inside), or even worse, passing around global states in a function argument at an attempt of having a program state, which is essential for gaming. You know, games are famous for having interactibility, and not just about walking around in a static world (which is allegedly a thing for the few Rust games).You can just. Have
datastructbe mutable if you want. Immutable by default doesn’t mean you can’t make variables mutable.I also never had an accident where I needed the seatbelt
How many bugs you encounter is unfortunately not a good metric, because devs will compensate by just thinking harder. The goal is rather to not need to think as hard, which increases productivity and helps out your team members (including your future self).
It took me a few months of working in an immutable-by-default language before I had the epiphany that everything is exactly like it’s written down in code (so long as it’s not marked as mutable). I don’t need to look at each variable and think about whether it might get changed somewhere down the line. A whole section of my brain just switched off that day.
As the other person said, there’s also nothing stopping you from using mutability, it’s just not the default, because most variables simply don’t get mutated, even in C code.
But I would even go so far that Rust is actually making mutability fashionable again. It has introduced various new concepts in this regard, which you won’t know from other languages.
For example, you can opt a variable into mutability, make your changes and then opt out of it again.
And if a function wants to modify one of its parameters, you have to explicitly pass a mutable reference, which is visible both in the function signature and where you’re calling the function.
But perhaps most importantly, it blocks you from mutating variables that you’ve passed into a different thread (unless you wrap the value in a mutex or similar).
In most of the immutable languages up until this point, the immutability was achieved by always copying memory when you want to change it, which is insanely inefficient. Rust doesn’t need this, by instead requiring that you follow its ownership/borrowing rules.
Edit:
I also don’t know what you heard, but this is for example written in Rust: https://bevyengine.org/examples/3d-rendering/bloom-3d/
The code is right below. It uses lots of mutability…
Or, if one prefers, having more flexibility to choose how and where to allocate mental energy, rather than letting the language force you to spend some amount on the “bookkeeping” necessary to avoid various footguns.
I really wanna know where you get your language info and examples from because nearly every single one you wrote in your comments is just wrong.
Program state in Rust isn’t immutable.
datastruct.nextState()is not only possible, but perfectly reasonable, it’s exactly how iterators are implemented.You can easily do the first option in Rust, you just use the
mutkeyword. That’s it, nothing more than that. And you’ll find that you quite rarely have to do that, and when you do it, it’s actually quite a useful signal to be aware of, since mutability sometimes means a bit more surprising data changes.I see your point though. It feels like people giving advice on Rust used it 3minutes. It really depends on how trait are structured and often times they are horribly difficult.
It’s because of the borrow checker complaining. It’s especially hard with Async stuff.
Rust is good, it’s not perfect for everyone. I wouldn’t recommend for gamedev. You might like C# with native modules in Godot, you can extend it pretty much how you want.
Less C++ stuff, more fun!
But yeah that’s a problem, if you want a system programming language it’s hard to get away from C/C++ lol.
Sorry but immutable by default just makes sense. When you start coding Rust you’ll see how rarely you actually need to use the
mutkeyword. It’s quite rare actually.C++ has a bunch of functional properties. It has lambdas, function pointers which allow currying, higher order functions, it has of course pure functions, functors, recursion, lazy evaluation, a type system supporting lambda calculus, and so on.
C++ is the dumping ground of programming paradigms. Name a paradigm and C++ probably has it. Just because another programming language supports some aspects of a paradigm doesn’t make it pure. Or for another a more common example: just because it quacks like a duck, doesn’t always mean its a duck.
In other words, rust is about as functional as C++. Plus minus a few things.
Anti Commercial-AI license
C++ is very cool for that. If only there weren’t 20 operators overload for everything it wouldn’t be as hard to work with it!
I still love it from times to times (in reasonable dose)
OP probably means no cult languages