Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]

Groups > comp.lang.c++ > #86469 > unrolled thread

“Microsoft Azure CTO Mark Russinovich: C/C++ should be deprecated”

Back to article view | Back to comp.lang.c++

Contents

  “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 1 of 6  [1] 2 3 4 5 6  Next page →

#86469 — “Microsoft Azure CTO Mark Russinovich: C/C++ should be deprecated”

“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]

#86470

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]

#86484 — Re: ???Microsoft Azure CTO Mark Russinovich: C/C++ should be deprecated???

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]

#86488 — Re: ???Microsoft Azure CTO Mark Russinovich: C/C++ should be deprecated???

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]

#86592 — Re: ???Microsoft Azure CTO Mark Russinovich: C/C++ should be deprecated???

[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]

#86594 — Re: ???Microsoft Azure CTO Mark Russinovich: C/C++ should be deprecated???

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]

#86619 — Re: ???Microsoft Azure CTO Mark Russinovich: C/C++ should be

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]

#86620 — Re: ???Microsoft Azure CTO Mark Russinovich: C/C++ should be

On Monday, September 26, 2022 at 11:24:51 AM UTC-4, Mut...@dastardlyhq.com wrote:

> True, but its doubtful much new greenfield code relatively speaking will be 
> written in [Java] in the future.

I think you've been misinformed :-)

Sometime in the 1990's, Java largely replaced C++ in middleware tooling for 
business-to-business messaging, data transformation, application servers for enterprises,
and IT infrastructure software generally as vendors including IBM, Oracle, and Tibco all moved 
to Java. That's a huge code base. There's some competition in this space from
.NET ASP, which is now cross platform across Linux, macOS, and Windows, but most of
the major vendors in this space are firmly in the Java camp. There's also a massive
amount of Java open source code in this space, including a JVM, particularly with the 
Apache Software Foundation.

Daniel
 

[toc] | [prev] | [next] | [standalone]

#86621 — Re: ???Microsoft Azure CTO Mark Russinovich: C/C++ should be

On Mon, 26 Sep 2022 09:00:34 -0700 (PDT)
"daniel...@gmail.com" <danielaparker@gmail.com> wrote:
>On Monday, September 26, 2022 at 11:24:51 AM UTC-4, Mut...@dastardlyhq.com
>wrote:
>
>> True, but its doubtful much new greenfield code relatively speaking will be 
>> written in [Java] in the future.
>
>I think you've been misinformed :-)
>
>Sometime in the 1990's, Java largely replaced C++ in middleware tooling for 
>business-to-business messaging, data transformation, application servers for
>enterprises,

Its not the 1990s anymore.

[toc] | [prev] | [next] | [standalone]

#86622 — Re: ???Microsoft Azure CTO Mark Russinovich: C/C++ should be

On Monday, September 26, 2022 at 12:11:54 PM UTC-4, Mut...@dastardlyhq.com wrote:
> On Mon, 26 Sep 2022 09:00:34 -0700 (PDT) 
> "daniel...@gmail.com" <daniel...@gmail.com> wrote: 
> >On Monday, September 26, 2022 at 11:24:51 AM UTC-4, Mut...@dastardlyhq.com 
> >wrote: 
> > 
> >> True, but its doubtful much new greenfield code relatively speaking will be 
> >> written in [Java] in the future. 
> > 
> >I think you've been misinformed :-) 
> > 
> >Sometime in the 1990's, Java largely replaced C++ in middleware tooling for 
> >business-to-business messaging, data transformation, application servers for 
> >enterprises,
> Its not the 1990s anymore.

Indeed :-) But the domination of Java in middleware tooling for 
business-to-business messaging, data transformation, application servers for 
enterprises, and IT infrastructure software generally remains, and major
vendors like IBM, Oracle and Tibco aren't moving anywhere, from the looks of
it. I realize this isn't your space.

Daniel

[toc] | [prev] | [next] | [standalone]

#86489 — Re: ???Microsoft Azure CTO Mark Russinovich: C/C++ should be deprecated???

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]

#86500 — Re: ???Microsoft Azure CTO Mark Russinovich: C/C++ should be deprecated???

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]

#86501 — Re: ???Microsoft Azure CTO Mark Russinovich: C/C++ should be deprecated???

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]

#86502 — Re: ???Microsoft Azure CTO Mark Russinovich: C/C++ should be deprecated???

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]

#86504 — Re: ???Microsoft Azure CTO Mark Russinovich: C/C++ should be deprecated???

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]

#86507 — Re: ???Microsoft Azure CTO Mark Russinovich: C/C++ should be deprecated???

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]

#86508 — Re: ???Microsoft Azure CTO Mark Russinovich: C/C++ should be deprecated???

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]

#86528 — g++ with -O6 slower than with -O2 [was Re: "Microsoft Azure CTO Mark Russinovich: C/C++ should be deprecated"]

Am Thu, 22 Sep 2022 23:15:44 +0100
schrieb Bart <bc@freeuk.com>:

> 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

I just implemented the benchmark myself (it should really be called
„Pfannkuchen“) quite straightforwardly (see below). There is a 1995
article about the the benchmark where the authors listed execution times
of (among others) C-versions compiled with "gcc -O2" and just "gcc". The
latter needed almost 4 times as long as the former. I wondered how "-O6"
would compare. So I compiled my program with that (using n=12 instead of
10 as in the article). To my big surprise "-O6": 

~/c> time ./fannkuch 
fannkuch(12)=65 equals 65 from oeis

real    0m36.325s
user    0m36.242s
sys     0m0.045s

was significantly slower than "-O2):

~/c> time ./fannkuch 
fannkuch(12)=65 equals 65 from oeis

real    0m30.976s
user    0m30.913s
sys     0m0.021s

What's the reason for that?




#include <iostream>
#include <algorithm>
#include <array>
#include <numeric>

//from oeis.org
int results[]={0, 0, 1, 2, 4, 7, 10, 16, 22, 30, 38, 51, 65, 80, 101,
113, 139, 159, 191, 221};

using namespace std; // I know…

const int n=12;

int flip(array<int, n> t) {
    int res=0;
    do {
        ++res;
        int top=t[0];
        reverse(t.begin(),t.begin()+top);
    } while (t[0]!=1);
    return res;
}

int main() {
    array<int, n> a;
    iota(a.begin(),a.end(),1);
    if (n>1) swap(a[0],a[1]); // don't need the perms with 1 at the beginning
    int m=0; //max
    do {
       int i=flip(a);
       if (i>m) m=i;
    } while (next_permutation(a.begin(),a.end()));
    cout<<"fannkuch("<<n<<")="<<m<<" equals "<<results[n]<<" from oeis"<<endl;
    return 0;
}

[toc] | [prev] | [next] | [standalone]

#86530 — Re: g++ with -O6 slower than with -O2 [was Re: "Microsoft Azure CTO Mark Russinovich: C/C++ should be deprecated"]

On 23/09/2022 12:44, Ralf Goertz wrote:
> Am Thu, 22 Sep 2022 23:15:44 +0100
> schrieb Bart <bc@freeuk.com>:
> 
>> 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
> 
> I just implemented the benchmark myself (it should really be called
> „Pfannkuchen“) quite straightforwardly (see below). There is a 1995
> article about the the benchmark where the authors listed execution times
> of (among others) C-versions compiled with "gcc -O2" and just "gcc". The
> latter needed almost 4 times as long as the former. I wondered how "-O6"
> would compare. So I compiled my program with that (using n=12 instead of
> 10 as in the article). To my big surprise "-O6":

I didn't know it went up to -O6, I thought that -O3 was the highest level.

My own tests shows -O3 was a bit slower than -O2, but -O4 and up were 
about the same as -O3.

Apparently there's no upper limit to optimisation level, as -O1000000 
also works (with the same result as -O3), as does -O1000000000000.

So the real mystery is what the deal is with those silly optimisation 
numbers.

 > I just implemented the benchmark myself (it should really be called

(Actually the reason for all those different (p)fannkuch versions was to 
use it as the basis of a bigger benchmark for comparing compilation 
speeds for large input files:

https://github.com/sal55/langs/blob/master/Compilertest3.md)

[toc] | [prev] | [next] | [standalone]

#86532 — Re: g++ with -O6 slower than with -O2 [was Re: "Microsoft Azure CTO Mark Russinovich: C/C++ should be deprecated"]

On 23/09/2022 14:53, Bart wrote:
> On 23/09/2022 12:44, Ralf Goertz wrote:
>> Am Thu, 22 Sep 2022 23:15:44 +0100
>> schrieb Bart <bc@freeuk.com>:
>>
>>> 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
>>
>> I just implemented the benchmark myself (it should really be called
>> „Pfannkuchen“) quite straightforwardly (see below). There is a 1995
>> article about the the benchmark where the authors listed execution times
>> of (among others) C-versions compiled with "gcc -O2" and just "gcc". The
>> latter needed almost 4 times as long as the former. I wondered how "-O6"
>> would compare. So I compiled my program with that (using n=12 instead of
>> 10 as in the article). To my big surprise "-O6":
> 
> I didn't know it went up to -O6, I thought that -O3 was the highest level.
> 

It is.  But gcc (in common with many compilers) accepts higher numbers 
and treats it all as highest level.

> My own tests shows -O3 was a bit slower than -O2, but -O4 and up were 
> about the same as -O3.
> 
> Apparently there's no upper limit to optimisation level, as -O1000000 
> also works (with the same result as -O3), as does -O1000000000000.
> 
> So the real mystery is what the deal is with those silly optimisation 
> numbers.
> 

At a guess, someone (long, long ago) thought it was a convenient 
compatibility with some other compiler that differentiated higher 
numbers - thus people could move from "some_other_compiler -O6" to "gcc 
-O6" without changing command line options.  (Many command line options 
in gcc are compatible with other *nix style compilers, new and old.)

>  > I just implemented the benchmark myself (it should really be called
> 
> (Actually the reason for all those different (p)fannkuch versions was to 
> use it as the basis of a bigger benchmark for comparing compilation 
> speeds for large input files:
> 
> https://github.com/sal55/langs/blob/master/Compilertest3.md)

[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