Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]
Groups > comp.lang.c > #167776 > 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 119 — 31 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??? Single Stage to Orbit <alex.buell@munted.eu> - 2022-09-22 09:42 +0100
Re: ???Microsoft Azure CTO Mark Russinovich: C/C++ should be deprecated??? David Brown <david.brown@hesbynett.no> - 2022-09-22 11:16 +0200
Re: ???Microsoft Azure CTO Mark Russinovich: C/C++ should be deprecated??? Ben Bacarisse <ben.usenet@bsb.me.uk> - 2022-09-22 16:48 +0100
Re: ???Microsoft Azure CTO Mark Russinovich: C/C++ should be deprecated??? David Brown <david.brown@hesbynett.no> - 2022-09-22 23:12 +0200
Re: ???Microsoft Azure CTO Mark Russinovich: C/C++ should be deprecated??? Ben Bacarisse <ben.usenet@bsb.me.uk> - 2022-09-23 01:40 +0100
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 deprecated??? The Real Non Homosexual <cdalten@gmail.com> - 2022-10-10 19:12 -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??? 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” Ben Collver <bencollver@tilde.pink> - 2022-09-22 15:19 +0000
Re: “Microsoft Azure CTO Mark Russinovich: C/C++ should be deprecated” gazelle@shell.xmission.com (Kenny McCormack) - 2022-09-22 15:23 +0000
Re: “Microsoft Azure CTO Mark Russinovich: C/C++ should be deprecated” "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> - 2022-09-22 12:13 -0700
Re: “Microsoft Azure CTO Mark Russinovich: C/C++ should be deprecated” Andrea Biscuola <a@abiscuola.com> - 2022-09-22 20:32 +0200
Re: “Microsoft Azure CTO Mark Russinovich: C/C++ should be deprecated” scott@slp53.sl.home (Scott Lurndal) - 2022-09-22 19:01 +0000
Re: “Microsoft Azure CTO Mark Russinovich: C/C++ should be deprecated” Richard Harnden <richard.nospam@gmail.com> - 2022-09-22 17:36 +0100
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??? Paavo Helde <eesnimi@osa.pri.ee> - 2022-09-27 22:32 +0300
Re: ???Microsoft Azure CTO Mark Russinovich: C/C++ should be deprecated??? Kaz Kylheku <864-117-4973@kylheku.com> - 2022-09-27 23:52 +0000
Re: ???Microsoft Azure CTO Mark Russinovich: C/C++ should be deprecated??? scott@slp53.sl.home (Scott Lurndal) - 2022-09-27 19:57 +0000
Re: ???Microsoft Azure CTO Mark Russinovich: C/C++ should be deprecated??? Kaz Kylheku <864-117-4973@kylheku.com> - 2022-09-28 00:03 +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??? scott@slp53.sl.home (Scott Lurndal) - 2022-09-28 14:18 +0000
Re: ???Microsoft Azure CTO Mark Russinovich: C/C++ should be deprecated??? Kaz Kylheku <864-117-4973@kylheku.com> - 2022-09-28 15:26 +0000
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-29 20:45 +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??? Michael S <already5chosen@yahoo.com> - 2022-10-01 11:40 -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??? 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??? scott@slp53.sl.home (Scott Lurndal) - 2022-09-28 14:17 +0000
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??? scott@slp53.sl.home (Scott Lurndal) - 2022-09-28 18:48 +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??? Bart <bc@freeuk.com> - 2022-09-27 12:41 +0100
Re: ???Microsoft Azure CTO Mark Russinovich: C/C++ should be deprecated??? Ben Bacarisse <ben.usenet@bsb.me.uk> - 2022-09-27 15:22 +0100
Re: ???Microsoft Azure CTO Mark Russinovich: C/C++ should be deprecated??? David Brown <david.brown@hesbynett.no> - 2022-09-27 18:13 +0200
Re: ???Microsoft Azure CTO Mark Russinovich: C/C++ should be deprecated??? David Brown <david.brown@hesbynett.no> - 2022-09-27 16:50 +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??? David Brown <david.brown@hesbynett.no> - 2022-09-26 08:55 +0200
Re: ???Microsoft Azure CTO Mark Russinovich: C/C++ should be deprecated??? BGB <cr88192@gmail.com> - 2022-10-01 16:07 -0500
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 1 of 6 [1] 2 3 4 5 6 Next page →
| From | Lynn McGuire <lynnmcguire5@gmail.com> |
|---|---|
| Date | 2022-09-21 14:04 -0500 |
| Subject | “Microsoft Azure CTO Mark Russinovich: C/C++ should be deprecated” |
| Message-ID | <tgfn8d$1sr8e$1@dont-email.me> |
“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.”
Wow ! Bold.
Lynn
[toc] | [next] | [standalone]
| From | "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> |
|---|---|
| Date | 2022-09-21 12:28 -0700 |
| Message-ID | <tgfok5$1svgu$1@dont-email.me> |
| In reply to | #167776 |
On 9/21/2022 12:04 PM, 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. Ohhh boy. Humm... > 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.” > > Wow ! Holy... MOLY! > Bold. Wow!! Where a non-gc lang is required? Huh? I personally have some issues with GC. I don't really like it. security and reliability? Is it possible to write buggy code in Rust? I have to admit that I never used it. Shit.
[toc] | [prev] | [next] | [standalone]
| From | Juha Nieminen <nospam@thanks.invalid> |
|---|---|
| Date | 2022-09-22 06:16 +0000 |
| Subject | Re: ???Microsoft Azure CTO Mark Russinovich: C/C++ should be deprecated??? |
| Message-ID | <tggukj$1bvn$1@gioia.aioe.org> |
| In reply to | #167776 |
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.??? > > Wow ! Bold. Is a "Rust religion" forming in the industry? I remember when Java was supposed to be the Holy Grail and answer to everything. (Nowadays I get the feeling that Java survives solely because it's the main/only programming language available for developing for Android devices. Haven't exactly researched if it's the only possible, or just the main one.)
[toc] | [prev] | [next] | [standalone]
| From | David Brown <david.brown@hesbynett.no> |
|---|---|
| Date | 2022-09-22 09:45 +0200 |
| Subject | Re: ???Microsoft Azure CTO Mark Russinovich: C/C++ should be deprecated??? |
| Message-ID | <tgh3re$235cv$1@dont-email.me> |
| In reply to | #167780 |
On 22/09/2022 08:16, Juha Nieminen wrote: > 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.??? >> >> Wow ! Bold. > > Is a "Rust religion" forming in the industry? > Rust is, IMHO, far too immature to be the right choice for major projects. It has some good points, but it needs to stabilise as a language and get more and better tools before it can be an alternative to C or C++ for a lot of work. An alternative future solution is for the C++ folks to copy the useful parts from Rust. Rust's memory safety (AFAIUI) relies partly on the use of static analysis tools run on the code. There are a variety of static and dynamic analysis tools available for C++, but they are often tightly to specific compilers or expensive third-party tools. If a common standard could be formed and integrated with the standard library and with open source tools, then C++ would be as "safe" as Rust for those that chose to use these tools. > I remember when Java was supposed to be the Holy Grail and answer to > everything. > > (Nowadays I get the feeling that Java survives solely because it's the > main/only programming language available for developing for Android > devices. Haven't exactly researched if it's the only possible, or just > the main one.) The preferred language for Android is now Kotlin (which runs on the same JVM virtual machine).
[toc] | [prev] | [next] | [standalone]
| From | Single Stage to Orbit <alex.buell@munted.eu> |
|---|---|
| Date | 2022-09-22 09:42 +0100 |
| Subject | Re: ???Microsoft Azure CTO Mark Russinovich: C/C++ should be deprecated??? |
| Message-ID | <e3070efe24638710878f48121260c80681ef59a6.camel@munted.eu> |
| In reply to | #167781 |
On Thu, 2022-09-22 at 09:45 +0200, David Brown wrote: > Rust is, IMHO, far too immature to be the right choice for major > projects. It has some good points, but it needs to stabilise as a > language and get more and better tools before it can be an > alternative to C or C++ for a lot of work. I'm greatly disturbed that support for Rust is being added to Linux in the next kernel release. This imposes a limitation on the kernel on what architectures it can be compiled for. If you port to an architecture unsupported by LLVM (Rust has a hard dependency on this), you are SOL. GCC supports a large number of architectures. I wouldn't mind so much if LLVM supported what GCC can support but it does not. And that's not good news. -- Tactical Nuclear Kittens
[toc] | [prev] | [next] | [standalone]
| From | David Brown <david.brown@hesbynett.no> |
|---|---|
| Date | 2022-09-22 11:16 +0200 |
| Subject | Re: ???Microsoft Azure CTO Mark Russinovich: C/C++ should be deprecated??? |
| Message-ID | <tgh94l$23jb1$1@dont-email.me> |
| In reply to | #167782 |
On 22/09/2022 10:42, Single Stage to Orbit wrote: > On Thu, 2022-09-22 at 09:45 +0200, David Brown wrote: >> Rust is, IMHO, far too immature to be the right choice for major >> projects. It has some good points, but it needs to stabilise as a >> language and get more and better tools before it can be an >> alternative to C or C++ for a lot of work. > > I'm greatly disturbed that support for Rust is being added to Linux in > the next kernel release. This imposes a limitation on the kernel on > what architectures it can be compiled for. If you port to an > architecture unsupported by LLVM (Rust has a hard dependency on this), > you are SOL. GCC supports a large number of architectures. > > I wouldn't mind so much if LLVM supported what GCC can support but it > does not. And that's not good news. Personally, I think the bigger problem is that Rust itself is not stable. It is getting there, but the language is still undergoing change and gaining significant new features. It has to be at the point where they say maintaining compatibility with existing code is more important than the convenience when writing new code before it is suitable for something like Linux. I don't know Rust well, and have only played with it briefly so far. There are various ways to resolve such issues - such as having a language version statement in code and requiring compilers to support old language versions as well as new ones. LLVM supports all mainstream Linux targets, but I don't think it supports all of the less popular targets. Some of these targets can be considered outdated, but not all of them. A Rust front-end for gcc is in the works, and has been accepted as part of mainline gcc, though it is still somewhat limited and experimental.
[toc] | [prev] | [next] | [standalone]
| From | Ben Bacarisse <ben.usenet@bsb.me.uk> |
|---|---|
| Date | 2022-09-22 16:48 +0100 |
| Subject | Re: ???Microsoft Azure CTO Mark Russinovich: C/C++ should be deprecated??? |
| Message-ID | <87v8pfxvew.fsf@bsb.me.uk> |
| In reply to | #167783 |
David Brown <david.brown@hesbynett.no> writes: > On 22/09/2022 10:42, Single Stage to Orbit wrote: >> On Thu, 2022-09-22 at 09:45 +0200, David Brown wrote: >>> Rust is, IMHO, far too immature to be the right choice for major >>> projects. It has some good points, but it needs to stabilise as a >>> language and get more and better tools before it can be an >>> alternative to C or C++ for a lot of work. >> I'm greatly disturbed that support for Rust is being added to Linux in >> the next kernel release. This imposes a limitation on the kernel on >> what architectures it can be compiled for. If you port to an >> architecture unsupported by LLVM (Rust has a hard dependency on this), >> you are SOL. GCC supports a large number of architectures. >> I wouldn't mind so much if LLVM supported what GCC can support but it >> does not. And that's not good news. > > Personally, I think the bigger problem is that Rust itself is not > stable. It is getting there, but the language is still undergoing > change and gaining significant new features. More so than C++? -- Ben.
[toc] | [prev] | [next] | [standalone]
| From | David Brown <david.brown@hesbynett.no> |
|---|---|
| Date | 2022-09-22 23:12 +0200 |
| Subject | Re: ???Microsoft Azure CTO Mark Russinovich: C/C++ should be deprecated??? |
| Message-ID | <tgij33$2a8di$1@dont-email.me> |
| In reply to | #167790 |
On 22/09/2022 17:48, Ben Bacarisse wrote: > David Brown <david.brown@hesbynett.no> writes: > >> On 22/09/2022 10:42, Single Stage to Orbit wrote: >>> On Thu, 2022-09-22 at 09:45 +0200, David Brown wrote: >>>> Rust is, IMHO, far too immature to be the right choice for major >>>> projects. It has some good points, but it needs to stabilise as a >>>> language and get more and better tools before it can be an >>>> alternative to C or C++ for a lot of work. >>> I'm greatly disturbed that support for Rust is being added to Linux in >>> the next kernel release. This imposes a limitation on the kernel on >>> what architectures it can be compiled for. If you port to an >>> architecture unsupported by LLVM (Rust has a hard dependency on this), >>> you are SOL. GCC supports a large number of architectures. >>> I wouldn't mind so much if LLVM supported what GCC can support but it >>> does not. And that's not good news. >> >> Personally, I think the bigger problem is that Rust itself is not >> stable. It is getting there, but the language is still undergoing >> change and gaining significant new features. > > More so than C++? > Perhaps not (I don't know enough detail to tell, though I believe the changes come faster in Rust than C++ which stocks them up for 3 years at a time) - but significantly more so than C, which is the main language for the Linux kernel. I expect that the rate of change to Rust will slow down, and that the language will reach a point that people are happy that it can do all they want it to do for the foreseeable future. Then we'll start seeing more implementations (including gcc), more tools, more users, and more Rust code. /Then/ it will make sense to consider using it in the Linux kernel.
[toc] | [prev] | [next] | [standalone]
| From | Ben Bacarisse <ben.usenet@bsb.me.uk> |
|---|---|
| Date | 2022-09-23 01:40 +0100 |
| Subject | Re: ???Microsoft Azure CTO Mark Russinovich: C/C++ should be deprecated??? |
| Message-ID | <877d1uylcp.fsf@bsb.me.uk> |
| In reply to | #167805 |
David Brown <david.brown@hesbynett.no> writes: > On 22/09/2022 17:48, Ben Bacarisse wrote: >> David Brown <david.brown@hesbynett.no> writes: >> >>> On 22/09/2022 10:42, Single Stage to Orbit wrote: >>>> On Thu, 2022-09-22 at 09:45 +0200, David Brown wrote: >>>>> Rust is, IMHO, far too immature to be the right choice for major >>>>> projects. It has some good points, but it needs to stabilise as a >>>>> language and get more and better tools before it can be an >>>>> alternative to C or C++ for a lot of work. >>>> I'm greatly disturbed that support for Rust is being added to Linux in >>>> the next kernel release. This imposes a limitation on the kernel on >>>> what architectures it can be compiled for. If you port to an >>>> architecture unsupported by LLVM (Rust has a hard dependency on this), >>>> you are SOL. GCC supports a large number of architectures. >>>> I wouldn't mind so much if LLVM supported what GCC can support but it >>>> does not. And that's not good news. >>> >>> Personally, I think the bigger problem is that Rust itself is not >>> stable. It is getting there, but the language is still undergoing >>> change and gaining significant new features. >> More so than C++? > > Perhaps not (I don't know enough detail to tell, though I believe the > changes come faster in Rust than C++ which stocks them up for 3 years > at a time) - but significantly more so than C, which is the main > language for the Linux kernel. After I posted I went to look, and it does seem to be fast-changing. But I don't know if these are mostly minor changes or major changes that break existing code. Obviously there's nothing to stop a project (like Linux) from stacking up the changes by permitting only certain versions and switching up only every few years, but this fails, of course, for changes that break existing code. > I expect that the rate of change to Rust will slow down, and that the > language will reach a point that people are happy that it can do all > they want it to do for the foreseeable future. Then we'll start > seeing more implementations (including gcc), more tools, more users, > and more Rust code. /Then/ it will make sense to consider using it in > the Linux kernel. It depends on what using it in the Linux kernel means. If it means that someone can write their device driver in Rust, then the onus is on them to keep up with the language changes and how these are used by the kernel build system. -- Ben.
[toc] | [prev] | [next] | [standalone]
| From | Blue-Maned_Hawk <bluemanedhawk@gmail.com> |
|---|---|
| Date | 2022-09-26 02:07 -0400 |
| Subject | Re: ???Microsoft Azure CTO Mark Russinovich: C/C++ should be deprecated??? |
| Message-ID | <tgrfj2$3m0g3$3@dont-email.me> |
| In reply to | #167780 |
[Multipart message — attachments visible in raw view] — view raw
On 9/22/22 02:16, Juha Nieminen wrote: > [snip] > > I remember when Java was supposed to be the Holy Grail and answer to > everything. > > (Nowadays I get the feeling that Java survives solely because it's the > main/only programming language available for developing for Android > devices. Haven't exactly researched if it's the only possible, or just > the main one.) I think it's possible to use other languages instead of Java, but i don't have any sort of citation for that. Personally, it seems to me like another big reason Java continues to limp on is because Minecraft, a terrible game that's somehow one of the most popular in the world, is based upon Java for it's primary edition. -- /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 | David Brown <david.brown@hesbynett.no> |
|---|---|
| Date | 2022-09-26 08:42 +0200 |
| Subject | Re: ???Microsoft Azure CTO Mark Russinovich: C/C++ should be deprecated??? |
| Message-ID | <tgrhl3$3mafr$1@dont-email.me> |
| In reply to | #167846 |
On 26/09/2022 08:07, Blue-Maned_Hawk wrote: > On 9/22/22 02:16, Juha Nieminen wrote: >> [snip] > > >> I remember when Java was supposed to be the Holy Grail and answer to >> everything. >> >> (Nowadays I get the feeling that Java survives solely because it's the >> main/only programming language available for developing for Android >> devices. Haven't exactly researched if it's the only possible, or just >> the main one.) > > I think it's possible to use other languages instead of Java, but i > don't have any sort of citation for that. Some easy references: <https://en.wikipedia.org/wiki/Kotlin_(programming_language)> <https://en.wikipedia.org/wiki/Android_software_development> Kotlin is now the preferred choice (I have little experience of Java, and none of Kotlin, so I have no idea of its pros and cons). But you can use all sorts of other languages too. In practice, a great many apps for Android are basically webpages - so HTML5 and JavaScript are all you need. > Personally, it seems to me > like another big reason Java continues to limp on is because Minecraft, > a terrible game that's somehow one of the most popular in the world, is > based upon Java for it's primary edition. > Minecraft is probably the Java application with most users. But Java has been hugely popular for in-house and dedicated programs for businesses, so there is a vast investment in Java code that most people never see. It may go out of fashion, but like Cobol, it will never die.
[toc] | [prev] | [next] | [standalone]
| From | Muttley@dastardlyhq.com |
|---|---|
| Date | 2022-09-26 15:24 +0000 |
| Subject | Re: ???Microsoft Azure CTO Mark Russinovich: C/C++ should be |
| Message-ID | <tgsg7i$8a5$1@gioia.aioe.org> |
| In reply to | #167848 |
On Mon, 26 Sep 2022 08:42:43 +0200 David Brown <david.brown@hesbynett.no> wrote: >On 26/09/2022 08:07, Blue-Maned_Hawk wrote: >> On 9/22/22 02:16, Juha Nieminen wrote: >>> [snip] >> > >>> I remember when Java was supposed to be the Holy Grail and answer to >>> everything. >>> >>> (Nowadays I get the feeling that Java survives solely because it's the >>> main/only programming language available for developing for Android >>> devices. Haven't exactly researched if it's the only possible, or just >>> the main one.) >> >> I think it's possible to use other languages instead of Java, but i >> don't have any sort of citation for that. > >Some easy references: > ><https://en.wikipedia.org/wiki/Kotlin_(programming_language)> ><https://en.wikipedia.org/wiki/Android_software_development> > >Kotlin is now the preferred choice (I have little experience of Java, >and none of Kotlin, so I have no idea of its pros and cons). But you >can use all sorts of other languages too. > >In practice, a great many apps for Android are basically webpages - so >HTML5 and JavaScript are all you need. > >> Personally, it seems to me >> like another big reason Java continues to limp on is because Minecraft, >> a terrible game that's somehow one of the most popular in the world, is >> based upon Java for it's primary edition. >> > >Minecraft is probably the Java application with most users. But Java >has been hugely popular for in-house and dedicated programs for Java looks great at first - no pointer issues, fully (almost) OO and garbage collected. Then a team writes a huge application in it which sucks up 100s of megs of memory just to boot, hangs at inappropriate moments while it GCs and generally runs multiple times slower than something similar written in C++. Then they find the write once run anywhere mantra only works if you don't do anything OS specific which for any given business app is unlikely and the 101 libraries to do the same thing becomes unmanagable. >businesses, so there is a vast investment in Java code that most people >never see. It may go out of fashion, but like Cobol, it will never die. True, but its doubtful much new greenfield code relatively speaking will be written in it in the future.
[toc] | [prev] | [next] | [standalone]
| From | The Real Non Homosexual <cdalten@gmail.com> |
|---|---|
| Date | 2022-10-10 19:12 -0700 |
| Subject | Re: ???Microsoft Azure CTO Mark Russinovich: C/C++ should be deprecated??? |
| Message-ID | <ad445be0-b4ad-4dfe-94fa-63df97a86e01n@googlegroups.com> |
| In reply to | #167848 |
> In practice, a great many apps for Android are basically webpages - so > HTML5 and JavaScript are all you need. I wrote an Android phone app that doesn't use webpages nor HTML5 and JavaScript. https://github.com/cdalten/WorkReminder/
[toc] | [prev] | [next] | [standalone]
| From | Juha Nieminen <nospam@thanks.invalid> |
|---|---|
| Date | 2022-09-22 09:41 +0000 |
| Subject | Re: ???Microsoft Azure CTO Mark Russinovich: C/C++ should be deprecated??? |
| Message-ID | <tghakg$b0m$1@gioia.aioe.org> |
| In reply to | #167776 |
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.
[toc] | [prev] | [next] | [standalone]
| From | Ben Bacarisse <ben.usenet@bsb.me.uk> |
|---|---|
| Date | 2022-09-22 16:46 +0100 |
| Subject | Re: ???Microsoft Azure CTO Mark Russinovich: C/C++ should be deprecated??? |
| Message-ID | <871qs3za1l.fsf@bsb.me.uk> |
| In reply to | #167784 |
Juha Nieminen <nospam@thanks.invalid> writes: > 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?) I've seen all of these in C, so why single out Rust? Does the language itself somehow promote this style? > 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.) Of course it could get shorter. In C it's nothing at all and you don't complain about that degree of brevity! > 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! And C has int, struct, enum, char, const, extern... I think there is a bit of a double standard here. -- Ben.
[toc] | [prev] | [next] | [standalone]
| From | gazelle@shell.xmission.com (Kenny McCormack) |
|---|---|
| Date | 2022-09-22 16:15 +0000 |
| Subject | Re: ???Microsoft Azure CTO Mark Russinovich: C/C++ should be deprecated??? |
| Message-ID | <tgi1no$1qrfd$1@news.xmission.com> |
| In reply to | #167789 |
In article <871qs3za1l.fsf@bsb.me.uk>, Ben Bacarisse <ben.usenet@bsb.me.uk> wrote: ... >> 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! > >And C has int, struct, enum, char, const, extern... I think there is a >bit of a double standard here. I think the implication is that, as a new language, Rust could and should do better. We don't NEED to keep re-implementing the mistakes of the past. C/C++ is, of course, constrained by those mistakes, because of their long history, but a new language isn't. That said, I *would* like to see in what ways the language itself reinforces these habits. -- The randomly chosen signature file that would have appeared here is more than 4 lines long. As such, it violates one or more Usenet RFCs. In order to remain in compliance with said RFCs, the actual sig can be found at the following URL: http://user.xmission.com/~gazelle/Sigs/Snicker
[toc] | [prev] | [next] | [standalone]
| From | David Brown <david.brown@hesbynett.no> |
|---|---|
| Date | 2022-09-22 20:43 +0200 |
| Subject | Re: ???Microsoft Azure CTO Mark Russinovich: C/C++ should be deprecated??? |
| Message-ID | <tgiabp$29fjk$1@dont-email.me> |
| In reply to | #167789 |
On 22/09/2022 17:46, Ben Bacarisse wrote: > Juha Nieminen <nospam@thanks.invalid> writes: > >> 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?) > > I've seen all of these in C, so why single out Rust? Does the language > itself somehow promote this style? > >> 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.) > > Of course it could get shorter. In C it's nothing at all and you don't > complain about that degree of brevity! > >> 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! > > And C has int, struct, enum, char, const, extern... I think there is a > bit of a double standard here. > 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. I don't know if I'd agree entirely with Juha here, but I'd certainly agree to some degree. But the point is that /if/ you think it is better to have clearer names, keywords, and language syntax in general, then Rust as a modern language should have done better. Whataboutism is not an acceptable defence, nor is it double standards to use a different language that is worse. Rust definitely scores points (IMHO) for having "mut" and "fn", even if I too would have preferred something a little longer.
[toc] | [prev] | [next] | [standalone]
| From | Ben Bacarisse <ben.usenet@bsb.me.uk> |
|---|---|
| Date | 2022-09-22 20:15 +0100 |
| Subject | Re: ???Microsoft Azure CTO Mark Russinovich: C/C++ should be deprecated??? |
| Message-ID | <87pmfnxlt0.fsf@bsb.me.uk> |
| In reply to | #167797 |
David Brown <david.brown@hesbynett.no> writes: > On 22/09/2022 17:46, Ben Bacarisse wrote: >> Juha Nieminen <nospam@thanks.invalid> writes: >> >>> 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?) >> I've seen all of these in C, so why single out Rust? Does the language >> itself somehow promote this style? >> >>> 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.) >> Of course it could get shorter. In C it's nothing at all and you don't >> complain about that degree of brevity! >> >>> 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! >> >> And C has int, struct, enum, char, const, extern... I think there is a >> bit of a double standard here. > > 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. Well all I can say is that's not how I read the remarks. I didn't get any sense of it being a disappointment, just that these things are worthy of criticism. Anyway, short keywords are, to my mind, a complete non-issue. I don't mind them in C and I don't mind them in Rust. > I don't know if I'd agree entirely with Juha here, but I'd certainly > agree to some degree. But the point is that /if/ you think it is > better to have clearer names, keywords, and language syntax in > general, then Rust as a modern language should have done better. It's odd, but I'd never go that far. Maybe I am just not assertive enough for the modern world! If I had this view, I'd express some disappointment in a wasted opportunity, but I could not bring myself to say that the designers should have done better. > Whataboutism is not an acceptable defence, Sure. I was not defending Rust's choice. > nor is it double standards > to use a different language that is worse. Nor was I suggesting the double standard came from making such a multi-faceted choice as which language to use. I was remarking on never having seen this objection raised about C or C++. -- Ben.
[toc] | [prev] | [next] | [standalone]
| From | David Brown <david.brown@hesbynett.no> |
|---|---|
| Date | 2022-09-22 22:56 +0200 |
| Subject | Re: ???Microsoft Azure CTO Mark Russinovich: C/C++ should be deprecated??? |
| Message-ID | <tgii6g$2a5pu$1@dont-email.me> |
| In reply to | #167800 |
On 22/09/2022 21:15, Ben Bacarisse wrote: > David Brown <david.brown@hesbynett.no> writes: > >> On 22/09/2022 17:46, Ben Bacarisse wrote: >>> Juha Nieminen <nospam@thanks.invalid> writes: >>> >>>> 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?) >>> I've seen all of these in C, so why single out Rust? Does the language >>> itself somehow promote this style? >>> >>>> 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.) >>> Of course it could get shorter. In C it's nothing at all and you don't >>> complain about that degree of brevity! >>> >>>> 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! >>> >>> And C has int, struct, enum, char, const, extern... I think there is a >>> bit of a double standard here. >> >> 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. > > Well all I can say is that's not how I read the remarks. I didn't get > any sense of it being a disappointment, just that these things are > worthy of criticism. > > Anyway, short keywords are, to my mind, a complete non-issue. I don't > mind them in C and I don't mind them in Rust. It's very much a subjective thing. Unless someone can show real, relevant statistical evidence that one style of keyword length is better than the other in terms of fewer mistakes in code, then it will always be a matter of personal preference and familiarity. (Perhaps people will agree that extremes such as APL and Cobol are not ideal for most programmers.) So I am certainly not saying there's anything wrong with thinking Rust's "mut" and "fn" are fine. I am merely pointing out that it is also fine to think Rust missed an opportunity here and would have been better if the names were more descriptive. And it is fine to think that and also enjoy programming in C and C++ despite their sometimes short (or even non-existent) keywords. (As I have not used Rust for more than a brief "hello, world" style test, it would be unfair for me to express a strong judgement about the lengths of its keywords or library identifiers. But my knee-jerk reaction is that I'd prefer them to be longer.) > >> I don't know if I'd agree entirely with Juha here, but I'd certainly >> agree to some degree. But the point is that /if/ you think it is >> better to have clearer names, keywords, and language syntax in >> general, then Rust as a modern language should have done better. > > It's odd, but I'd never go that far. Maybe I am just not assertive > enough for the modern world! If I had this view, I'd express some > disappointment in a wasted opportunity, but I could not bring myself to > say that the designers should have done better. > For those that think the language could easily have been improved with more longer keywords, or in other ways be "better" than C (for whatever subjective meaning of "better" they choose) it is perhaps wrong to blame Rust's designers. Clearly they /could/ have done better, but it is a lot less clear that they /should/ have done better. One could perhaps blame those promoting Rust as a safer and better alternative to C. Many people would like to see a language that has the efficiency of C but lower risks of code errors. The people, projects and companies of influence who promote a candidate for such a language have a responsibility to ensure it really fits the bill. >> Whataboutism is not an acceptable defence, > > Sure. I was not defending Rust's choice. > >> nor is it double standards >> to use a different language that is worse. > > Nor was I suggesting the double standard came from making such a > multi-faceted choice as which language to use. I was remarking on > never having seen this objection raised about C or C++. > I interpreted your comment as a more direct response to Juha - accusing him personally of double standards. But it looks like I was reading too much into a general comment. Perhaps people are just so used to C and C++ programming that its keywords are considered "normal" or "standard", and everything else is judged in relation to them. "mut" is short because it is shorter than "mutable", rather than being viewed as how well it fits in Rust programming.
[toc] | [prev] | [next] | [standalone]
| From | Bart <bc@freeuk.com> |
|---|---|
| Date | 2022-09-22 23:15 +0100 |
| Subject | Re: ???Microsoft Azure CTO Mark Russinovich: C/C++ should be deprecated??? |
| Message-ID | <tgimqg$lv3$1@gioia.aioe.org> |
| In reply to | #167803 |
On 22/09/2022 21:56, David Brown wrote: > On 22/09/2022 21:15, Ben Bacarisse wrote: >> David Brown <david.brown@hesbynett.no> writes: >> >>> On 22/09/2022 17:46, Ben Bacarisse wrote: >>>> Juha Nieminen <nospam@thanks.invalid> writes: >>>> >>>>> 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?) >>>> I've seen all of these in C, so why single out Rust? Does the language >>>> itself somehow promote this style? >>>> >>>>> 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.) >>>> Of course it could get shorter. In C it's nothing at all and you don't >>>> complain about that degree of brevity! >>>> >>>>> 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! >>>> >>>> And C has int, struct, enum, char, const, extern... I think there is a >>>> bit of a double standard here. >>> >>> 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. >> >> Well all I can say is that's not how I read the remarks. I didn't get >> any sense of it being a disappointment, just that these things are >> worthy of criticism. >> >> Anyway, short keywords are, to my mind, a complete non-issue. I don't >> mind them in C and I don't mind them in Rust. > > It's very much a subjective thing. Unless someone can show real, > relevant statistical evidence that one style of keyword length is better > than the other in terms of fewer mistakes in code, then it will always > be a matter of personal preference and familiarity. (Perhaps people > will agree that extremes such as APL and Cobol are not ideal for most > programmers.) > > So I am certainly not saying there's anything wrong with thinking Rust's > "mut" and "fn" are fine. I am merely pointing out that it is also fine > to think Rust missed an opportunity here and would have been better if > the names were more descriptive. And it is fine to think that and also > enjoy programming in C and C++ despite their sometimes short (or even > non-existent) keywords. > > (As I have not used Rust for more than a brief "hello, world" style > test, it would be unfair for me to express a strong judgement about the > lengths of its keywords or library identifiers. But my knee-jerk > reaction is that I'd prefer them to be longer.) I've done a bit more than you then in porting a 70-line benchmark to it: https://github.com/sal55/langs/blob/master/fannkuch.txt (From line 670 and done during a brief period when I had a fully working implementation.) But this apparently is not idiomatic Rust. 'Proper' Rust code has most lines starting with "." (chained method calls I believe, split across lines) and is generally indecipherable to me. Having short keywords (they couldn't even stretch 'fn' to 'fun') is the least of it. (WTH is a borrow checker, and why do I have to concern myself with it instead of writing my app? Either the language should care of it, or give me full control.) It also seems to be one of the slowest languages to compile on the planet.
[toc] | [prev] | [next] | [standalone]
Page 1 of 6 [1] 2 3 4 5 6 Next page →
Back to top | Article view | comp.lang.c
csiph-web