digitalmars.D - [OT] Safer C
- Sergey (14/14) Nov 17 It is kinda interesting that at the same time several projects
- Kagamin (1/6) Nov 21 Quote of the day, lol.
- Gregor =?UTF-8?B?TcO8Y2ts?= (33/39) Nov 22 I think that there is a quite common sentiment these days that
- Paulo Pinto (4/44) Nov 23 That language will arrive too late for what is already happening
- Gregor =?UTF-8?B?TcO8Y2ts?= (27/80) Nov 26 I doubt that. First off, even though you list a couple of big
It is kinda interesting that at the same time several projects appeared to catch the "safer" language desire. Both projects have automatic safe MM (GC and auto-free), both trying to fix C.. sounds familiar right? :) First one is only going to be released in 2025, the second is currently mostly a hobby project of one guy, but in both projects some people are from large corps (Disney, Epic Games). And they could just try D instead ¯\_(ツ)_/¯ TrapC: https://vimeo.com/1028578347 https://www.theregister.com/2024/11/12/trapc_memory_safe_fork/ Fil-C: https://www.youtube.com/live/_VF3pISRYRc?t=4862s https://github.com/pizlonator/llvm-project-deluge
Nov 17
"I was actually interim chairman of the Rust committee at the Motion Picture Academy last summer," he said. "And it's an interesting language and I enjoyed playing with it, but I was like, I just can't imagine having to rewrite all my software in this."Quote of the day, lol.
Nov 21
On Thursday, 21 November 2024 at 18:43:51 UTC, Kagamin wrote:I think that there is a quite common sentiment these days that (a) rust solves a few painful problems nicely, but (b) is too impractical to use at scale. My prediction right now is that rust won't overtake any of the major languages. Here's why: - There is a genuine drive to build a successor that interacts much more nicely with existing code in C and C++. Especially C++ seems to be in this weird spot where it is at the same time a major improvement over C to be worth using, but also starting to overstay its welcome in many teams. - Nobody is going to rewrite the world just to get more control over memory bugs. Old code that works is perfectly fine and mostly not a liability in that regard (caveats apply). - People want good interop with their existing code when introducing a new language. This isn't a big issue with C, but any more advanced C++ library, for example, is hard to bind to other compiled languages. Some features can't be bound at all unless the target language makes special provisions to enable it (see C++ interop in D and Swift, also C++/CLI). Rust will probably have its lunch eaten the moment a language comes along that - is as fast as rust or C++, - has memory guarantees on par with rust (not necessarily a carbon copy of the rust borrow checker), - and can interop with more modern languages than C with less friction than rust can. I assume that there are enough dev leads out there that would literally throw money at such a solution with both hands, so it's bound to happen eventually. [Also, stupid pet peeve: "memory safety" is the wrong name for what rust accomplishes in my head. I associate "safety" with functional safety, which rust doesn't solve at all.]"I was actually interim chairman of the Rust committee at the Motion Picture Academy last summer," he said. "And it's an interesting language and I enjoyed playing with it, but I was like, I just can't imagine having to rewrite all my software in this."Quote of the day, lol.
Nov 22
On Saturday, 23 November 2024 at 01:11:46 UTC, Gregor Mückl wrote:On Thursday, 21 November 2024 at 18:43:51 UTC, Kagamin wrote:That language will arrive too late for what is already happening at Google, Microsoft, Apple, Amazon, Cloudflare, Vercel, Facebook, Activision, Capcom,....I think that there is a quite common sentiment these days that (a) rust solves a few painful problems nicely, but (b) is too impractical to use at scale. My prediction right now is that rust won't overtake any of the major languages. Here's why: - There is a genuine drive to build a successor that interacts much more nicely with existing code in C and C++. Especially C++ seems to be in this weird spot where it is at the same time a major improvement over C to be worth using, but also starting to overstay its welcome in many teams. - Nobody is going to rewrite the world just to get more control over memory bugs. Old code that works is perfectly fine and mostly not a liability in that regard (caveats apply). - People want good interop with their existing code when introducing a new language. This isn't a big issue with C, but any more advanced C++ library, for example, is hard to bind to other compiled languages. Some features can't be bound at all unless the target language makes special provisions to enable it (see C++ interop in D and Swift, also C++/CLI). Rust will probably have its lunch eaten the moment a language comes along that - is as fast as rust or C++, - has memory guarantees on par with rust (not necessarily a carbon copy of the rust borrow checker), - and can interop with more modern languages than C with less friction than rust can. I assume that there are enough dev leads out there that would literally throw money at such a solution with both hands, so it's bound to happen eventually. [Also, stupid pet peeve: "memory safety" is the wrong name for what rust accomplishes in my head. I associate "safety" with functional safety, which rust doesn't solve at all.]"I was actually interim chairman of the Rust committee at the Motion Picture Academy last summer," he said. "And it's an interesting language and I enjoyed playing with it, but I was like, I just can't imagine having to rewrite all my software in this."Quote of the day, lol.
Nov 23
Gregor =?UTF-8?B?TcO8Y2ts?= <gregormueckl gmx.de> On Saturday, 23 November 2024 at 18:44:55 UTC, Paulo Pinto wrote:On Saturday, 23 November 2024 at 01:11:46 UTC, Gregor Mückl wrote:I doubt that. First off, even though you list a couple of big names, they cover only a tiny fraction of the software development that is happening in the world. Also, the decisions they make are highly bespoke to their internal needs - ludicrously big teams and their highly monolithic and sprawling codebases. My experience is that their tooling and decision making is so warped by this that it is foolish to apply (almost) any of that to a project with less than ~100 developers. This still leaves a world full of "brownfield" projects that can't easily accommodate a second language as different as rust for all kinds of reasons. They would gladly take anything that gives them the same level of results with less friction than rust would. There is heap of real money lying on the table here. Developers don't care much about how these better guarantees are achieved in detail under the hood (e.g. borrow checking). They just want guardrails on what they are doing that catch more mistakes that would be costly, but also with the least intrusiveness on what they do. Rust is on the very extreme end of a spectrum, mostly because of design decisions that do not concern memory management. The proponents are good at selling it. But there are certainly other sweet spots between C and rust that aren't as radical. People are searching for it (see thread starter for examples - there are more) and at least one of these attempts will be successful. If you want to find true successor languages to C or C++, it will appear in that space.On Thursday, 21 November 2024 at 18:43:51 UTC, Kagamin wrote:That language will arrive too late for what is already happening at Google, Microsoft, Apple, Amazon, Cloudflare, Vercel, Facebook, Activision, Capcom,....I think that there is a quite common sentiment these days that (a) rust solves a few painful problems nicely, but (b) is too impractical to use at scale. My prediction right now is that rust won't overtake any of the major languages. Here's why: - There is a genuine drive to build a successor that interacts much more nicely with existing code in C and C++. Especially C++ seems to be in this weird spot where it is at the same time a major improvement over C to be worth using, but also starting to overstay its welcome in many teams. - Nobody is going to rewrite the world just to get more control over memory bugs. Old code that works is perfectly fine and mostly not a liability in that regard (caveats apply). - People want good interop with their existing code when introducing a new language. This isn't a big issue with C, but any more advanced C++ library, for example, is hard to bind to other compiled languages. Some features can't be bound at all unless the target language makes special provisions to enable it (see C++ interop in D and Swift, also C++/CLI). Rust will probably have its lunch eaten the moment a language comes along that - is as fast as rust or C++, - has memory guarantees on par with rust (not necessarily a carbon copy of the rust borrow checker), - and can interop with more modern languages than C with less friction than rust can. I assume that there are enough dev leads out there that would literally throw money at such a solution with both hands, so it's bound to happen eventually. [Also, stupid pet peeve: "memory safety" is the wrong name for what rust accomplishes in my head. I associate "safety" with functional safety, which rust doesn't solve at all.]"I was actually interim chairman of the Rust committee at the Motion Picture Academy last summer," he said. "And it's an interesting language and I enjoyed playing with it, but I was like, I just can't imagine having to rewrite all my software in this."Quote of the day, lol.
Nov 26