[pjmlp]

In part yes.

Had GNU/Linux not taken off, in the alternative universe from Windows, BeOS, Mac OS, OS/2, commercial UNIX (remember Motif++ and CORBA?) would kept writing the software in C++, instead of caring about creating FOSS stuff in C.

GNOME vs KDE is a good example of that schism and language wars.

[groby_b]

Having written software in the 90s: C++ was unusable for large-scale apps on commodity hardware. It was a neat toy. It had humongous compile times, and the runtime was suboptimal at best.

The choice was protracted language wankery with continuous (wrong) declarations of "Soon, the compiler will make it fast enough", or actually shipping software.

The balance started tipping in the early to mid-2000s. You could, if you were very careful, write decent-sized systems with good performance in C++ at that point, and the abstractions were starting to be worth it.

And I say that as somebody who enjoys C++, and has written code in it since the late 80s. Yes, on cfront. "Horses for course" always has been, and always will be, the major driver for language adoption. That particular horse wasn't ready in the 90s.

[zabzonk]

> And I say that as somebody who enjoys C++, and has written code in it since the late 80s

As have I, and I say you don't seem to know what you are talking about. I've been involved in writing very large Unix and Windows applications in the 1990s (starting in the late 80s), and have had no problems that you mention.

[mcguire]

I remember CORBA. Oh, god, do I remember CORBA. I wish I could forget CORBA.

[pjmlp]

It is called gRPC nowadays.

[CraigJPerry]

All of those operating systems kernels were written in C (and ASM) not C++.

[pjmlp]

Where did I mentioned the kernel?

And no, that is not correct.

Mac OS was a mix of Object Pascal (originally created by Apple), Assembly and C++.

Windows (32 bit variants) and OS/2 userspace has always been a mix of C and C++.

BeOS userspace was C++.

Symbian was full C++, including the kernel by the way.

[duskwuff]

> Mac OS was a mix of Object Pascal (originally created by Apple), Assembly and C++.

That doesn't ring true at all.

Object Pascal was a rather short-lived project at Apple. It was only seriously used for the MacApp framework -- which was a separate product sold to application developers, not part of the core OS or development tools -- and was abandoned entirely during the PowerPC transition. Later versions of MacApp used C++.

The bits of source code I've seen for System 7 were primarily C and assembly, with some older code in (non-object) Pascal. I don't recall seeing any C++.

[rovolo]

I checked through the source code for System 7.1 at https://www.macintoshrepository.org/1398-mac-os-7-1-source-c... . You look correct (A=assembly, H=header, C=c, P=pascal, R=resource)

    % find ~/Downloads/System\ 7.1\ Source/ -type f -print0 | xargs -0 -n 1 basename | cut -d. -f 2- | tr '[a-z]' '[A-Z]' | sort | uniq -c | sort -rn | head -20
      869 A
      308 H
      189 C
      162 P
       85 R
       69 MAKE
       31 M.A
       28 O
       11 RSRC
       11 AII
    ...

[dvfjsdhgfv]

Would you say that the predominance of C++ rather than C in FLOSS would have a net positive result?

[pjmlp]

Yes, because while it isn't fullproof due to copy-paste compatibility with C89, at least it offers better tooling for safer coding, provided one doesn't code "C with C++ compiler".

Namely:

- proper string and vector types (most compilers allow to enable bounds checking anyway)

- stronger rules for type conversions

- reference types for parameters

- better tooling for immutable data structures

- memory allocation primitives instead of getting sizeof wrong to malloc()

- collection library instead of reinventing the wheel in each project

- RAII

- smart pointers

- templates instead of error prone macros

- namespacing (usefull in large scale projects with prefix tricks)

[groby_b]

A large number of those came only usefully into existence in 1998, with C++98

string & vector types: STL, 1998 type conversion operators: 1998. mutable keyword: 1998. collection library: STL, 1998. smart pointers: STL, auto_ptr<> in C++98

I'd argue that without STL & C++98, C++ would've languished even longer. And with STL, it still took another 5 years for the compilers to be good enough.

[brandmeyer]

> And with STL, it still took another 5 years for the compilers to be good enough.

This is under-stated, IMO. It wasn't really until 2004 or even later that we had high-quality support for C++98 in GCC. LLVM wasn't available, yet. Heaven help you if you wanted to develop in C++ on OSX, since Apple's packaging of GCC was a total disaster. Step zero for developing C++ on OSX was "install GCC from FSF sources" for many years.

Even MSVC support was lagging. It wasn't until the Microsoft tools leadership got involved with C++11 that MSVC took standard support seriously. They were already prioritizing .NET in that timeframe.

Meanwhile, the big open-source desktop C++ libraries (Qt and WxWindows) still don't fully take advantage of the types and features in the standard library in 2021.

[DerekL]

> Heaven help you if you wanted to develop in C++ on OS X, since Apple's packaging of GCC was a total disaster.

If you were developing Mac programs in C++ back then, you were probably using Metrowerks CodeWarrior.

[for_xyz]

> Meanwhile, the big open-source desktop C++ libraries (Qt and WxWindows) still don't fully take advantage of the types and features in the standard library in 2021.

Of course not. C++ and libraries don't go along nicely. STL is not really useful for cross boundary interop due the fact that C++ ABI is not stable.

Shipping libraries that leak STL types all over the place will only give you headache.

[mcguire]

I also have a copy of P. J. Plauger's Draft Standard C++ Library.

[zxzax]

Good news! GNOME and KDE both have efforts to add more Rust: https://wiki.gnome.org/Projects/Rust https://community.kde.org/Rust