What’s up with all these posts lately talking as if C was the chain breaker that will let you achieve a higher spiritual level for your soul or some shit. This is at least the second I’ve seen this week.

It’s a programming language. If you want to use it, use it. There is no illuminati pulling in the strings to prevent you from learning this holy language.

That being said, like all programming languages, it’s a tool, with its upsides and downsides. Depending on the project it might be the best choice or the worst. But with the advancement in language design, there’s very little upsides compared to more modern languages, taking into account its big downsides.

It’s a one line function in an example. It’s a getter.

Lmao, and they say dynamic typing is supposed to speed up the developer.

This is literally a getter function. How is a getter awful code? It’s the simplest function there is. The only function simpler than that is returning the input itself.

Python doesn’t check the types of function headers though. They’re only hints for the programmer.

For rust I use iced, as it meets all my needs and is a delight to work in. I don’t think it’s good for making graphs though. For graphs I heard that people like matplotlib (in python), which you can also use inside PyQt apps. I’ve tried using matplotlib and did not enjoy the experience at all, but I don’t know of any alternatives.

To be fair, in that article mentions the way to get rust from C. Sure, there is not a compiler written in C, but C is down there in the list of compilers needed for rust, so “just” need to compile some other compilers in the middle.

The bedrock of modern civilizations is expensive to develop, buggy and unergonomic though.

If you make C run, you probably (I’m not sure, would have to verify) can make rust run. And if there isn’t yet, there will probably soon be a C compiler written in rust, so you can choose to bootstrap from wherever you prefer.

C’s ABI will probably last longer than C, since there is not a stable rust ABI though.

To be fair, mechanic items, and especially electronic ones were far more repairable back then.

You could see, desolder and solder components without issue. Nowadays most of the electronics are inside chips, and only the components that need to be physically big (like those responsible for the power supply) are human sized. Sure, there are some small SMD that can be manually diagnosed and replaced, but even then you often need a lot of skill and equipment.

The good thing about Box::leak() is that it returns a raw *mut pointer. So you need unsafe{} to dereference it. Might as well: let my_ref = &mut unsafe{*ptr}; while you are at it, so you have a perfectly normal rust reference, so the function signatures don’t need any change.

The problem with Rc is that it would also require a RefCell most of the time. So the whole thing would be filled with Rc<RefCell<T>>. With the required .borrow_mut(). It would both do a pain to do and undo.

And of course I want to undo it, because RC is a shitty GC.

I’ve re-thought about the problem and I think for prototyping I should just Box::leak() and work with raw pointers.

This approach also doesn’t allow you to not learn the borrow checker, since leaking everything is not a good memory management strategy, but might be fine for rapidly iterating on a design.

EDIT: maybe use a leak!() Macro that does Box::leak(Box::new()) in debug mode but panics on release (as long as you execute once in release it should be fine).

I did.

Another user already proposed Odin, but no one yet Jonathan blow’s unnamed programming language (people call it jay). Those are the 2 programming languages that came to mind when I think of game development.

I haven’t tried either so I don’t know if they fit you, but they are new languages so they should avoid java’s and C++'s pitfalls.

Interfaces (traits in rust) are the best imo. Way better than raw structs in C or the mess that is inheritance.

What I don’t like about go’s interfaces is that they’re implemented implicitly. I much prefer java’s and Rust’s way to implicitly say which classes/structs extend/implement which interfaces.

Using “clever” ways to disable the borrow checker is one of the few things I don’t like about rust. I much rather it having a “borrow checker version” and a “garbage collector version”. That way we could rapidly iterate through design choices with the GC, and once the design has proven good, apply lifetimes and such to use with the borrow checker. The only downside to this I can think of is that most would just leave it in the GC version and not bother to move to borrow checker. But that’s fine by me, rust has many other features to take advantage of. As long as no GC libraries are allowed in crates.io, it should be fine.

You can just. Have datastruct be mutable if you want. Immutable by default doesn’t mean you can’t make variables mutable.

My favourite is when every error is an HTTP Bad Request with no body. Absolutely wonderful to use those APIs

Yes.it is hype. Because it is a product still in development. Windows is not yet officially supported, and they announced Linux like one month ago.

It still lacks some basic features. However, what they already have looks good, it is much more performant that vscode.

Storing them in files with correct permissions.

Git is not the only version control software out there, and not the first one either.

Facebook for example is famous for not using git. Because their own modified copy of mercurial fits their needs better.

Microsoft didn’t use git until relatively recently either. They had to make some big contributions to make it work for their system.