Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]
Groups > comp.lang.c++ > #86469 > unrolled thread
| Started by | Lynn McGuire <lynnmcguire5@gmail.com> |
|---|---|
| First post | 2022-09-21 14:04 -0500 |
| Last post | 2022-09-26 02:08 -0400 |
| Articles | 20 on this page of 109 — 28 participants |
Back to article view | Back to comp.lang.c++
“Microsoft Azure CTO Mark Russinovich: C/C++ should be deprecated” Lynn McGuire <lynnmcguire5@gmail.com> - 2022-09-21 14:04 -0500
Re: “Microsoft Azure CTO Mark Russinovich: C/C++ should be deprecated” "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> - 2022-09-21 12:28 -0700
Re: ???Microsoft Azure CTO Mark Russinovich: C/C++ should be deprecated??? Juha Nieminen <nospam@thanks.invalid> - 2022-09-22 06:16 +0000
Re: ???Microsoft Azure CTO Mark Russinovich: C/C++ should be deprecated??? David Brown <david.brown@hesbynett.no> - 2022-09-22 09:45 +0200
Re: ???Microsoft Azure CTO Mark Russinovich: C/C++ should be deprecated??? Blue-Maned_Hawk <bluemanedhawk@gmail.com> - 2022-09-26 02:07 -0400
Re: ???Microsoft Azure CTO Mark Russinovich: C/C++ should be deprecated??? David Brown <david.brown@hesbynett.no> - 2022-09-26 08:42 +0200
Re: ???Microsoft Azure CTO Mark Russinovich: C/C++ should be Muttley@dastardlyhq.com - 2022-09-26 15:24 +0000
Re: ???Microsoft Azure CTO Mark Russinovich: C/C++ should be "daniel...@gmail.com" <danielaparker@gmail.com> - 2022-09-26 09:00 -0700
Re: ???Microsoft Azure CTO Mark Russinovich: C/C++ should be Muttley@dastardlyhq.com - 2022-09-26 16:11 +0000
Re: ???Microsoft Azure CTO Mark Russinovich: C/C++ should be "daniel...@gmail.com" <danielaparker@gmail.com> - 2022-09-26 09:22 -0700
Re: ???Microsoft Azure CTO Mark Russinovich: C/C++ should be deprecated??? Juha Nieminen <nospam@thanks.invalid> - 2022-09-22 09:41 +0000
Re: ???Microsoft Azure CTO Mark Russinovich: C/C++ should be deprecated??? Ben Bacarisse <ben.usenet@bsb.me.uk> - 2022-09-22 16:46 +0100
Re: ???Microsoft Azure CTO Mark Russinovich: C/C++ should be deprecated??? gazelle@shell.xmission.com (Kenny McCormack) - 2022-09-22 16:15 +0000
Re: ???Microsoft Azure CTO Mark Russinovich: C/C++ should be deprecated??? David Brown <david.brown@hesbynett.no> - 2022-09-22 20:43 +0200
Re: ???Microsoft Azure CTO Mark Russinovich: C/C++ should be deprecated??? Ben Bacarisse <ben.usenet@bsb.me.uk> - 2022-09-22 20:15 +0100
Re: ???Microsoft Azure CTO Mark Russinovich: C/C++ should be deprecated??? David Brown <david.brown@hesbynett.no> - 2022-09-22 22:56 +0200
Re: ???Microsoft Azure CTO Mark Russinovich: C/C++ should be deprecated??? Bart <bc@freeuk.com> - 2022-09-22 23:15 +0100
g++ with -O6 slower than with -O2 [was Re: "Microsoft Azure CTO Mark Russinovich: C/C++ should be deprecated"] Ralf Goertz <me@myprovider.invalid> - 2022-09-23 13:44 +0200
Re: g++ with -O6 slower than with -O2 [was Re: "Microsoft Azure CTO Mark Russinovich: C/C++ should be deprecated"] Bart <bc@freeuk.com> - 2022-09-23 13:53 +0100
Re: g++ with -O6 slower than with -O2 [was Re: "Microsoft Azure CTO Mark Russinovich: C/C++ should be deprecated"] David Brown <david.brown@hesbynett.no> - 2022-09-23 15:31 +0200
Re: g++ with -O6 slower than with -O2 [was Re: "Microsoft Azure CTO Mark Russinovich: C/C++ should be deprecated"] David Brown <david.brown@hesbynett.no> - 2022-09-23 15:53 +0200
Re: g++ with -O6 slower than with -O2 [was Re: "Microsoft Azure CTO Mark Russinovich: C/C++ should be deprecated"] Ralf Goertz <me@myprovider.invalid> - 2022-09-23 16:21 +0200
Re: g++ with -O6 slower than with -O2 [was Re: "Microsoft Azure CTO Mark Russinovich: C/C++ should be deprecated"] David Brown <david.brown@hesbynett.no> - 2022-09-24 17:05 +0200
Re: g++ with -O6 slower than with -O2 [was Re: "Microsoft Azure CTO Mark Russinovich: C/C++ should be deprecated"] red floyd <no.spam.here@its.invalid> - 2022-09-24 12:33 -0700
Re: g++ with -O6 slower than with -O2 [was Re: "Microsoft Azure CTO Muttley@dastardlyhq.com - 2022-09-25 08:45 +0000
Re: ???Microsoft Azure CTO Mark Russinovich: C/C++ should be deprecated??? Ben Bacarisse <ben.usenet@bsb.me.uk> - 2022-09-23 00:08 +0100
Re: ???Microsoft Azure CTO Mark Russinovich: C/C++ should be deprecated??? Juha Nieminen <nospam@thanks.invalid> - 2022-09-23 07:45 +0000
Re: ???Microsoft Azure CTO Mark Russinovich: C/C++ should be deprecated??? Paavo Helde <eesnimi@osa.pri.ee> - 2022-09-23 12:13 +0300
Re: ???Microsoft Azure CTO Mark Russinovich: C/C++ should be deprecated??? Juha Nieminen <nospam@thanks.invalid> - 2022-09-23 10:01 +0000
Re: ???Microsoft Azure CTO Mark Russinovich: C/C++ should be deprecated??? Michael S <already5chosen@yahoo.com> - 2022-09-23 03:14 -0700
Re: ???Microsoft Azure CTO Mark Russinovich: C/C++ should be deprecated??? Juha Nieminen <nospam@thanks.invalid> - 2022-09-26 08:01 +0000
Re: ???Microsoft Azure CTO Mark Russinovich: C/C++ should be deprecated??? Tim Rentsch <tr.17687@z991.linuxsc.com> - 2022-10-02 12:57 -0700
Re: ???Microsoft Azure CTO Mark Russinovich: C/C++ should be deprecated??? Michael S <already5chosen@yahoo.com> - 2022-10-02 13:53 -0700
Re: ???Microsoft Azure CTO Mark Russinovich: C/C++ should be deprecated??? Tim Rentsch <tr.17687@z991.linuxsc.com> - 2022-10-07 16:00 -0700
Re: ???Microsoft Azure CTO Mark Russinovich: C/C++ should be deprecated??? Michael S <already5chosen@yahoo.com> - 2022-10-08 10:57 -0700
Re: ???Microsoft Azure CTO Mark Russinovich: C/C++ should be deprecated??? Tim Rentsch <tr.17687@z991.linuxsc.com> - 2022-10-09 08:33 -0700
Re: ???Microsoft Azure CTO Mark Russinovich: C/C++ should be deprecated??? Ben Bacarisse <ben.usenet@bsb.me.uk> - 2022-09-23 11:58 +0100
Re: ???Microsoft Azure CTO Mark Russinovich: C/C++ should be deprecated??? Juha Nieminen <nospam@thanks.invalid> - 2022-09-26 08:01 +0000
Re: ???Microsoft Azure CTO Mark Russinovich: C/C++ should be deprecated??? Blue-Maned_Hawk <bluemanedhawk@gmail.com> - 2022-09-26 02:03 -0400
Re: ???Microsoft Azure CTO Mark Russinovich: C/C++ should be deprecated??? David Brown <david.brown@hesbynett.no> - 2022-09-23 13:32 +0200
Re: ???Microsoft Azure CTO Mark Russinovich: C/C++ should be deprecated??? red floyd <no.spam.here@its.invalid> - 2022-09-23 14:43 -0700
Re: ???Microsoft Azure CTO Mark Russinovich: C/C++ should be deprecated??? Juha Nieminen <nospam@thanks.invalid> - 2022-09-23 07:26 +0000
Re: ???Microsoft Azure CTO Mark Russinovich: C/C++ should be deprecated??? Ben Bacarisse <ben.usenet@bsb.me.uk> - 2022-09-23 11:15 +0100
Re: ???Microsoft Azure CTO Mark Russinovich: C/C++ should be deprecated??? Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2022-09-23 12:35 -0700
Re: ???Microsoft Azure CTO Mark Russinovich: C/C++ should be deprecated??? "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> - 2022-09-23 12:44 -0700
Re: ???Microsoft Azure CTO Mark Russinovich: C/C++ should be deprecated??? Juha Nieminen <nospam@thanks.invalid> - 2022-09-26 08:09 +0000
Re: ???Microsoft Azure CTO Mark Russinovich: C/C++ should be deprecated??? Bonita Montero <Bonita.Montero@gmail.com> - 2022-09-24 13:25 +0200
Re: ???Microsoft Azure CTO Mark Russinovich: C/C++ should be deprecated??? Juha Nieminen <nospam@thanks.invalid> - 2022-09-26 08:13 +0000
Re: ???Microsoft Azure CTO Mark Russinovich: C/C++ should be deprecated??? Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2022-09-26 10:44 -0700
Re: ???Microsoft Azure CTO Mark Russinovich: C/C++ should be deprecated??? Juha Nieminen <nospam@thanks.invalid> - 2022-09-27 06:26 +0000
Re: ???Microsoft Azure CTO Mark Russinovich: C/C++ should be deprecated??? Joe Pfeiffer <pfeiffer@cs.nmsu.edu> - 2022-09-27 09:56 -0600
Re: ???Microsoft Azure CTO Mark Russinovich: C/C++ should be deprecated??? Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2022-09-27 10:50 -0700
Re: ???Microsoft Azure CTO Mark Russinovich: C/C++ should be deprecated??? Blue-Maned_Hawk <bluemanedhawk@gmail.com> - 2022-09-26 01:57 -0400
Re: “Microsoft Azure CTO Mark Russinovich: C/C++ should be deprecated” Jens Stuckelberger <Jens_Stuckelberger@nowhere.net> - 2022-09-22 14:01 +0000
Re: “Microsoft Azure CTO Mark Russinovich: C/C++ should be deprecated” Kaz Kylheku <864-117-4973@kylheku.com> - 2022-09-23 03:17 +0000
Re: ???Microsoft Azure CTO Mark Russinovich: C/C++ should be deprecated??? Juha Nieminen <nospam@thanks.invalid> - 2022-09-23 07:50 +0000
Re: ???Microsoft Azure CTO Mark Russinovich: C/C++ should be deprecated??? David Brown <david.brown@hesbynett.no> - 2022-09-23 13:37 +0200
Re: ???Microsoft Azure CTO Mark Russinovich: C/C++ should be deprecated??? Juha Nieminen <nospam@thanks.invalid> - 2022-09-26 08:19 +0000
Re: ???Microsoft Azure CTO Mark Russinovich: C/C++ should be deprecated??? David Brown <david.brown@hesbynett.no> - 2022-09-26 13:55 +0200
Re: ???Microsoft Azure CTO Mark Russinovich: C/C++ should be deprecated??? Juha Nieminen <nospam@thanks.invalid> - 2022-09-26 14:31 +0000
Re: ???Microsoft Azure CTO Mark Russinovich: C/C++ should be deprecated??? Bart <bc@freeuk.com> - 2022-09-26 16:05 +0100
Re: ???Microsoft Azure CTO Mark Russinovich: C/C++ should be deprecated??? Juha Nieminen <nospam@thanks.invalid> - 2022-09-27 06:36 +0000
Re: ???Microsoft Azure CTO Mark Russinovich: C/C++ should be deprecated??? David Brown <david.brown@hesbynett.no> - 2022-09-27 11:21 +0200
Re: ???Microsoft Azure CTO Mark Russinovich: C/C++ should be deprecated??? Juha Nieminen <nospam@thanks.invalid> - 2022-09-27 13:26 +0000
Re: ???Microsoft Azure CTO Mark Russinovich: C/C++ should be deprecated??? Bo Persson <bo@bo-persson.se> - 2022-09-27 16:53 +0200
Re: ???Microsoft Azure CTO Mark Russinovich: C/C++ should be deprecated??? David Brown <david.brown@hesbynett.no> - 2022-09-28 10:32 +0200
Re: ???Microsoft Azure CTO Mark Russinovich: C/C++ should be deprecated??? Kaz Kylheku <864-117-4973@kylheku.com> - 2022-09-27 18:18 +0000
Re: ???Microsoft Azure CTO Mark Russinovich: C/C++ should be deprecated??? James Kuyper <jameskuyper@alumni.caltech.edu> - 2022-09-28 01:30 -0400
Re: ???Microsoft Azure CTO Mark Russinovich: C/C++ should be deprecated??? Kaz Kylheku <864-117-4973@kylheku.com> - 2022-09-28 08:26 +0000
Re: ???Microsoft Azure CTO Mark Russinovich: C/C++ should be deprecated??? Bo Persson <bo@bo-persson.se> - 2022-09-28 10:43 +0200
Re: ???Microsoft Azure CTO Mark Russinovich: C/C++ should be deprecated??? James Kuyper <jameskuyper@alumni.caltech.edu> - 2022-09-28 13:15 -0400
Re: ???Microsoft Azure CTO Mark Russinovich: C/C++ should be deprecated??? Kaz Kylheku <864-117-4973@kylheku.com> - 2022-09-28 23:38 +0000
Re: ???Microsoft Azure CTO Mark Russinovich: C/C++ should be deprecated??? David Brown <david.brown@hesbynett.no> - 2022-09-29 11:46 +0200
Re: ???Microsoft Azure CTO Mark Russinovich: C/C++ should be deprecated??? Kaz Kylheku <864-117-4973@kylheku.com> - 2022-09-29 17:58 +0000
Re: ???Microsoft Azure CTO Mark Russinovich: C/C++ should be deprecated??? David Brown <david.brown@hesbynett.no> - 2022-09-30 09:17 +0200
Re: ???Microsoft Azure CTO Mark Russinovich: C/C++ should be deprecated??? Kaz Kylheku <864-117-4973@kylheku.com> - 2022-09-30 16:39 +0000
Re: ???Microsoft Azure CTO Mark Russinovich: C/C++ should be deprecated??? David Brown <david.brown@hesbynett.no> - 2022-10-01 12:47 +0200
Re: ???Microsoft Azure CTO Mark Russinovich: C/C++ should be deprecated??? Kaz Kylheku <864-117-4973@kylheku.com> - 2022-09-30 17:20 +0000
Re: ???Microsoft Azure CTO Mark Russinovich: C/C++ should be deprecated??? Paavo Helde <eesnimi@osa.pri.ee> - 2022-09-30 20:59 +0300
Re: ???Microsoft Azure CTO Mark Russinovich: C/C++ should be deprecated??? Tim Rentsch <tr.17687@z991.linuxsc.com> - 2022-10-02 07:31 -0700
Re: ???Microsoft Azure CTO Mark Russinovich: C/C++ should be deprecated??? David Brown <david.brown@hesbynett.no> - 2022-10-02 13:38 +0200
Re: ???Microsoft Azure CTO Mark Russinovich: C/C++ should be deprecated??? Ben Bacarisse <ben.usenet@bsb.me.uk> - 2022-10-02 13:00 +0100
Re: ???Microsoft Azure CTO Mark Russinovich: C/C++ should be deprecated??? David Brown <david.brown@hesbynett.no> - 2022-10-02 16:20 +0200
Re: ???Microsoft Azure CTO Mark Russinovich: C/C++ should be deprecated??? Manfred <noname@add.invalid> - 2022-10-02 22:05 +0200
Re: ???Microsoft Azure CTO Mark Russinovich: C/C++ should be deprecated??? David Brown <david.brown@hesbynett.no> - 2022-10-03 11:58 +0200
Re: ???Microsoft Azure CTO Mark Russinovich: C/C++ should be deprecated??? Tim Rentsch <tr.17687@z991.linuxsc.com> - 2022-10-02 07:24 -0700
Re: ???Microsoft Azure CTO Mark Russinovich: C/C++ should be deprecated??? David Brown <david.brown@hesbynett.no> - 2022-09-28 09:40 +0200
Re: ???Microsoft Azure CTO Mark Russinovich: C/C++ should be deprecated??? Richard Damon <Richard@Damon-Family.org> - 2022-09-28 07:56 -0400
Re: ???Microsoft Azure CTO Mark Russinovich: C/C++ should be deprecated??? David Brown <david.brown@hesbynett.no> - 2022-09-28 15:50 +0200
Re: ???Microsoft Azure CTO Mark Russinovich: C/C++ should be deprecated??? scott@slp53.sl.home (Scott Lurndal) - 2022-09-28 14:21 +0000
Re: ???Microsoft Azure CTO Mark Russinovich: C/C++ should be deprecated??? scott@slp53.sl.home (Scott Lurndal) - 2022-09-28 16:17 +0000
Re: ???Microsoft Azure CTO Mark Russinovich: C/C++ should be deprecated??? Kaz Kylheku <864-117-4973@kylheku.com> - 2022-09-28 16:56 +0000
Re: ???Microsoft Azure CTO Mark Russinovich: C/C++ should be deprecated??? Bo Persson <bo@bo-persson.se> - 2022-09-28 20:31 +0200
Re: ???Microsoft Azure CTO Mark Russinovich: C/C++ should be deprecated??? doctor@doctor.nl2k.ab.ca (The Doctor) - 2022-09-28 21:45 +0000
Re: ???Microsoft Azure CTO Mark Russinovich: C/C++ should be deprecated??? David Brown <david.brown@hesbynett.no> - 2022-09-29 11:50 +0200
Re: ???Microsoft Azure CTO Mark Russinovich: C/C++ should be deprecated??? Richard Damon <Richard@Damon-Family.org> - 2022-09-28 19:33 -0400
Re: ???Microsoft Azure CTO Mark Russinovich: C/C++ should be deprecated??? rbowman <bowman@montana.com> - 2022-09-26 09:04 -0600
Re: ???Microsoft Azure CTO Mark Russinovich: C/C++ should be deprecated??? David Brown <david.brown@hesbynett.no> - 2022-09-27 11:27 +0200
Re: ???Microsoft Azure CTO Mark Russinovich: C/C++ should be deprecated??? rbowman <bowman@montana.com> - 2022-09-27 08:11 -0600
Re: ???Microsoft Azure CTO Mark Russinovich: C/C++ should be deprecated??? David Brown <david.brown@hesbynett.no> - 2022-09-27 18:10 +0200
Re: ???Microsoft Azure CTO Mark Russinovich: C/C++ should be deprecated??? rbowman <bowman@montana.com> - 2022-09-27 17:30 -0600
Re: ???Microsoft Azure CTO Mark Russinovich: C/C++ should be deprecated??? Kaz Kylheku <864-117-4973@kylheku.com> - 2022-09-28 00:26 +0000
Re: ???Microsoft Azure CTO Mark Russinovich: C/C++ should be deprecated??? David Brown <david.brown@hesbynett.no> - 2022-09-28 11:00 +0200
Re: ???Microsoft Azure CTO Mark Russinovich: C/C++ should be deprecated??? Ben Bacarisse <ben.usenet@bsb.me.uk> - 2022-09-28 13:33 +0100
Re: ???Microsoft Azure CTO Mark Russinovich: C/C++ should be deprecated??? Manfred <noname@add.invalid> - 2022-09-25 19:31 +0200
Re: ???Microsoft Azure CTO Mark Russinovich: C/C++ should be deprecated??? Kaz Kylheku <864-117-4973@kylheku.com> - 2022-09-26 04:53 +0000
Re: ???Microsoft Azure CTO Mark Russinovich: C/C++ should be deprecated??? Tim Rentsch <tr.17687@z991.linuxsc.com> - 2022-10-02 12:59 -0700
Re: “Microsoft Azure CTO Mark Russinovich: C/C++ should be deprecated” Opus <ifonly@youknew.org> - 2022-09-23 18:32 +0200
Re: “Microsoft Azure CTO Mark Russinovich: C/C++ should be deprecated” Blue-Maned_Hawk <bluemanedhawk@gmail.com> - 2022-09-26 02:08 -0400
Page 3 of 6 — ← Prev page 1 2 [3] 4 5 6 Next page →
| From | red floyd <no.spam.here@its.invalid> |
|---|---|
| Date | 2022-09-23 14:43 -0700 |
| Subject | Re: ???Microsoft Azure CTO Mark Russinovich: C/C++ should be deprecated??? |
| Message-ID | <tgl99c$2mfba$1@redfloyd.dont-email.me> |
| In reply to | #86518 |
On 9/23/2022 12:45 AM, Juha Nieminen wrote: > > In general, the more condensed or the more sparse the code, the less > readable it is. The perfect middle should be the goal. Or, as Einstein once put it, "Things should be as simple as possible, but no simpler".
[toc] | [prev] | [next] | [standalone]
| From | Juha Nieminen <nospam@thanks.invalid> |
|---|---|
| Date | 2022-09-23 07:26 +0000 |
| Subject | Re: ???Microsoft Azure CTO Mark Russinovich: C/C++ should be deprecated??? |
| Message-ID | <tgjn3l$14e6$1@gioia.aioe.org> |
| In reply to | #86502 |
In comp.lang.c++ David Brown <david.brown@hesbynett.no> wrote: > Rust is supposed to be /better/ than C. It is supposed to look at how C > has evolved over the decades, and pick a better starting point. So > saying C is as bad, or worse, is not an excuse for poor design choices > in Rust. That's exactly what I meant. C is something like 45 years old, Rust is something like 10 years old, and supposed to be a more modern and better designed language taking advantage of 50+ years of experience on how a good programming language should be like. Answering the criticism "this 10yo language has this design problem" with "oh yeah? Well, this 45yo language also has the same problem!" makes no sense. Newer "better" language are not supposed to copy the mistakes of the past. It's supposed to fix/improve on them. I'm not saying that eg. C++ is significantly better. The "brevity-over-clarity" mentality can oftentimes be seen throughout the standard library. For example, there's literally no reason why it should be called 'shared_ptr' instead of 'shared_pointer'. I can't think of any advantage in shortening "pointer" like that. But not to be bested, Rust makes it better: 'Rc'. Because why not.
[toc] | [prev] | [next] | [standalone]
| From | Ben Bacarisse <ben.usenet@bsb.me.uk> |
|---|---|
| Date | 2022-09-23 11:15 +0100 |
| Subject | Re: ???Microsoft Azure CTO Mark Russinovich: C/C++ should be deprecated??? |
| Message-ID | <87tu4ywg5t.fsf@bsb.me.uk> |
| In reply to | #86517 |
Juha Nieminen <nospam@thanks.invalid> writes: > In comp.lang.c++ David Brown <david.brown@hesbynett.no> wrote: >> Rust is supposed to be /better/ than C. It is supposed to look at how C >> has evolved over the decades, and pick a better starting point. So >> saying C is as bad, or worse, is not an excuse for poor design choices >> in Rust. > > That's exactly what I meant. C is something like 45 years old, Rust is > something like 10 years old, and supposed to be a more modern and better > designed language taking advantage of 50+ years of experience on how a > good programming language should be like. > > Answering the criticism "this 10yo language has this design problem" with > "oh yeah? Well, this 45yo language also has the same problem!" makes > no sense. Newer "better" language are not supposed to copy the mistakes > of the past. It's supposed to fix/improve on them. I took too much from the context. The context was Rust suggested as a replacement for C (any maybe C++, I don't recall) but your remarks seemed to all about thing things you thought bad about Rust that C also had. So in that context, all you seemed to be saying is that Rust is no worse than C. Maybe everyone, even the Rust champions, agree but they will then point to the things that /are/ better in Rust. -- Ben.
[toc] | [prev] | [next] | [standalone]
| From | Keith Thompson <Keith.S.Thompson+u@gmail.com> |
|---|---|
| Date | 2022-09-23 12:35 -0700 |
| Subject | Re: ???Microsoft Azure CTO Mark Russinovich: C/C++ should be deprecated??? |
| Message-ID | <875yhdevec.fsf@nosuchdomain.example.com> |
| In reply to | #86517 |
Juha Nieminen <nospam@thanks.invalid> writes:
> In comp.lang.c++ David Brown <david.brown@hesbynett.no> wrote:
>> Rust is supposed to be /better/ than C. It is supposed to look at how C
>> has evolved over the decades, and pick a better starting point. So
>> saying C is as bad, or worse, is not an excuse for poor design choices
>> in Rust.
>
> That's exactly what I meant. C is something like 45 years old, Rust is
> something like 10 years old, and supposed to be a more modern and better
> designed language taking advantage of 50+ years of experience on how a
> good programming language should be like.
>
> Answering the criticism "this 10yo language has this design problem" with
> "oh yeah? Well, this 45yo language also has the same problem!" makes
> no sense. Newer "better" language are not supposed to copy the mistakes
> of the past. It's supposed to fix/improve on them.
>
> I'm not saying that eg. C++ is significantly better. The
> "brevity-over-clarity" mentality can oftentimes be seen throughout
> the standard library.
>
> For example, there's literally no reason why it should be called
> 'shared_ptr' instead of 'shared_pointer'. I can't think of any advantage
> in shortening "pointer" like that.
>
> But not to be bested, Rust makes it better: 'Rc'.
>
> Because why not.
"Rc" stands for "Reference Counted Smart Pointer". It's not just a
random 2-letter sequence.
--
Keith Thompson (The_Other_Keith) Keith.S.Thompson+u@gmail.com
Working, but not speaking, for Philips
void Void(void) { Void(); } /* The recursive call of the void */
[toc] | [prev] | [next] | [standalone]
| From | "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> |
|---|---|
| Date | 2022-09-23 12:44 -0700 |
| Subject | Re: ???Microsoft Azure CTO Mark Russinovich: C/C++ should be deprecated??? |
| Message-ID | <tgl2b8$2knm0$2@dont-email.me> |
| In reply to | #86544 |
On 9/23/2022 12:35 PM, Keith Thompson wrote: > Juha Nieminen <nospam@thanks.invalid> writes: >> In comp.lang.c++ David Brown <david.brown@hesbynett.no> wrote: >>> Rust is supposed to be /better/ than C. It is supposed to look at how C >>> has evolved over the decades, and pick a better starting point. So >>> saying C is as bad, or worse, is not an excuse for poor design choices >>> in Rust. >> >> That's exactly what I meant. C is something like 45 years old, Rust is >> something like 10 years old, and supposed to be a more modern and better >> designed language taking advantage of 50+ years of experience on how a >> good programming language should be like. >> >> Answering the criticism "this 10yo language has this design problem" with >> "oh yeah? Well, this 45yo language also has the same problem!" makes >> no sense. Newer "better" language are not supposed to copy the mistakes >> of the past. It's supposed to fix/improve on them. >> >> I'm not saying that eg. C++ is significantly better. The >> "brevity-over-clarity" mentality can oftentimes be seen throughout >> the standard library. >> >> For example, there's literally no reason why it should be called >> 'shared_ptr' instead of 'shared_pointer'. I can't think of any advantage >> in shortening "pointer" like that. >> >> But not to be bested, Rust makes it better: 'Rc'. >> >> Because why not. > > "Rc" stands for "Reference Counted Smart Pointer". It's not just a > random 2-letter sequence. > Humm, Rc, I thought it might of been a "Reference Collected" attribute applied to an object's declaration.
[toc] | [prev] | [next] | [standalone]
| From | Juha Nieminen <nospam@thanks.invalid> |
|---|---|
| Date | 2022-09-26 08:09 +0000 |
| Subject | Re: ???Microsoft Azure CTO Mark Russinovich: C/C++ should be deprecated??? |
| Message-ID | <tgrmnr$1k0d$3@gioia.aioe.org> |
| In reply to | #86544 |
In comp.lang.c++ Keith Thompson <Keith.S.Thompson+u@gmail.com> wrote: >> But not to be bested, Rust makes it better: 'Rc'. >> >> Because why not. > > "Rc" stands for "Reference Counted Smart Pointer". It's not just a > random 2-letter sequence. Of course it's not random, but it's needlessly short, for no reason nor advantage.
[toc] | [prev] | [next] | [standalone]
| From | Bonita Montero <Bonita.Montero@gmail.com> |
|---|---|
| Date | 2022-09-24 13:25 +0200 |
| Subject | Re: ???Microsoft Azure CTO Mark Russinovich: C/C++ should be deprecated??? |
| Message-ID | <tgmpe6$2vai7$1@dont-email.me> |
| In reply to | #86489 |
Am 22.09.2022 um 11:41 schrieb Juha Nieminen: > In comp.lang.c++ Lynn McGuire <lynnmcguire5@gmail.com> wrote: >> ???Microsoft Azure CTO Mark Russinovich: C/C++ should be deprecated??? >> https://devclass.com/2022/09/20/microsoft-azure-cto-on-c-c/ >> >> ??????It???s time to halt starting any new projects in C/C++ and use Rust for >> those scenarios where a non-GC language is required. For the sake of >> security and reliability, the industry should declare those languages as >> deprecated,??? he said on Twitter, expressing a personal opinion rather >> than a fresh Microsoft policy.??? > > I took a cursory look at Rust, and it really seems to embrace the > "brevity-over-clarity" style of programming. > > What I call "brevity-over-clarity style of programming" is something > I have opposed and learned to hate over the years. For some reason it > appears to be what a good majority of beginner programmers naturally > gravitate towards, and some of them never unlearn. It's the general > use of names that are as short as possible, usually with complete > disregard to readability and understandability. (For example, > using the variable name "err" instead of "errorCode". Or "ret" > instead of "returnValue". Or "i" instead of "index". Sometimes the > word may be spelled-out rather than contracted, but in itself is > very non-descript without any further qualifiers. For example a > function named "convert()". Convert what? And into what?) > > It appears that functions in Rust are declared with a keyword. What is > this keyword? Perhaps "function"? Of course not. It's "fn". Because > why wouldn't it be? (It couldn't get much shorter than that, unless > you want it to be just "f". Which actually wouldn't even surprise me.) > > In order to declare a varible as mutable you have to specify that with > a keyword. And what is this keyword? Perhaps "mutable" (like in C++)? > Of course not. It's "mut", because why wouldn't it be? Who cares about > readability? You are saving typing a whopping 4 characters! > > Obviously type names are as short as possible, such as "i32" and "u64". > > Rust seems to also support a "using" keyword similar to the one used > in C++ and some other languages. Except that, obviously, "using" is > too long, so it's "use". (At least it is an entire English word.) > > The standard library (or at least the little I skimmed over) seems to be > a bit of a mixed bag. Sometimes words might be spelled out in their > entirety, but not even nearly always. (For example, what possible reason > is there to call a function "gen_range" instead of "generate_range"? Is > that honestly too much to type?) > > At least their string type is named "String". I wouldn't have been > surprised if it had been "Str". Must have been a lapsus. If that are your arguments against a lanuage - don't program at all.
[toc] | [prev] | [next] | [standalone]
| From | Juha Nieminen <nospam@thanks.invalid> |
|---|---|
| Date | 2022-09-26 08:13 +0000 |
| Subject | Re: ???Microsoft Azure CTO Mark Russinovich: C/C++ should be deprecated??? |
| Message-ID | <tgrmuh$1tcq$1@gioia.aioe.org> |
| In reply to | #86552 |
In comp.lang.c++ Bonita Montero <Bonita.Montero@gmail.com> wrote: > If that are your arguments against a lanuage - don't program at all. I thought you weren't reading any of my "nonsense". So why are you? Just go away, asshole.
[toc] | [prev] | [next] | [standalone]
| From | Keith Thompson <Keith.S.Thompson+u@gmail.com> |
|---|---|
| Date | 2022-09-26 10:44 -0700 |
| Subject | Re: ???Microsoft Azure CTO Mark Russinovich: C/C++ should be deprecated??? |
| Message-ID | <87mtamm3mw.fsf@nosuchdomain.example.com> |
| In reply to | #86600 |
Juha Nieminen <nospam@thanks.invalid> writes:
> In comp.lang.c++ Bonita Montero <Bonita.Montero@gmail.com> wrote:
>> If that are your arguments against a lanuage - don't program at all.
>
> I thought you weren't reading any of my "nonsense". So why are you?
>
> Just go away, asshole.
Juha, if you do not stop feeding the trolls, I will treat you
as a troll yourself and add you to my killfile. You do not have
to respond to everything. I have several users filtered out by
the equivalent of a killfile. You are bypassing my killfile by
posting responses. Please stop.
--
Keith Thompson (The_Other_Keith) Keith.S.Thompson+u@gmail.com
Working, but not speaking, for Philips
void Void(void) { Void(); } /* The recursive call of the void */
[toc] | [prev] | [next] | [standalone]
| From | Juha Nieminen <nospam@thanks.invalid> |
|---|---|
| Date | 2022-09-27 06:26 +0000 |
| Subject | Re: ???Microsoft Azure CTO Mark Russinovich: C/C++ should be deprecated??? |
| Message-ID | <tgu53e$1n80$1@gioia.aioe.org> |
| In reply to | #86623 |
In comp.lang.c++ Keith Thompson <Keith.S.Thompson+u@gmail.com> wrote: > Juha, if you do not stop feeding the trolls, I will treat you > as a troll yourself and add you to my killfile. You do not have > to respond to everything. I have several users filtered out by > the equivalent of a killfile. You are bypassing my killfile by > posting responses. Please stop. Which pretty much makes killfiles useless. I have never understood, and will never understand, why people use them. They are useless. The only thing they do is that they break threads and make them disjointed. And if you just keep adding people to your killfile because they keep responding to people in your killfile, or to people responding to those, or to people responding to those... sooner or later you'll have almost everybody in your killfile and see nothing. I honestly cannot see the point.
[toc] | [prev] | [next] | [standalone]
| From | Joe Pfeiffer <pfeiffer@cs.nmsu.edu> |
|---|---|
| Date | 2022-09-27 09:56 -0600 |
| Subject | Re: ???Microsoft Azure CTO Mark Russinovich: C/C++ should be deprecated??? |
| Message-ID | <1b8rm4erpk.fsf@pfeifferfamily.net> |
| In reply to | #86639 |
Juha Nieminen <nospam@thanks.invalid> writes: > In comp.lang.c++ Keith Thompson <Keith.S.Thompson+u@gmail.com> wrote: >> Juha, if you do not stop feeding the trolls, I will treat you >> as a troll yourself and add you to my killfile. You do not have >> to respond to everything. I have several users filtered out by >> the equivalent of a killfile. You are bypassing my killfile by >> posting responses. Please stop. > > Which pretty much makes killfiles useless. I have never understood, > and will never understand, why people use them. They are useless. > The only thing they do is that they break threads and make them > disjointed. And if you just keep adding people to your killfile > because they keep responding to people in your killfile, or to > people responding to those, or to people responding to those... > sooner or later you'll have almost everybody in your killfile > and see nothing. > > I honestly cannot see the point. Typically only a few people ever respond to the people who have, by dint of extraordinary effort, managed to land in my killfile. Typically those few people who do respond to them aren't much loss either. The killfile propagation you are describing is not my experience.
[toc] | [prev] | [next] | [standalone]
| From | Keith Thompson <Keith.S.Thompson+u@gmail.com> |
|---|---|
| Date | 2022-09-27 10:50 -0700 |
| Subject | Re: ???Microsoft Azure CTO Mark Russinovich: C/C++ should be deprecated??? |
| Message-ID | <87czbgn1tp.fsf@nosuchdomain.example.com> |
| In reply to | #86639 |
Juha Nieminen <nospam@thanks.invalid> writes:
> In comp.lang.c++ Keith Thompson <Keith.S.Thompson+u@gmail.com> wrote:
>> Juha, if you do not stop feeding the trolls, I will treat you
>> as a troll yourself and add you to my killfile. You do not have
>> to respond to everything. I have several users filtered out by
>> the equivalent of a killfile. You are bypassing my killfile by
>> posting responses. Please stop.
>
> Which pretty much makes killfiles useless. I have never understood,
> and will never understand, why people use them. They are useless.
> The only thing they do is that they break threads and make them
> disjointed. And if you just keep adding people to your killfile
> because they keep responding to people in your killfile, or to
> people responding to those, or to people responding to those...
> sooner or later you'll have almost everybody in your killfile
> and see nothing.
>
> I honestly cannot see the point.
I'm going to assume that you actually want an explanation. That might
be a bad assumption.
My killfile is extremely useful. It filters out posts by a handful of
users who would otherwise seriously damage the signal-to-noise ratio of
my view of this newsgroup. It makes this newsgroup a much more pleasant
place.
Most other users here have enough sense to refrain from posting
followups to noise.
My killfile does not generally make threads disjointed, because
typically none of the participants in a meaningful thread are in my
killfile.
You are one of the few users here who both posts relevent content *and*
posts annoying responses to trolls. Most recently, you posted:
> I thought you weren't reading any of my "nonsense". So why are you?
>
> Just go away, asshole.
because, apparently, you thought that *all* readers of this newsgroup
needed to see you say that. We really really didn't.
I'll note that the particular troll you were replying to posts under
what appears to be a valid email address, so you could have contacted
them directly.
Honestly, I understand the urge to feed the trolls. I've done it
myself. But I strongly suggest that you learn to let them have the last
word -- or it will never end.
Perhaps you now understand a bit better. Whether you do or not, my
previous statement stands. Your positive contributions here do not
outweigh the noise you produce with posts like your recent one.
--
Keith Thompson (The_Other_Keith) Keith.S.Thompson+u@gmail.com
Working, but not speaking, for Philips
void Void(void) { Void(); } /* The recursive call of the void */
[toc] | [prev] | [next] | [standalone]
| From | Blue-Maned_Hawk <bluemanedhawk@gmail.com> |
|---|---|
| Date | 2022-09-26 01:57 -0400 |
| Subject | Re: ???Microsoft Azure CTO Mark Russinovich: C/C++ should be deprecated??? |
| Message-ID | <tgrevh$3m0g3$1@dont-email.me> |
| In reply to | #86489 |
[Multipart message — attachments visible in raw view] — view raw
Man, of all the things i've seen people complain about about Rust, this is probably one of the most superficial. Granted, there are some issues with names, like how the `mut` and `unsafe` keywords impart value judgments, or how the Rust community has a single specific style (¡that might not work for everybody!) and by default the compiler gets all judgy if you don't follow those standards (¡remember, the only thing better than perfect is standardized!), or how the `use` keyword makes it more difficult to find where something is from. But all of these pale in comparison to Rust's bigger problems. -- /blu.mɛin.dʰak/ | shortens to "Hawk" | he/him/his/himself/Mr. bluemanedhawk.github.io I think my Usenet provider stores their passwords in plain text. If i'm acting suspiciously, chances are that that backfired on them.
[toc] | [prev] | [next] | [standalone]
| From | Jens Stuckelberger <Jens_Stuckelberger@nowhere.net> |
|---|---|
| Date | 2022-09-22 14:01 +0000 |
| Message-ID | <tghpsb$19fg$1@gioia.aioe.org> |
| In reply to | #86469 |
On Wed, 21 Sep 2022 14:04:43 -0500, Lynn McGuire wrote: > “Microsoft Azure CTO Mark Russinovich: C/C++ should be deprecated” > https://devclass.com/2022/09/20/microsoft-azure-cto-on-c-c/ > > ““It’s time to halt starting any new projects in C/C++ and use Rust for > those scenarios where a non-GC language is required. For the sake of > security and reliability, the industry should declare those languages as > deprecated,” he said on Twitter, expressing a personal opinion rather > than a fresh Microsoft policy.” A personal opinion is like an asshole: everybody's got one.
[toc] | [prev] | [next] | [standalone]
| From | Kaz Kylheku <864-117-4973@kylheku.com> |
|---|---|
| Date | 2022-09-23 03:17 +0000 |
| Message-ID | <20220922201519.3@kylheku.com> |
| In reply to | #86469 |
["Followup-To:" header set to comp.lang.c.] On 2022-09-21, Lynn McGuire <lynnmcguire5@gmail.com> wrote: > “Microsoft Azure CTO Mark Russinovich: C/C++ should be deprecated” > https://devclass.com/2022/09/20/microsoft-azure-cto-on-c-c/ > > ““It’s time to halt starting any new projects in C/C++ and use Rust for > those scenarios where a non-GC language is required. Those scenarios are almost never, though. The niche is small, and nothing needs replacing in it. > For the sake of > security and reliability ... write in an easy-to use GC language that doesn't have a fit if you get objects in a cycle, and in which any reference to any object can go anywhere in the program you want without a hassle. -- TXR Programming Language: http://nongnu.org/txr Cygnal: Cygwin Native Application Library: http://kylheku.com/cygnal
[toc] | [prev] | [next] | [standalone]
| From | Juha Nieminen <nospam@thanks.invalid> |
|---|---|
| Date | 2022-09-23 07:50 +0000 |
| Subject | Re: ???Microsoft Azure CTO Mark Russinovich: C/C++ should be deprecated??? |
| Message-ID | <tgjogc$1ivg$2@gioia.aioe.org> |
| In reply to | #86514 |
In comp.lang.c++ Kaz Kylheku <864-117-4973@kylheku.com> wrote: > ["Followup-To:" header set to comp.lang.c.] > On 2022-09-21, Lynn McGuire <lynnmcguire5@gmail.com> wrote: >> ???Microsoft Azure CTO Mark Russinovich: C/C++ should be deprecated??? >> https://devclass.com/2022/09/20/microsoft-azure-cto-on-c-c/ >> >> ??????It???s time to halt starting any new projects in C/C++ and use Rust for >> those scenarios where a non-GC language is required. > > Those scenarios are almost never, though. > > The niche is small, and nothing needs replacing in it. I wouldn't call embedded programming to be a "small niche". (Well, the subset of embedded programming that happens on processors so small that they can't run Linux, at least.)
[toc] | [prev] | [next] | [standalone]
| From | David Brown <david.brown@hesbynett.no> |
|---|---|
| Date | 2022-09-23 13:37 +0200 |
| Subject | Re: ???Microsoft Azure CTO Mark Russinovich: C/C++ should be deprecated??? |
| Message-ID | <tgk5qc$2h0hh$1@dont-email.me> |
| In reply to | #86519 |
On 23/09/2022 09:50, Juha Nieminen wrote: > In comp.lang.c++ Kaz Kylheku <864-117-4973@kylheku.com> wrote: >> ["Followup-To:" header set to comp.lang.c.] >> On 2022-09-21, Lynn McGuire <lynnmcguire5@gmail.com> wrote: >>> ???Microsoft Azure CTO Mark Russinovich: C/C++ should be deprecated??? >>> https://devclass.com/2022/09/20/microsoft-azure-cto-on-c-c/ >>> >>> ??????It???s time to halt starting any new projects in C/C++ and use Rust for >>> those scenarios where a non-GC language is required. >> >> Those scenarios are almost never, though. >> >> The niche is small, and nothing needs replacing in it. > > I wouldn't call embedded programming to be a "small niche". > > (Well, the subset of embedded programming that happens on processors > so small that they can't run Linux, at least.) And it will be a /long/ time before Rust has significant market share in these devices. Despite wanting the newest microcontrollers, embedded programmers are a conservative bunch - C90 is, I think, the most popular choice of language. (Yes, C90 - not C99.) C++ is gaining, assembly is dwindling (but not gone), and there is a small subset that like Ada, Forth, MicroPython and a few others. It may well be that the use of Rust in such systems would be a good idea - but that does not mean it will happen to any serious extent.
[toc] | [prev] | [next] | [standalone]
| From | Juha Nieminen <nospam@thanks.invalid> |
|---|---|
| Date | 2022-09-26 08:19 +0000 |
| Subject | Re: ???Microsoft Azure CTO Mark Russinovich: C/C++ should be deprecated??? |
| Message-ID | <tgrnao$3gj$1@gioia.aioe.org> |
| In reply to | #86527 |
In comp.lang.c++ David Brown <david.brown@hesbynett.no> wrote: >> I wouldn't call embedded programming to be a "small niche". >> >> (Well, the subset of embedded programming that happens on processors >> so small that they can't run Linux, at least.) > > And it will be a /long/ time before Rust has significant market share in > these devices. Despite wanting the newest microcontrollers, embedded > programmers are a conservative bunch - C90 is, I think, the most popular > choice of language. (Yes, C90 - not C99.) In my experience working in the field I think C99 has gained popularity even among many (although not all) old-school "as bare metal as possible" embedded C programmers. Designated initializers are perhaps the best thing that has happened to C during its entire existence (which is why they have been widely adopted in the Linux kernel, and many other major C projects).
[toc] | [prev] | [next] | [standalone]
| From | David Brown <david.brown@hesbynett.no> |
|---|---|
| Date | 2022-09-26 13:55 +0200 |
| Subject | Re: ???Microsoft Azure CTO Mark Russinovich: C/C++ should be deprecated??? |
| Message-ID | <tgs3un$3nr9v$1@dont-email.me> |
| In reply to | #86601 |
On 26/09/2022 10:19, Juha Nieminen wrote: > In comp.lang.c++ David Brown <david.brown@hesbynett.no> wrote: >>> I wouldn't call embedded programming to be a "small niche". >>> >>> (Well, the subset of embedded programming that happens on processors >>> so small that they can't run Linux, at least.) >> >> And it will be a /long/ time before Rust has significant market share in >> these devices. Despite wanting the newest microcontrollers, embedded >> programmers are a conservative bunch - C90 is, I think, the most popular >> choice of language. (Yes, C90 - not C99.) > > In my experience working in the field I think C99 has gained popularity > even among many (although not all) old-school "as bare metal as possible" > embedded C programmers. > Certainly C99 has gained popularity, but I think many C programmers would be surprised to see how common C90 still is. It's also common to have a kind of mixture of C90 with bits of C99 - people might use single line comments but define all their local variables uninitialised at the top of a function and use "int" when they should use "bool". And the use of compiler extensions is also common - for many microcontrollers, it is unavoidable. > Designated initializers are perhaps the best thing that has happened to C > during its entire existence (which is why they have been widely adopted > in the Linux kernel, and many other major C projects). Designated initialisers are certainly nice, but I would not call them the "best" feature of C99. If I were to pick one favourite C99 feature, it would be mixing declarations and statements - but such choices are highly subjective. However, it's taken until C++20 to get designated initialisers in C++, which suggests that they were not viewed as the most important feature (though there has certainly been plenty of call for them in C++).
[toc] | [prev] | [next] | [standalone]
| From | Juha Nieminen <nospam@thanks.invalid> |
|---|---|
| Date | 2022-09-26 14:31 +0000 |
| Subject | Re: ???Microsoft Azure CTO Mark Russinovich: C/C++ should be deprecated??? |
| Message-ID | <tgsd4k$lcr$1@gioia.aioe.org> |
| In reply to | #86612 |
In comp.lang.c++ David Brown <david.brown@hesbynett.no> wrote: >> Designated initializers are perhaps the best thing that has happened to C >> during its entire existence (which is why they have been widely adopted >> in the Linux kernel, and many other major C projects). > > Designated initialisers are certainly nice, but I would not call them > the "best" feature of C99. If I were to pick one favourite C99 feature, > it would be mixing declarations and statements - but such choices are > highly subjective. It is indeed highly subjective. Many C programmers are of the opinion that declaring variables within the code implementation is actually a bad thing, and they still prefer declaring all the variables of the function at the beginning. (If I'm not mistaken, this is actually one of the style requirements of the Linux kernel code. Although I'm not sure if it's outright required or just recommended.) When you have seen and programmed with designated initializers, however, you really start to appreciate them. If you are writing eg. a Linux kernel module, you essentially "fill out" some particular structs with the data required for your module to work. The great thing about designated initializers is that not only are these struct initializations much more readable, but moreover the code doesn't need to care what the order of the member variables is, or if there are more member variables before, after, or in-between the ones being initialized. It really makes a lot easier. (It also allows for those structs to be changed by eg. adding new member variables without breaking tons of existing code.) > However, it's taken until C++20 to get designated > initialisers in C++, which suggests that they were not viewed as the > most important feature (though there has certainly been plenty of call > for them in C++). And C++20 ruined one of the best aspects of them: The fact that you don't need to know the order in which the member variables have been defined in the struct. (Not having to care about the order allows for refactoring of the struct by swapping things around. Also, the order of the member variables in the struct might have been chosen for space efficiency, while in the initialization you can use a more logical order of initialization by grouping related values together.)
[toc] | [prev] | [next] | [standalone]
Page 3 of 6 — ← Prev page 1 2 [3] 4 5 6 Next page →
Back to top | Article view | comp.lang.c++
csiph-web