You can still add g++, boost and other high-quality C++ libraries to OpenBSD via ports/packages. They just prefer plain C in the base install. Plain C is inline with their "keep it simple" philosophy.

g++ hasn't gone anywhere.

Indeed, just to make it clear: There's no more C++ code in the OpenBSD's base, but g++ the C++ compiler is still present.

I don't think that g++ will be removed. Too many things are written in C++. And as long as GCC is present in OpenBSD, there's no reason to remove G++.

And what will they do when GCC moves over to C++?

I believe they are working on pcc (for various reasons).

Unless that version of GCC is released under GPL 2, nothing.

What an interesting development. The year is 2011 and we are proudly announcing removal of C++ due to bloat.

I didn't catch the word "bloat" in the linked article, nor really any hint of such a complaint. Rather, it seems like the OpenBSD has happily announced the removal of C++ in their base because of compilation speed issues.

> Groff was also one of the slowest parts in a full build...

C++ compilers might be many things, but zippy they are not.

Well, C++ compiler is bloat, as is standard library. There's an effort to use Portable C Compiler (which recently reached 1.0 http://pcc.ludd.ltu.se/news/) to compile OpenBSD.

Plus, from mandoc website (http://mdocml.bsd.lv/):

Why? groff amounts to over 5 MB of source code, ...

> and its replacement is much faster in rendering manpages

Besides the build bloat, that certainly hints at it.

Mandoc is a tool specifically for formatting man pages. Groff is a general typesetting tool. That probably accounts for most if not all of the difference in speed.

Probably a good choice. For a workstation, you might encounter the need for a typesetting system. But for your router, you probably don't need it. So I think OpenBSD made the right choice about what to ship in core.

troff is technically a general-purpose typesetting system, but how many people are still using it for anything other than formatting man pages? (La)TeX and other formats have pretty much taken over.

Indeed. I hope Linux distributions will follow with replacing Groff. It's a huge, slow, ancient system and for the purpose of formatting manpages it can be replaced by a 15-line Python script.

(this has nothing to do with C++ versus C, simply with removing some bloated UNIX legacy code)

Well, 15 lines is a bit optimistic. mandoc is ~25 000 lines of C, and not yet complete.

I was figuratively speaking. In Python it'd be less lines than C, but still a substantial project.

Orthogonal to bloat, libstdc++ is a large, ugly, and hard-to-audit attack surface that I'm sure OpenBSD is glad to push out of core.

libstdc++ remains as much a part of core as it ever was.

But if nothing links with it, so there are no executables using it, that would seem to reduce the attack surface.

The attack surface of "there is groff in /usr/bin" was never very substantial.

Get root to run "man foo" with the right manpath...

I see. So does this purge only consist of compiled executables then, with the standard C++ headers and libstdc++ still getting a pass?

I think it's rather sad that HN has mostly ignored the meat of this story, and is instead focusing on a not entirely true one line throwaway.

Sad, but understandable. "OpenBSD writes their own ROFF interpreter" isn't very interesting, but "OpenBSD purges C++ from core" appeals to developers' strong emotional responses toward C++.

Yes. And it's not so much a C++ purge as it is a "unmaintainable GPL-licensed slow software" purge, as far as I understand. C++ does hurt comprehension, but it's not the main complaint.

Wait... so then libstdc++ isn't written in C++? Or is "core" different from "base"?

Option 3: core/base is not actually free of C++.

I write more C++ than C, but this still makes me happy.

Some people set an objective, for whatever reason, and accomplished it. Other people seem happy with the result.

I'd call that a positive outcome for OpenBSD and all the developers involved. Cheers!

Wow, another reason to check back in with OpenBSD. Regardless of the meta debate on C++'s virtues or issues, having the core system build with just C would seem to help in simplifying things.

I am perhaps in the minority but I would really like a straight forward to build and maintain UNIX derivative and perhaps this can be it.

I know I'm just one data point, but I've been quite happy with OpenBSD as my primary OS for over 7 years.

I'm running Debian on a spare laptop for "common Linux distro" testing purposes, but am continually annoyed by it.

Not being familiar with OpenBSD, what are some of the pain points you have when using Debian that you don't experience with OpenBSD?

I don't like apt-get. The way they break up packages is annoying and sometimes leads to debian-specific forks. I also hoped that Debian's vastly larger community would mean discovering several good packages apt-get (which I'd port to OpenBSD), but there really hasn't been much that OpenBSD doesn't already have. Disappointing.

GNU coreutils. The BSD userland (the core system) is much better integrated, which affects a great many things. In particular, I really prefer BSD top.

When I installed some recommended package so that closing my netbook's lid would make it suspend, it didn't work. I read the source, and it was so obviously broken (among other things, it was suspending on lid-close AND lid-open) that I just wrote my own. Usually I contribute patches, but...eh. Other stuff that tried to "automagically" configure itself, but didn't work quite right, and interfered with manual configuration.

"This project only has a man page because we want to note that man pages suck, look at the info page instead." I hate empty man pages, and it's particularly annoying because the documentation on OpenBSD is phenomenal.

I prefer /etc/rc.conf to /etc/init.d/ , though that's fairly minor. (I usually run daemons via runit anyway.)

There are probably several other things that don't come to mind at the moment.

Language purity for a project is never bad, it makes it easier to contribute to a project. However, this is barely a feature, given that C is weakly typed and common C functions do not use boundary checks.

For an operating system that aims to be secure, one would expect a more progressive stance, and heavy (intellectual) investment in a language that makes safety easier.

Yes, I know that OpenBSD prefers more secure variants of common functions.

When you only have 1 program using another language and it slows the builds, you tend to want to replace it. There are still scripts and such in different languages (ksh and I do believe some perl).

Right, just as I said, it is always a good idea to make a project more (language) uniform. But that wasn't my main point.

Since OpenBSD still compiles on a VAX, removing C++ from the build is a decent feature. As you say, OpenBSD has function with bounds checking and that seems to satisfy their requirements. Also, they haven't achieved language purity and I don't think they are trying.

It's funny, they are so proud of it. Groff is so ancient, you can't seriously claim it's written in C++. It's written in C++ circa 1988. Pre-template collections, no Standard library, no namespaces, no exceptions, practically plain C code. Well, not plain exactly, C with classes and virtual functions. I guess, OpenBSD folks didn't like virtual functions...

It'd probably be too much to hope that this catches on and becomes a trend.

So they replaced a generic roff system with a specialized man page viewer? Why? I mean, if you're rewriting everything and include a bevvy of output formats, why not make it a proper replacement? Would be quite a bit more unix-y. Yes, maybe a bit more work in the end, but you could always have "oroff 0.1" which only supports a -man subset evolve into a full-fledged implementation. Going from mandoc to "oroff" seems less likely.

(Or I'm just the only one who still occasionally uses ms/tbl/pic…)

The main reasons for replacing groff were:

1. Groff is buggy

2. Groff is slow to compile & execute

3. Groff is not BSD licensed

mandoc has none of these problems. If you want a "generic" roff system, groff is available as a package.

According to http://mdocml.bsd.lv/

> groff amounts to over 5 MB of source code, most of which is C++ and all of which is GPL. It runs slowly, produces uncertain output, and varies in operation from system to system. mdocml strives to fix this (respectively small, C, ISC-licensed, fast and regular).

Those are reason why you wouldn't use groff, it still doesn't explain why – if you're taking the effort – you're not building a proper roff replacement, but some subset bastard program. And then hack stuff like tbl into the main executable. (Never mind that there's Plan 9 roff or the heirloom version)

I get it, nobody really seems to use non-man roff anymore. Still, subsetting and reinventing the wheel (partially) seems a odd solution for this.

Resources, need, and code audits are the reason to build a simple tool that does the job you want.

Why is reducing the scope of the problem in order to simplify the solution so odd?

This isn't the program you are looking for [[ http://man.cat-v.org/plan_9/1/troff ]]

> So they replaced a generic roff system with a specialized man page viewer? Why?

Because no one uses roff format for anything other than man pages any more. And even then, it's extremely common to use it only as "object code", output from some higher level/cleaner input format (perldoc, pydoc, docbook/asciidoc). I like that they have high level output formats (pdf, html, ascii) and hope that the package becomes an option in Debian at some point.

I'm curious if someone can elaborate more on this. Is C++ in general that much more time-consuming to compile than C code? Or is it just an issue with gcc vs g++? Or is this issue unique to Groff?

C++, especially template heavy code, is orders of magnitude slower in compiling.

Clang and LLVM is faster but not that much faster.