- "Will Carbon Replace C++?" by Manuel Rubio - 17 Updates
- Is this safe? - 8 Updates
| Sam <sam@email-scan.com>: Feb 28 08:36PM -0500 Lynn McGuire writes: > "Will Carbon Replace C++?" by Manuel Rubio > https://semaphoreci.com/blog/carbon Carbon will replace C++ as soon as C++ gets replaced by Java, dot-Nyet, Python, and Rust. Then it will be Carbon's turn. |
| Muttley@dastardlyhq.com: Mar 01 09:44AM On Tue, 28 Feb 2023 15:35:48 -0600 >experiment. The keynote was titled: Carbon Language: An experimental >successor to C++. But why do we need a successor and where did this idea >come from?" I'm fairly sure thats what Go was supposed to be. Presumably it'll soon be Gone. |
| "Öö Tiib" <ootiib@hot.ee>: Mar 01 02:51AM -0800 On Tuesday, 28 February 2023 at 23:36:05 UTC+2, Lynn McGuire wrote: > successor to C++. But why do we need a successor and where did this idea > come from?" > Here we go again. Answer to the question is "Certainly No". There are better candidates (like D, Rust and Swift). Meanwhile C++ is no way dying despite being dangerously obese ... its popularity is high. If a language tries to be as performant and to interoperate with C++ (so to gradually replace it) then it has first either to make compiler frontend for some toolchain that compiles C++ or at least transpiler to C++ (or some other language in such a toolchain). Without that the talks can't be taken seriously. As of syntax sugar ... the proposed improvements / changes compared to C++ look about same or even less impressive than others. So Carbon looks like a list of unfulfilled wishes and buzzwords. Now if Google pushes it ... then it can perhaps reach questionable state of Golang and Dart. If it does not then it will remain a vapourware. |
| "Alf P. Steinbach" <alf.p.steinbach@gmail.com>: Mar 01 12:02PM +0100 On 2023-02-28 10:35 PM, Lynn McGuire wrote: > successor to C++. But why do we need a successor and where did this idea > come from?" > Here we go again. With the NSA recommendation to not use C or C++ the succession might happen swifter than one would think. Or not. Things are happening. NSA, November 2022: ¹❝NSA advises organizations to consider making a strategic shift from programming languages that provide little or no inherent memory protection, such as C/C++, to a memory safe language when possible. Some examples of memory safe languages are C#, Go, Java, Ruby™, and Swift®❞ The New Stack, February 2023 (linking to Bjarne's NSA response): ²❝In mid-January, the official C++ "direction group" — which makes recommendations for the programming language's evolution — issued a statement addressing concerns about C++ safety. While many languages now support "basic type safety" — that is, ensuring that variables access only sections of memory that are clearly defined by their data types — C++ has struggled to offer similar guarantees. This new statement, co-authored by C++ creator Bjarne Stroustrup, now appears to call for changing the C++ programming language itself to address safety concerns. "We now support the idea that the changes for safety need to be not just in tooling, but visible in the language/compiler, and library." The group still also supports its long-preferred use of debugging tools to ensure safety (and "pushing tooling to enable more global analysis in identifying hard for humans to identify safety concerns"). But that January statement emphasizes its recommendation for changes within C++. Specifically, it proposes "packaging several features into profiles" (with profiles defined later as "a collection of restrictions and requirements that defines a property to be enforced" by, for example, triggering an automatic analysis.) In this way the new changes for safety "should be visible such that the Safe code section can be named (possibly using profiles), and can mix with normal code."❞ ¹ https://media.defense.gov/2022/Nov/10/2003112742/-1/-1/0/CSI_SOFTWARE_MEMORY_SAFETY.PDF ² https://thenewstack.io/can-c-be-saved-bjarne-stroustrup-on-ensuring-memory-safety/ - Alf |
| "Alf P. Steinbach" <alf.p.steinbach@gmail.com>: Mar 01 12:12PM +0100 On 2023-03-01 12:02 PM, Alf P. Steinbach wrote: > programming languages that provide little or no inherent memory > protection, such as C/C++, to a memory safe language when possible. Some > examples of memory safe languages are C#, Go, Java, Ruby™, and Swift®❞ [snip] > ¹ > https://media.defense.gov/2022/Nov/10/2003112742/-1/-1/0/CSI_SOFTWARE_MEMORY_SAFETY.PDF Sorry, the NSA apparently didn't use those words. The quote is from Bjarne's response, where it appeared to be a quote of the NSA article. Either the NSA has changed the article, or else Bjarne needs to train on how to present summaries and paraphrases so that they do not look exactly like literal quotes. But as a summary it's correct. Bjarne's NSA response: https://www.open-std.org/jtc1/sc22/wg21/docs/papers/2023/p2739r0.pdf - Alf |
| Muttley@dastardlyhq.com: Mar 01 11:13AM On Wed, 1 Mar 2023 02:51:19 -0800 (PST) >buzzwords. Now if Google pushes it ... then it can perhaps reach >questionable state of Golang and Dart. If it does not then it will >remain a vapourware. It doesn't help that Carbon is also an Apple C API so Google clearly didn't bother to check if the name was already used in the IT world. |
| Muttley@dastardlyhq.com: Mar 01 11:17AM On Wed, 1 Mar 2023 12:02:16 +0100 >programming languages that provide little or no inherent memory >protection, such as C/C++, to a memory safe language when possible. Some >examples of memory safe languages are C#, Go, Java, Ruby™, and Swift®❞ Apples and oranges. The use case of C and up to a point C++ is rather different to those languages. You'd think the NSA might know this. >identifying hard for humans to identify safety concerns"). But that >January statement emphasizes its recommendation for changes within C++. Just leave C++ alone FFS. |
| Bonita Montero <Bonita.Montero@gmail.com>: Mar 01 01:46PM +0100 > I'm fairly sure thats what Go was supposed to be. Presumably it'll soon be Gone. Go wasn't designed as a C++-replacement but as a cloud-computing language for the backend. Go has a performance similar to Java and Java is on average half as fast as C++ in the computer languages benchmark game. |
| Bo Persson <bo@bo-persson.se>: Mar 01 03:30PM +0100 >> remain a vapourware. > It doesn't help that Carbon is also an Apple C API so Google clearly didn't > bother to check if the name was already used in the IT world. Not only that, it is really hard to Google for Carbon and find something related. :-) https://carbondesignsystem.com/ https://carbon.website/ https://carbon.nesbot.com/docs/ https://www.carbonads.net/ https://www.carbonbrief.org/ https://www.carbontrust.com/ https://www.carbonfootprint.com/ https://carbontracker.org/ https://carbon-pulse.com/ https://www.globalcarbonproject.org/ https://www.carbonclean.com/ https://carbonengineering.com/ https://www.getcarbon.co/ https://carbonmarketwatch.org/ https://www.carbonrecycling.is/ https://www.carbonneutral.com/ https://www.carbon-direct.com/ https://joincarbon.com/ https://carbonfund.org/ https://carbon.coop/ https://www.carbon.tv/ |
| cross@spitfire.i.gajendra.net (Dan Cross): Mar 01 02:59PM In article <ttnbbo$3u603$1@dont-email.me>, >> Here we go again. >With the NSA recommendation to not use C or C++ the succession might >happen swifter than one would think. Or not. Things are happening. Too bad Carbon isn't memory safe. :-/ - Dan C. |
| "Öö Tiib" <ootiib@hot.ee>: Mar 01 07:12AM -0800 On Wednesday, 1 March 2023 at 13:02:33 UTC+2, Alf P. Steinbach wrote: > > Here we go again. > With the NSA recommendation to not use C or C++ the succession might > happen swifter than one would think. Or not. Things are happening. Nice. NSA is evil organisation so its advise should be ignored but good news are that Bjarne seems to realise that specifying language to be "UB" multiple times per every page and then writing "core guidelines" how to navigate in that forest of bear traps is not enough. That is unlikely to make C++ worse or to help vapourware like Carbon. |
| Vir Campestris <vir.campestris@invalid.invalid>: Mar 01 04:50PM On 28/02/2023 21:35, Lynn McGuire wrote: > come from?" > Here we go again. > Lynn Nothing is going to replace C++ - at least not completely. Fortran and Cobol haven't gone away, and we all know C is pretty healthy. I've written assembler for odd bits quite recently - and that's pretty old. Heck, it's not that long since I've been forced to write actual machine code... It's possible that C++ will get less popular. It isn't going away. Andy |
| Daniel <danielaparker@gmail.com>: Mar 01 09:28AM -0800 On Wednesday, March 1, 2023 at 9:30:36 AM UTC-5, Bo Persson wrote: > Not only that, it is really hard to Google for Carbon and find something > related. :-) Try googling for carbon c++ :-) Daniel |
| legalize+jeeves@mail.xmission.com (Richard): Mar 01 05:47PM [Please do not mail me a copy of your followup] Lynn McGuire <lynnmcguire5@gmail.com> spake the secret code >"Will Carbon Replace C++?" by Manuel Rubio >[...] >Here we go again. Betteridge's law of headlines Betteridge's law of headlines is an adage that states: "Any headline that ends in a question mark can be answered by the word no." <https://en.wikipedia.org/wiki/Betteridge%27s_law_of_headlines> -- "The Direct3D Graphics Pipeline" free book <http://tinyurl.com/d3d-pipeline> The Terminals Wiki <http://terminals-wiki.org> The Computer Graphics Museum <http://computergraphicsmuseum.org> Legalize Adulthood! (my blog) <http://legalizeadulthood.wordpress.com> |
| Lynn McGuire <lynnmcguire5@gmail.com>: Mar 01 02:16PM -0600 On 3/1/2023 10:50 AM, Vir Campestris wrote: > actual machine code... > It's possible that C++ will get less popular. It isn't going away. > Andy I think that Fortran is in the process of converting from a development language to a hobbyist language. The recent shutdown of most of the Fortran Compiler companies after the freewareing of Intel Fortran was a sign of the times. Lynn |
| scott@slp53.sl.home (Scott Lurndal): Mar 01 09:30PM >> Andy >I think that Fortran is in the process of converting from a development >language to a hobbyist language. Now you're being absurd. > The recent shutdown of most of the >Fortran Compiler companies after the freewareing of Intel Fortran was a >sign of the times. I'd suggest that the existance of gcc and clang haven't relegated C and C++ to "hobbyist languages". They have relegated a whole bunch of commercial toolchains to niche or oblivion. |
| "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com>: Mar 01 02:27PM -0800 On 3/1/2023 3:02 AM, Alf P. Steinbach wrote: > With the NSA recommendation to not use C or C++ the succession might > happen swifter than one would think. Or not. Things are happening. > [...] Reminds me of people saying ADA is the only safe language. |
| Muttley@dastardlyhq.com: Mar 01 09:37AM On Tue, 28 Feb 2023 18:34:10 +0100 >/hardware/ can have bugs. But if a piece of code gives the specified >output and effects for the specified inputs, then it is correct and >bug-free. Really? Spec: function always returns 10 int func() { char *ptr = 0; for(int i=0;i < 100000;++i) ptr[i] = 0; return 10; } Bug free? >You lock your front door, because that forms a boundary between areas of >trust. You don't lock your in-house doors because you trust those >inside the house. The function is the house in this metaphor, the rest of the program is outside. >agree that complicated code (or complicated specifications) make things >much more difficult. That's why you divide things up into parts - both >code and specifications - and handle them individually. That's why you Perfectly working parts can still fail with bugs when put together as Ariane 5 and Mars Climate Orbiter discovered. Format testing requires a formal system test too, you can't ignore it if you want to do it properly. |
| Malcolm McLean <malcolm.arthur.mclean@gmail.com>: Mar 01 02:29AM -0800 > return 10; > } > Bug free? A better example would be int func() { char *ptr = malloc(1); return 10; } This function will always return 10, so it's to specification. But it's the source of a bug. |
| David Brown <david.brown@hesbynett.no>: Mar 01 02:27PM +0100 > return 10; > } > Bug free? You are accessing other data that is not part of the specification. That has to be considered part of the input - this function would have a precondition that 100,000 int's from address 0 onwards must be writeable. (It is a lot easier to write clear specifications for pure functions - no access of any non-constant global data, and no side-effect, so that the output depends solely on the input.) >> trust. You don't lock your in-house doors because you trust those >> inside the house. > The function is the house in this metaphor, the rest of the program is outside. Then no, you don't lock your front door because you put your controlled boundaries in a sensible place. Putting them at every function is /not/ smart. > Perfectly working parts can still fail with bugs when put together as Ariane 5 > and Mars Climate Orbiter discovered. Format testing requires a formal system > test too, you can't ignore it if you want to do it properly. Those were failures of the specifications at a higher level - the individual parts were fine, but the higher level systems specified the wrong subcomponents. |
| Keith Thompson <Keith.S.Thompson+u@gmail.com>: Mar 01 10:48AM -0800 > specification. That has to be considered part of the input - this > function would have a precondition that 100,000 int's from address 0 > onwards must be writeable. ptr contains a null pointer, which may or may not be "address 0" (depending on just what you mean by "address 0"). The code has undefined behavior. Conceivably it could depend on the behavior of the target system *and* of the compiler, but it's far more likely that it's just a bug. And as far as the C standard is concerned, there's no guarantee that the function will return 10. (It has additional UB if int is 16 bits.) -- Keith Thompson (The_Other_Keith) Keith.S.Thompson+u@gmail.com Working, but not speaking, for XCOM Labs void Void(void) { Void(); } /* The recursive call of the void */ |
| Ben Bacarisse <ben.usenet@bsb.me.uk>: Mar 01 07:53PM > return 10; > } > Bug free? No, the code does not meet it's specification. In fact, the code has no defined behaviour at all. -- Ben. |
| Ben Bacarisse <ben.usenet@bsb.me.uk>: Mar 01 07:56PM > } > This function will always return 10, so it's to specification. But > it's the source of a bug. This is a better example (because it has defined behaviour), but does the function meet the specification? I would say that, speaking informally, specifications are taken to be minimal. Would int func() { getchar(); return 10; } meet the specification as well? -- Ben. |
| Malcolm McLean <malcolm.arthur.mclean@gmail.com>: Mar 01 12:53PM -0800 On Wednesday, 1 March 2023 at 19:56:23 UTC, Ben Bacarisse wrote: > informally, specifications are taken to be minimal. Would > int func() { getchar(); return 10; } > meet the specification as well? This is where you get trapped by C's misuse of the term "function". If the term "function" were used in the proper mathematical sense, then the program's memory would be in one state on function entry and another on function return, and so you can't have a function without a specification. But C "functions" can perform actions. Specifying correct actions is a whole different ball game to specifying functions, which are just mappings from one set to another. |
| Ben Bacarisse <ben.usenet@bsb.me.uk>: Mar 01 09:13PM > then the program's memory would be in one state on function entry and > another on function return, and so you can't have a function without a > specification. No, that's not the issue. Of course it would help if functions were functions, but the terminology is not the issue here. A sin function (in some unimpeachable language like Haskell) that did all sorts of other computations and took an hour, or used half the available memory, would not meet the specification because, in my book, the specification should be taken to be minimal. > But C "functions" can perform actions. Specifying correct actions is a whole > different ball game to specifying functions, which are just mappings from > one set to another. So lets' call them all "procedures" for the moment and get back to the question at hand. Should a specification be taken to be essentially minimal? I would say so. -- Ben. |
| You received this digest because you're subscribed to updates for this group. You can change your settings on the group membership page. To unsubscribe from this group and stop receiving emails from it send an email to comp.lang.c+++unsubscribe@googlegroups.com. |
No comments:
Post a Comment