Timeline for C++ and memory safety
Current License: CC BY-SA 4.0
28 events
| when toggle format | what | by | license | comment | |
|---|---|---|---|---|---|
| Sep 17, 2024 at 8:33 | comment | added | freakish | As for 3d models or similar assets, I'm pretty sure these are distributed in a language independent formats. Bevy supports multiple such formats. So you can buy an asset from UE store and use it with bevy, I don't think it is a problem at all. At least technically, UE store might prohibit that, I do not know. | |
| Sep 16, 2024 at 8:45 | comment | added | freakish | @Caleth I don't know much about game development, especially how licencing works (I've been doing some private projects only, for fun), so I can't really say. But for physics, graphics, networking, etc. then yes, Rust has crates (modules) for each, and bevy does come with them out of the box. As far as I'm aware all of that is free to use and modify. Bevy does not have a fancy editor like UE though, but it is on the roadmap AFAIK. | |
| Sep 16, 2024 at 8:44 | comment | added | Caleth | @freakish As in, can you as a solo or small team, licence something featureful enough to be able to make your game, not having to write all the physics, graphics, networking, etc yourself. Bonus points for also being able to licence animated 3d models of whatever as 3rd party plugins | |
| Sep 16, 2024 at 8:39 | comment | added | freakish | @Caleth what do you mean by "commercially available" and why does it matter? Rust does have multiple game engines, I've been using one myself: bevy. Free to use and open source, btw. It is not as mature as Unreal Engine, but then again entire Rust isn't. As I said: a matter of time. | |
| Sep 16, 2024 at 8:35 | comment | added | Caleth | @freakish I wouldn't call Unreal Engine legacy tech debt. But using it is one of a small number of options when developing a 3d game to modern standards. I'm not aware of any commercially available game engines in rust or ada. | |
| Sep 16, 2024 at 8:31 | comment | added | freakish | @Caleth sure, legacy and technological debt is no joke. And the only real reason we keep using those outdated tech stacks. That being said it is just a matter of time, hopefully. The movement has already started. In fact there's even DARPA project sponsored by the USA government (I think) which aims to translate entire C to Rust. Ambitious? Sure. But the fact that it exists already says much. | |
| Sep 16, 2024 at 8:29 | comment | added | Caleth | @freakish your assertion of "objectively better language" is not universal. If you already have 1M lines of C++, it's not better to start from scratch in rust, you will run out of money before you have reimplemented the features you already have, and even if you don't, you'll introduce a whole bunch of new bugs. | |
| Sep 14, 2024 at 17:26 | history | edited | Christophe | CC BY-SA 4.0 |
added 55 characters in body
|
| Sep 14, 2024 at 17:18 | history | edited | Christophe | CC BY-SA 4.0 |
added 1609 characters in body
|
| Sep 14, 2024 at 16:59 | comment | added | freakish | Is that the thing you say when you run out of arguments? Because there are objectively better and worse languages. Otherwise everyone would still be writing direct machine code, not even assembly. Yes, it does solve real world problems. Again: why do you think Rust was created? For fun? | |
| Sep 14, 2024 at 13:02 | comment | added | Christophe | @freakish as said, language war and my-language-is-better-than-yours arguments are not constructive and do not help in solving real word problems. | |
| Sep 14, 2024 at 11:45 | comment | added | freakish | And at least Rust issues do not outweight C++ issues. There's a reason why it become second language (after C) in Linux kernel development, even though C++ exists for like what? 50 years? | |
| Sep 14, 2024 at 11:17 | comment | added | freakish | @Christophe ridiculous. Rust was literally created so that we depend less on people. If a tool can take care of a problem I see no reason to depend on people. And the fact that Rust or Ada also have issues is no argument for using C++. Unless those issues outweight C++ issues. | |
| Sep 14, 2024 at 10:56 | comment | added | Christophe | @freakish safety requires a constant effort in all languages. I'm pretty sure that deadlocks are possible in Ada, first papers on insecurity of rust start to emerge (attacks via common packages using unsecure features), and whatever language, it's only a matter of time to stumble on some issues (caused by the language or its implementation or a commonly used library: the end result is the same). My message here: ranting on languages has no benefit in safe and secure programming. It's people and engineering discipline that makes the difference. | |
| Sep 14, 2024 at 9:23 | comment | added | freakish | For example thread safety is notoriously hard to test. That's why languages like Rust heavily restrict what you can and cannot do with respect to threads. C++ does not. Literally no C++ feature helps you writing thread safe code. | |
| Sep 14, 2024 at 8:04 | comment | added | freakish | And tests are only as good as the person writing them is. Which typically means a lot worse than what proper static analyzers can do (I'm thinking about Ada and Rust, C++ cannot be properly analyzed due to its nature). The only reason to use C++ is because of its amazing performance, nothing else. | |
| Sep 14, 2024 at 7:47 | comment | added | freakish | @Christophe most critical systems in spacecrafts, rockets and powerplants are written in Ada, not C++. Precisely because of Ada's safety. C++ is s**t language for masochists. Yes, you can write safe code in it. Except the language itself taunts you to do otherwise. Safe pointers? Sure, except most libs still use raw pointers. Good luck with that, or write everything from scratch. | |
| Jun 18, 2024 at 20:29 | comment | added | Basilevs | That's the problem. It is much harder to design protection against UB than against DB. And all modern languages have const or even value objects, that's a given, not an advantage. Driven or not, safety is never a commodity in C++. | |
| Jun 18, 2024 at 18:44 | comment | added | Christophe | At the same time C++ offers const functions to prevent accidental changes of an object's state, which is a very common issue in other languages. What I want to say here is that you cannot generalise your own experience. There are a lot of C++ developments that are not al all driven by SEGV. (but hopefully test driven). | |
| Jun 18, 2024 at 18:40 | comment | added | Christophe | @Basilev but doesn't everybody do tests, whatever the language? Don't we mix here very different problems ? I mean, you can have a similar code like pschils in lemory safe languages like Swift. You wouldn't have UB but you would not iterate on the latest version of v. If this loops would be to calculate insulin dosage, it could mean life or death even if it's not UB in swift. On the other side you can by design prevent these situations in C++ as well. I use for example a lot copies when there is a risk of conflict. | |
| Jun 18, 2024 at 17:41 | comment | added | Basilevs | they can and do test | |
| Jun 18, 2024 at 12:42 | comment | added | Christophe | @Basilevs strange that sonfar most of the spacecrafts, rockets, planes, powerplants and life critical systems that cannot bear any interuotions were development in C++. | |
| Jun 18, 2024 at 8:54 | comment | added | Basilevs | There are no reliable ways to work with C++. You can only test and do SEGV driven development. | |
| Jun 18, 2024 at 8:48 | comment | added | Basilevs | I have 10 years of experience with C++ and worked professionally with it for 6 years I've hit the UB @pschill describes multiple times and there was nothing I could do to predict it. There are NO raw pointers in his example. The UB is very well hidden. The reference to a vector being updated or iterator over it may be obtained indirectly. I perfectly understand the nature of this particular UB and it does not help a bit. | |
| Jun 18, 2024 at 7:07 | comment | added | Christophe | @Basilevs as long time practitioner having worked with C++ since before templates even existed, and having witnessed the emergence of cleaner ways to do things since modern c++11, I simply do not agree. The main risk with C++ is caused by a lot of teachers around the world who still teach C idioms and malloc() in C++, have not inderstood the C*+ object model and perpetuate UB behaviors and use of raw pointers because they feel powerful in doing so. Such a way of teaching should be considered as a crime. | |
| Jun 18, 2024 at 5:12 | comment | added | Basilevs | The lifetime is next to impossible to predict in C++. See answer by @pschill | |
| Jun 17, 2024 at 18:48 | history | edited | Christophe | CC BY-SA 4.0 |
added 5 characters in body
|
| Jun 17, 2024 at 18:34 | history | answered | Christophe | CC BY-SA 4.0 |